解决方法

在软件开发领域做一名会思考的从业者。这包括经常反思自己的工作状况。考虑一下自己的实践是新颖的，创新的，还是过时的。对那些团队中其他人都想当然的事情，多给自己画几个问号。如果觉得目前工作中有一些让人特别痛苦或开心的事情，问问自己事情是怎么变成这个样子的，如果问题是负面的，如何能改善它？我们的目标是通过将每一种经验拆分开，然后再以新的、有趣的方式组合起来，从其中提取最多数量的教育价值。

一种可用于明确表达这种反思的技巧是使用“个人实践图”（Personal Practices Map）。这是Joe Walnes在伦敦的“极限编程周二俱乐部”上介绍的一种想法。它要求人们有意识地写下自己所做的事情以及这些事情之间的联系。在每个人写下他们的实践之后，整个小组对其中的实践展开讨论。如果你看看那个“人们的个人实践图”的网页，^[1]你会看到由Ade和其他几名开发者画出的图。

反复使用这一技巧，会得到这样的结果：你的一组实践中所产生的变化被凸现出来。比如，2003年以后，Ade从“从不使用调试器”转变到实践“测试驱动的调试”，后来在实现复杂算法时又开始刻意使用不变量（invariant）。拥有一张看得见摸得着的实践图表，能使你更深入地思考自己所使用技术的每一次变化。在Ade的例子中，采用测试驱动开发使他重新评估了其他所有的实践，而图表成了将这一变化形象化的工具。

这种观察、反思并改变的过程并不只限于你自己的行为。你还可以悄悄地观察团队中的熟练工和师傅。思考他们使用的实践、过程和技术，看看这些东西能否跟自己经验中的其他部分关联起来。只需要在更有经验的技师们着手工作时近距离观察他们，即使是学徒，也能发掘出新颖的思想。

2004年，Dave是一个极限编程（XP）团队的一员，那个团队里有好几名世界级的开发者。他们拥有一种相当标准的结对编程风格：一名开发者写一个测试，然后把键盘推给他的搭档，他的搭档写代码让这个测试通过，然后立即写出下一个测试，再把键盘推回给第一个家伙。第一个人写代码通过这个测试，如此反复。这种结对编程风格从未被真正讨论过；它只是在个别的经验中形成的。

Dave加入了他的下一个项目，在他向新队友们解释这种结对编程的风格时，他意识到这种风格需要有一个名字。Dave为此写了一篇博客，结果引起了一连串的反应，很快StickyMinds.com邀请他写几篇专栏文章。所发生的这一切仅仅因为Dave反思了更高级的开发者引入的实践。

敏捷社区采纳了这一过程的某个版本。由Norm Kerth的《Project Retrospectives》一书推动，它要求团队周期性地聚在一起回顾项目的状态，以找出改进的方法。这样一来，它就比学徒可能采取的持续自我分析更加正式。它也要求相对开明的管理者愿意提供一个相对安全的环境，理由是尊崇Kerth的最高指导原则：“无论我们发现了什么，考虑到当时的已知情况、个人的技术水平和能力、可用的资源，以及手上的状况，我们理解并坚信：每个人对自己的工作都已全力以赴。”^[2]

学徒们并非都能有幸在这样的环境中工作，但即使在相对不那么宽松的企业文化中，养成富有成效的反思习惯也是有用的。

只要你工作的时间足够长，人们就会开始称你为“老手”，但这不应该是你的目标。所有的经验都表明你已经有能力在这个行业生存。但它显示不出你所学到的知识量，仅仅是你所花费的时间。在我们行业的某些领域，有时很容易将同样的时间经历重复10次却没有取得能力上的实质进步。事实上，这有时会变成“反经验”（anti-experience），即这样一种现象：每一次新的时间经历仅仅强化了你所养成的坏习惯。^[3]这就是为什么你的目标应该是达到技能娴熟，而非“有经验”。技能水平的提高，是你在研究、适应及改善工作习惯方面所付出努力的唯一有效的证明。

[1]http://www.xpdeveloper.net/xpdwiki/Wiki.jsp?page=MapsOfPeoplesPersonalPra-ctices.

[2]The Retrospective Prime Directive（回顾活动最高指导原则）：http://www.retrospectives.com/pages/retroPrimeDirective.html。

[3]反经验（Anti-Experience）：http://c2.com/cgi/wiki/changes.cgi?AntiExperience。