程序员修炼之道

不要容忍破窗户（低劣的设计，错误的决策，或是糟糕的代码）不修，发现一个就修一个，置之不理会加速腐烂的进程。 Remember the big picture.要持续不断的观察周围发生的事，而不是你自己在做的事。 编程就像绘画，要知道何时止步，不然绘画就会迷失在绘制中。 如果把知识看做资产，管理知识资产就和管理金融资产一样： 1. 严肃的投资者一定定期投资 2. 多元化是长期成功的关键 3. 聪明的投资者在保守的投资和高风险、高回报的投资之间平衡资产 4. 投资者设法低买高卖，取得最大回报 5. 应周期性的重新评估和平衡资产 DRY：不要在系统中对知识进行重复 正交性：不要把任何一项知识分散在系统各处

关于正交性： 如果两个或多个事物中的一个发生变化，不会影响到其他事物，这些实物就是正交的。必须要消除无关事物之间的影响。正交还能促进复用，组件如果有具体、良好的定义的责任，就易于与新组件组合在一起，且得到的结果往往不是M+N，而是M×N。 原型制作是一种学习经验，其价值并不在于所产生的代码，而在于所学到的经验教训

让错误尽可能在源头暴露，越晚发现越难解决 代码中的 assert 只能用于检查“决不该发生的事” Heisenbug: 调式改变了被调试系统的行为 编写“羞怯”的代码是有益的，方式有两种：不向别人暴露自己，不与太多人打交道

怎样进行重构？Martin Flower给出了以下简单提示：

一、重复的危害。DRY原则：

这个原则的释义应为：

每一个对象、属性都要有其唯一性，这是安全的要求。但远远不是这样，这是一种理想的状态，真正做到非常困难，特别是在时间有限、产品多变、要求敏捷、快速迭代的要求下。 重复的种类有： 1、强加的重复： 作者列举了几种产生这种重复的可能性：

总的来说是机制问题，我们尽量把机制的设计朝适合具体项目情况、减少重复上来。像信息的多种表达的问题，就需要有原数据、原规则、转换器，来保证多种表达之间的一致性。比如多平台之间不得不做重复的实现，但这不可避免，只能尽量共用基础类库减少多余的、可能产生歧义的内容。 2、无意的重复： 作者举了一个例子，一个类输出几个变量值，而值间有依赖计算关系，如果直接把这个几变量值输出，就是可能产生歧义的地方。最好的办法是提取出来原子数据，剩下的变量值通过公式动态由原子数据计算返回。 3、无耐性的重复： 这里显然就在说copy代码了，这对所有程序员都是一个很重的考验，在感觉有copy对象的时候如何去做到不copy，抑或是copy了不出错？最好的办法只能是告诉自己为了避免以后无休止的产生并不得不中断手头的工作去补现在copy代码带来的坑，现在尽量不要copy，即使要，也不如把原来一码一行一行copy，以确保自己知道这每一行确实是需要copy并且没有错误的（我的建议）。 4、开发者之间的重复 这就是是传说中的重复造轮子，可这个问题太难解决，只能提倡多参与、使用开源项目的代码，多交流。同时，多使用框架，多让代码模块化。 二、正交性 这个问题说白了就是“解耦合”、“模块化”、“组件化”，作者认为这样做的好友有：

具体到编码层面，作者给出的建议是：

另外，在设计、测试、文档、选择工具库方面也要注意这种正交性，在此不赘述。 三、可撤消性 1、

2、

3、做灵活的架构，无论你使用的是何种机制，让它可撤消，如果某样东西是自动添加的，它也可以自动去掉。没有人知道未来会怎么样，尤其是我们！所以要让代码学代摇滚，可以摇就摇，必须滚就滚。——也就是说，不要理那些看不见的，做你现在知道的，做得更灵活可变，并且随时准备着修改。 四、曳光弹（Tracer Bullet） 曳光弹用于在发射子弹时作为尝试，发射时带有光尾，如果它击中目标，则后面通过同样的角度、发射条件的子弹就可以跟着它去击中目标了。 做一个新的需求不甚确定的项目，可以用这种方式，开发一份曳光代码，实现在目标共同的条件环境，如果它检验合格，再在它的基础上进行丰富，直到完成。 它的优点：

注意事项： 1）曳光弹并非总能击中目标 2）曳光代码 vs 原型制作（注：原型用完就扔掉，可能用其他的快捷的方式、语言等去实现，比如GUI，而曳光代码需求考虑更多的实际条件，而且最终它会成为结果的骨干部分。所以原型制作可以看作”发射曳光弹之前的侦察和情报收集工作“） 五、原型与便笺

”为了学习而制作原型“

可以忽略的细节有：

制造原型必须要放弃细节，但

所以在制作原型之前要确保每个人都能理解这是原型，而不是最终结果，这些代码用完就扔，不完整并且不可能完整。 六、领域语言

，这里说的是语言在沟通、认知中的重要性。具体到本节书写的目的，就指的是在具体领域写具体领域专用的语言了。

这里指在需要的情况下，实现当前领域专用的小型语言，当然这需要编写专用的编译器，使用专用的文法；也可以扩展已有的语言，在这种方法上，实际上形成专用的类库；更简单的一种，用SQL、网页、XML等动态的数据形式来存储和传递动态数据，或者用指定命令作为输入，而其他的内容用固定的已有语言普通实现，然后使两者结合，所谓嵌入。 做这件事最重要的应该是权衡清楚易开发性和易维护性两者。 七、估算 通过学习估算，你可以在接受需求时，直觉地知道它是否实际可行，在实现时，能够知道哪些子部分需要优化，哪些可以放在一边。从而避免了意外的发生。 1、估算首先要知道多准确才足够准确，需要知道对方需要的信息的目的和尺度。 2、你使用的单位会对别人对结果的角度造成影响。因为单位意味着不同级别的精度。因此，作者推荐的度量估算单位为（其他级别的单位选择也可以参考这种方式）：

3、估算的关键还是在于系统建模，建模的步骤为：1）请教做过类似事情的人；2）理解提问内容；3）建立系统模型。 4、建模是用模型的简单性来和精确性做交易，所以要认可不精确性的存在。 5、建模时可能还能发现关键节点的存在。这些节点存在底层模式与过程，当选择去除这些节点，你可能可以用比较小的某些特性的牺牲换来更多其他方面的收获，比如时间、成本的降低或效率、性能的提升。 6、建立了模型之后，可以把模型分解为不同的组件，组件的关键变量在于某些参数，之后需要做的就是确定每个参数了。在为参数逐一指定数值时，需要考虑哪些参数是倍数增长、减少，哪些参数会引起的只是少量加减。重视关键参数，从而提高估算的精确度。在得到所有参数之后，计算答案，并选择合适的单位和精度，给出一个合适的答案。 7、在得到答案时，可以答案是奇怪的，这里要排除几个嫌疑：计算错误、模型错误、问题理解错误。 8、

。特别是当估算错误之后，不要一笑而过，检查、反思，看看模型错在哪，或者是其他原因。这样你的下一次估算会更准确的。作者建议，从现在开始写估算日志，追踪每一次的精确程度，找到自己的估算瓶颈。 9、面临较大项目进度的估算，普通的方法常常会失效，除非在相同项目上有过经验，否则这是一个悖论。特别是当你实行增量开发、重复：检查需求、分析风险、设计+实现+集成、向用户确认，这样的步骤，一开始因为团队、技术要求、项目要求等等不同，你只能猜想，但在经过一轮迭代之后，基于经验，可以逐渐提炼优化原来对迭代次数、迭代所做内容的猜想，一次比一次好，对进度表的信心也将随之增长。这就是所谓“通过代码对进度表进行迭代”。 10、在被要求进行估算时，可以说

。利用这个时间，像前面所说一样，做一次检查和评估，再给出答案，将会是一个比较令人满意的结果。

不要容忍破窗户（低劣的设计，错误决策或是糟糕的代码）： 一个不修，会越来越多，迅速恶化。 如果没有人处理项目的所有垃圾，找一个大型垃圾桶处理掉。不要遗留下来 当你容忍项目中已存在的垃圾时，会是的自己也不断创造垃圾 当项目中都是漂亮的代码时，你也会想法设法保持优雅 即使暂时无法处理修补垃圾代码，也要把垃圾分离出去，使成为一个独立的附属，随时可以修补和去除 知道何时停止： 不可能存在完美的代码，完美的功能。 知道下一步改进所带来的麻烦和改进是否合算 学习新的知识： 定期学习：即使学习量很小 多元化：需要知道目前所用的特定技术的各种特性，掌握的技术越多，就越能更好的调整 管理风险：不要把所有的技术放在同一个领域 领先一步：在知识得到大规模肯定和应用之前学习它可能会得到高额回报，而不是总在追随流行的知识，类似于股票 重新评估和平衡：或许上个月的热门技术已经冰冷，需要重温很久没用的某项知识， 建议： 每年至少学习一种新语言 每季度阅读一本技术书籍 也要阅读非技术书籍 上课：培训等 参加本地用户组织 实验不同的环境 跟上潮流 持续投入：如果熟悉了某种新语言，继续前进 不要重复你自己： 软件中的每一项知识都必须单一,无歧义，权威的表示 使修改时只用修改一处，永远不要期望自己记得与此项关联的其他项，保证只需要修改一处 正交性： 系统功能不相互依赖，保持良好的隔离性，使更好的复用，测试，结合 可撤销性： 应该允许突然的变动。如数据库系统，商业逻辑 但随着项目的进展，一个个关键决策的作出，越来越难作出重大改变 构建原型： 使用高级的语言实现原型，推迟考虑许多细节，忽略完整性，可以使用虚设的数据，不使用文档和注释 迅速产生一个演示，方便的进行展示，提供样本以修改，测试 提供犯错误的机会，可以为不必要的开发做好准备 在调试时小心“近视”: 要抵制只修正你看到的症状的急迫愿望：有可能实际的故障就在旁边。 要小心的改正每个错误，比编码更谨慎的态度去。因为错误的改正bug会导致真正bug更深次的隐藏 代码生成： 可用来解决“不要重复你自己”问题，不用复制粘贴代码，而采用一个源文件生成代码的方式来进行，永远保持生成代码 通过合约进行设计： 对前条件严格，传递好数据是调用者的责任。而允诺返回的东西要尽可能少。 早崩溃，对于一个错误的参数，要直接了当的崩溃，明确错误 软件中不可能发生的事情，也可能发生，要检查，断言： 一个月少于28天 c++:a=2;b=3;if(a+b!=5) exit(1); 内角和不等于180度的三角形 没有60秒的一分钟 java：（a+1)<=a 永远要相信事情有可能发生，不要轻易断言 要针对不同的问题，采取生成错误信息，或引发异常，或忽略！ 元数据驱动(扩展性)： 把抽象放进代码，细节放进元数据 对决定性的配置放在代码外，进行配置 商业逻辑更应成为元数据 如采购天数，定期备份等等，这些数据应放在配置文件中，单独列出 清楚了解什么事物表示为程序的具体代码，什么应表示为外部的元数据 其实也就是扩展性，应该把经常变动，或者需要变动事物列出，方便用户自主更改 何时进行重构： 重复：发现对DRY原则的违反 非正交的设计 过时的知识 性能 1.不要试图在重构同时增加功能 2.在开始重构之前，确保拥有良好的测试，这样，如果改动破坏力任何东西，便能很快知道 3.采取短小，深思熟虑的步骤 不要使用你不理解的向导代码： 特别是这些代码与你自己的代码交织一起，你就只能前进，而不知道修改，特别是GUI构建 形式方法（UML)： 它们无法表示有适应能力的动态系统 鼓励专门化，需要专门去学习，把设计数据模型的人跟具体编码人分离 代码测试： 编一点，修一点 sign your work!

1、在犯错误时，

2、软件的熵：

，有问题马上解决掉，比如低劣的设计、错误的决策、糟糕的代码，就算没有时间，请把问题代码注释掉或者注明TODO、或者用假数据（dummy data），使问题可控。一旦有破窗户出现，整个系统很快就会恶化、腐烂。 3、

，煮一锅石头汤总需要发起的人。在大家都觉得问题很大，启动很难时，先做点起始工作，让大家跟进，这确实是一个很不错的主意，千里之行始于足下。还有一句话：

，这就是典型的先斩后奏。 4、

，往往我们在处理日常琐碎问题的过程中确实容易忘记当初是为什么开始的，我们到底为了什么目标去进行的，所以要用各种办法来提醒自己，不时地提醒，总结、归纳、修正我们的目标，以保证从容和正确，防止温水煮青蛙。同时也要注意，自己做的目标是客观，还是主观的意愿，特别对于一个组织来说，我们在做催化剂时更需要考察这个问题。 5、

，特别是在外包产品时更明显，让需求提出方为质量自己做出选择，这样与工程时间进行相关联，更能给出两方能接受的、实际可行的时间估计。因为”许多用户宁愿在今天用上有一些毛边的软件，也不愿等待一年后的多媒体版本“。及时给他们一个可以使用把玩的东西，他们的反馈能够把你引向一个最终的解决方案（不一定是最佳，但至少是他们最能接受的可行方案）。 对于质量问题，作为一个普通用户，他更关心的是产品价值，只要这个产品能够满足他的需求，能解决他的核心问题，一些小毛病确实也是无伤大雅。当然还是以可用为前提，不能一上来就Crash，那用户也无法用下去，前10秒决定用户的去留，用户都无法留下来，就谈不上用户价值了。而且，一个产品如果能够及时更新，修复问题，用户也会感觉到惊喜和收获，这使用户对产品以及产品团队的认同度得到提高，他也会觉得自己得到重视，并且看到希望。 6、

，所以，要在职业生涯获得成功，必须像管理金融资产一样，管理自己的知识资产，做到以下几条：

7、根据上述知识资产投资的要求，建议如下

8、与专家们打交道的礼节和教养：

9、作者建议：从现在开始做上面的建议，如读一本新书、学习一门新语言，更重要的，

10、与人交流的注意事项

11、使用电子邮件的技巧，归纳如下： 1）在发送电子邮件前一定要校对； 2）检查拼写； 3）尽量准备引文； 4）引用别人的邮件时一定要注明出处； 5）不要攻击别人； 6）检查收件人名单； 7）将收到和发送的重要邮件分类归档。 # 本章完.