《程序员修炼之道-从小工到专家》是一本1999年写的老书，但15年之后，书中的许多道理依然没变，时不时拿出一章咀嚼一下仍有许多可回味之处。
第二章 注重实效的途径
7、重复的危害
开发一个软件，大量的时间都会用在维护上，牢记DRY原则（不要重复你自己Don't Repeat Yourself）
系统中的每一项知识都必须具有单一、无歧义、权威的表示。
8、正交性
就是不相依赖性和解耦性。
正交性使问题局部化，一个模块的问题不会扩散到其它模块；促进复用，便于与其它组件组合在一起；使系统更健壮；更利于测试。
项目团队的设置也有正交性的问题，尽量不要让2个团队的责任重叠。
面向对象的技术虽有许多好处，但也非常容易乱用，从而制造出非正交的代码来。
9、可撤消性
10、曳光弹
就是敏捷开发的理念，要即时反馈。
曳光代码与原型系统不是一回事，曳光弹是一个可以运转的整体，虽然功能不全；而原型通常只是一个界面，原型代码通常要丢弃。
11、原型与便笺
原型制作是一种学习经验。其价值并不在于所产生的代码，而在于所学到的经验教训。
12、领域语言
哪些时候需要给程序设计一种领域语言？我写的程序里还没有像VB自动化式的功能需求。
13、估算
估算一个软件项目到底要花多长时间来完成是一个不可能完成的任务。
看看这篇帖子提到的3种方法：
1）想要搞清楚一个事情需要多少时间完成，这最好的方法是找一个程序员已经完成的、相似的项目。对一些简单的网站和应用来说非常有效，或者那些使用标准CRUD的项目也是适用。当项目小且简单时这种方法最好用。这种方法可以用在软件1.0版本时，但以后的版本就不行了，因为这时你跟相参照的项目开始慢慢的产生差异，这时写的代码是你以前没有写过的。
2）我的好朋友、并且是以前的同事John Walker(不是这个John Walker)喜欢用这种方法。把项目拆解成最小的任务。然后记录完成每个任务你认为可能需要多少小时、天、周、月。遵循这种原则，如果一个任务需要几小时，就是算成一天，如果需要数天，就是算成一周，如果是数周，就算成一月。如果超过一个月，那你就无法知道需要多少时间了，或你根本不知道要做什么。
3）我有自己的预估方法，但事实上跟John的把任务拆分成最小的子任务的方法非常相似。我是以最坏的情况下每个最小单元需要的完成时间为标准。汇总，然后乘以4。再向上取舍到最近的素数，就算是对我的这种没谱的方法的讽刺吧。
第一章 注重实效的哲学
第二章 注重实效的途径
第三章 基本工具
第四章 注重实效的偏执
第五章：弯曲或折断
第六章：当你编码时
第七、八章