软件的成败与否，很大程度上取决于用户的看法，要“让你的用户参与权衡”，但也要知道进退，
知道何时止步，不能画蛇添足。对于现阶段的我们而言，处在知识经济的时代，知识资产变得尤
为重要，一不小心就会被这个社会淘汰，作者明确提出了自己的观点和建议，为我指明了方向。
当你编码时：
代码需要演化，它不是静态的事务。
重构
不要试图在重构的同时增加功能。
在开始重构之前，确保你拥有良好的测试。
采用短小，深思熟虑的步骤。
从一开始就可以把可测试性构建进软件中，并且在把各个部分连接在一起之前对每个部分进行彻底的测试。
在项目开始之前：
需求需要挖掘，而不仅仅是收集。找出用户为何要做特定事情的原因，而不是他们目前做这件事情的方式。
建立需求文档：把形式化的模板做备忘录
好的需求文档会保持抽象
Chap1 注重实效的哲学
程序员所应该遵循的实用主义原则。
我的源码让猫给吃了：出现错误时，要诚实，不要推诿或者找借口。要提供各种可能的解决方案与后果并
与他人沟通，而不是提供借口。
软件的熵：这是著名的破窗户原理。项目中一个小的、无人料理的问题可能带来后续编码时的懈怠，从而
造成更大的问题。不要容忍任何小的错误，解决它或至少打上TODO标签。
石头汤与煮青蛙：这个小节很有趣，它讲述了小的变化如何能渐进式地演变为大的变化。
一方面，在面对一个毫无生气的团体、试图催生积极的变化时，可以去做第一个带来改变的人。这样，就
会有人随之作出改变。可能每个改变都非常微小，但可以渐变式地带来大的改变。
另一方面，不管是个人和团体都很容易对于小的改变疏忽大意。这意味着有些时候小的改变会在不经意间
催生出巨大的改变。不管是有人恶意为之还是意外累积而成，小的坏习惯、坏改变可能会积累成很大的问
题，而程序员又可能最后才看出问题来。
这里有一个有趣的问题。石头汤显示我们可以通过小的积极改变催生大的积极改变，而煮青蛙显示我们可
能会被小的消极改变迷惑，而忽略了他们在催生大的消极改变。在个体试图催生变化时如何判断是哪一
种，消极与积极的改变又以什么作为判断标准？
Chap2 注重实效的途径
程序需要遵守的实用主义原则。
重复的危害：如果某个事物在代码中重复多次，就可能会在维护过程中带来问题，因为改动了一处而忘记
改动另一处造成自相矛盾。这加大了维护难度。要遵守DRY原则，即Don’t repeat yourself。
重复通常由这些东西引起：
强加的重复，由文档或用户需求决定。这通常可以依照情况消除。需要重复表示的信息可以用元数据sche
ma与代码生成器消除重复。注释与代码会重复，但实际上这种重复没有必要：注释不应重复代码中显而易
见的东西，而应该表达更高级的东西。文档与代码也会重复，可以利用文档生成工具。有些语言会强加一
些重复，这比较难解决，只能依情况而定，一些基本的技术是cpp中不要在其他文件中引用函数，而应该使
用头文件。
无意的重复，由设计的疏忽造成，需要积极的检查和重构。如果为了性能需要违反DRY原则，记得将重复本
地化，不要泄漏到模块外，并保持模块内行为良好。
无耐性的重复，可能造成远大于一时麻烦的痛苦后果。程序员要学会约束自己。
开发者之间的重复，需要加强开发者之间的沟通。