程序员修炼之道（通俗版）——第七章

《程序员修炼之道》这本书中的内容挺不错，里面包含了很多精华，但一些句子很拗口，所以我就根据国人的阅读习惯，在不改变原意的情况下对词句稍加修改，标题中的“通俗版”就是这么来的。

1、在讨论用户界面时，需求、政策和实现之间的区别会变得非常模糊。“系统必须能让你选择贷款期限”是对需求的陈述。“我们需要一个列表框，以选择贷款期限”可能是，也可能不是。如果用户一定要有列表框，那么它就是需求。相反，如果他是在描述选择能力，但只是用列表框做例子，这个陈述可能不是需求。
找出用户要做某件事情的原因，而不只是他们目前做这件事的方式，这很重要。到最后，你的开发必须解决他们的商业问题，而不只是满足他们陈述的需求。用文档记载需求背后的原因将在每天进行决策时给你的团队带来无价的信息。

2、有人会认真考虑用下图中那些过分简单化的木棍人来为复杂的信息建立文档，这可能会让我们觉得难以置信。不要做任何方法的奴隶，只要是能与听众交流需求的好方法，你都可以加以使用。

3、制作需求文档时的一大危险是太过具体，好的需求文档会保持抽象。在涉及需求的地方，最简单的、能够准确地反映商业需要的陈述是最好的。这并非意味着你可以含糊不清——你必须把底层的语义不变项当作需求进行捕捉，并把具体的或当前的工作实践当做政策记录文档。
需求不是架构、需求不是设计，也不是用户界面。需求就是需要。

4、管理需求增长的关键是向出资人指出每项新特性对项目进度的影响。当项目已经拖后了一年，各种责难开始纷飞时，能够准确、完整地了解需求增长是怎样及何时发生的，会很有帮助。
我们很容易被吸进“只是再增加一个新特性”的大漩涡，但通过追踪需求，你可以更清楚地看到，“只是再增加一个新特性”其实已经是本月新增的第15个特性。

5、不时地，你会发现自己与一个有很多问题的新项目牵扯在一起：某项工程设计你就是找不到头绪，或是你发现有些代码比你想象的要难得多。也许它看起来是不可能解决的，但它真的有看上去那么困难吗？
考虑现实世界的谜题——那些好像是作为圣诞礼物、或是从旧货市场突然出现的奇形怪状的小木块、锻铁、或是塑料。你要做的就是拿掉铁环、或是把T形块放进盒子里等等。
于是你拉动铁环，或是试着把T形块放进盒子里，并且很快发现明显的解决方法没有用。你无法以常用的方式解开谜题，但即使这很明显，人们仍然会继续尝试同样的事情——一次又一次——并且认为那样肯定能行。
解开谜题的秘诀是确定真正的（而不是想象的）约束，并且在其中找出解决方法。有些约束是绝对的；有些则是先入之见。绝对的约束必须受到尊重，不管它们看上去有多讨厌或与愚蠢。另一方面，有些外表上的约束也许根本不是真正的约束。
当问题百思不得其解时，换个思路、换种角度，或从其他方面解释下这个问题，那可能会给你带来意想不到的惊喜。

6、有时你会发现，自己在处理的问题似乎比你以为的要难得多，感觉好像是你走错了路——一定有比这更容易的方法！这正是你退回一步，问问自己以下问题的时候：有更容易的方法吗？

• 你是在设法解决真正的问题，还是被外围的技术问题转移了注意力？
• 这件事情为什么是一个问题？
• 是什么使它如此难以解决？
• 它必须以这种方式完成吗？
• 它真的必须完成吗？
  很多时候，当你设法回答这些问题时，你会有意外的收获，很多时候，对需求的重新诠释能让整个问题全部消失——就像是戈尔迪斯结。
  当你正在处理的问题变得越来越复杂时，那多半是你的解题思路出现了偏差，不要继续往下走了马上停下来，看看问题出在哪里，然后重新整理思路，你一定会找到一个更好的解决方案。

7、每个人都害怕空白的纸页，启动新项目（或是已有项目中的新模块）可能会是让人身心交瘁的经验。我们许多人更愿意延缓做出最初的启动承诺。那么，你怎样才能知道，你什么时候是在拖延，而不是在负责地等待所有工作准备就绪？
在这样的情形下，我们采用的一种行之有效的技术是开始构建原型。选择一个你觉得会有困难的地方，开始进行某种概念校正。在典型情况下，可能会有两种结果。一种结果是，开始后不久，你可能就觉得自己是在浪费时间。这种厌烦可能很好的证明，你最初的勉强只是希望推迟启动。放弃原型，回到真正的开发中吧。
另一种结果是，随着原型取得进展，你可能会在某个时刻得到启示。突然意识到有些基本的前提错了。不仅如此，你还将清楚地看到可以怎样纠正错误，你将会愉快地放弃原型，投入正常的项目。你的直觉是对的，你为自己和团队节省了可观的、本来会浪费的努力。
当你做出决定，把构建原型当作调查你不适的一种方法时，一定要记住你为何这样做。你最不想看到的事情就是，你花了几个星期认真地进行开发，然后才想起你一开始应该先画一个原型。
有一点冷嘲热讽的意味：从“政治策略”的角度说，去构建原型也许比简单的宣布“我觉得不该启动”，并开始玩单人纸牌游戏更能让人接受。

8、作为注重实效的程序员，你应该倾向于把需求搜索、设计、以及实现视为交付高质量系统这一过程的不同方面。不要信任这样的环境：搜索需求、编写规范、然后开始编码，所有这些步骤都是孤立进行的。相反，要设法采用无缝的方法：规范和实现不过是同一过程——设法捕捉和编纂需求——的不同方面。每一步都应该直接流入下一步，没有人为制造的界限。如果把来自实现与测试的意见添加到规范中，你将发现，我们的开发过程会更加健康。

9、一些开发者，在由许多已沉没的项目组成的大海里漂流，不断抓住最新的时尚，就像是遇到海难的人紧紧抓住漂来的木头一样。每当有新木头漂过时，他们都会费力地游过去，希望这一块会更好。但到最后，不管漂浮物有多好，这些开发者仍然漫无目的地漂流着。
新工具、新技术只是我们达到目标的手段，最好是不要为了学习而学习，不要忘记学习它们的初衷是为了解决问题。