软件工程好习惯

1. 20世纪80年代，丰田公司的流水作业线因为它在缺陷预防方法上的革新变得出了名的高效。每个发现自己的部门有问题的成员都有权暂停生产。这个方法意在宁可发现问题后马上暂定生产、解决问题，也不能由其继续生产而导致更棘手且更高代价的修复/更换/召回后的问题。

2. 代码设计是否糟糕，从某些地方就可以看出来。比如：
　　a. 超大类或超大函数
　　b. 大片被注释的代码
　　c. 逻辑重复
　　d. If/else嵌套过深

3. 如果你的团队突然失去了一个主力成员，你会怎么办？生意依旧进行还是戛然而止？
　　很不幸，大多数软件团队都陷入了后一种情况。这些团队把他们的开发人员培养成了只会处理他们自己专业领域的“领域专家”。起初，这看起来是一个比较合理的方法。它对汽车制造装配生产线很适用，但是为什么对软件开发团队就不行呢?毕竟，想让每个成员都掌握所编程序的细微差别也不太可能，对吧?问题是开发人员不容易轻易替换掉。虽然当每位成员都可用时，“抽屉方法”很有效，但如果当“领域专家”突然因人事变动、疾病或突发事故而无法工作 时，抽屉 方法立马土崩瓦解。(所以，)软件团队有一些看似多余实则重要的后备力量至关重要。代码复查、结对编程和共有代码可以成功营造一个环境，在这个环境中， 每位开发人员至少表面上是熟悉自己非擅长领域之外的系统部分。

4. 不要留着“破窗户”(低劣的设计、错误的决策或者糟糕的代码)不修。
　　发现一个就修一个。 如果没有足够的时间进行适当的修理，就先把它保留起来。或许你可以把出问题的代码放到注释中，或是显示“未实现”消息，或用虚拟数据加以替代。采取一些措施，防止进一步的恶化。这表明局势尚在掌控之中。
　　编程社区就好像一个现实社区。每个作品都是一个开发者的缩影。糟糕的代码发布的越多，就越容易反映现状。如果你不去努力编写优秀、整洁和稳定的代码，那你每天都将和糟糕的代码相伴了。
　　同样地，如果你看到别人写出了糟糕的代码，你就要跟这个人提出来。注意，这时候机智就应该用上场了。一般情况下，程序员都愿意承认他们在软件开发中还是有不懂的地方，并且会感谢你的好意。
    
5. 双鸟在林，不如一鸟在手
　　如果可以讨论系统架构和重构，那么就差找个时间把事情做完。为了使正常运作的东西更加简洁而做改动，权衡改动的利弊很重要。当然了，简洁是一个理想目标，但总会有可以通过重构改进的代码。在编程世界中，为了代码不过时，会频繁简单改动代码。但有时候你又必须保证代码对客户有价值。那么，你面临一个简单窘境：你不能一石二鸟。你在重构旧代码上所花时间越多，你编写新代码的时间就越少。在及时改进代码和维护程序之间，也需要找到平衡点。

6. 能力越大，责任越大

　　毫无疑问，软件已成为我们生活中一个既基本又重要的一部分。正因如此，开发优秀软件格外重要。乒乓球游戏中的Bug是一回事，航天飞机导向系统或者 航空交通管制系统中的Bug是另外一回事。Slashdot曾发表一文，讲述了单单Google News的一个小失误使一家公司股票蒸发11.4亿美元。其他例子参见《软件Bug引发的十次严重后果》。这些例子便说明了我们正行使着多大的权利。你今 天写的代码，无论你是否有意，说不定有朝一日在重要的应用程序中派上用场，这想想都令人害怕。编写正确合格的代码吧!

7. 一个程序员用在写程序上的时间大概占他的工作时间的10-20%，大部分的程序员每天大约能写出10-12行的能进入最终的产品的代码 — —不管他的技术水平有多高。 好的程序员花去90%的时间在思考、研究和实验，来找出最优方案。差的程序员花去90%的时间在调试问题程序、盲目的修改程序，期望某种写法能可行。

8. 伟大的程序员只花很少的时间去写代码——至少指那些最终形成产品的代码。那些要花掉大量时间写代码的程序员都是太懒惰，太自大，太傲慢，不屑用现有的方案去解决老问题。伟大的程序员的精明之处在于懂得欣赏和重复利用通用模式。好的程序员并不害怕经常的重构(重写)他们的代码以求达到最好效果。差的程序员写的代码缺乏整体概念，冗余，没有层次，没有模式，导致很难重构。把这些代码扔掉重做也比修改起来容易。

9. 尽管大多数软件都是团体开发的，但这并不是一项民/主的活动。通常，一个人负责设计，其他人负责实现细节。

10. 编程是个很难的工作。是一种剧烈的脑力劳动。好的程序员7×24小时的思考他们的工作。他们最重要的程序都是在淋浴时、睡梦中写成的。因为这最重要的工作都是在远离键盘的情况下完成的，所以软件工程不可能通过增加在办公室的工作时间或增加人手来加快进度。

11. 简单是稳定的前提，任何优秀的大软件里面都是一个个优秀的小程序。

12. 对于增加一个功能点所付出的代价，你要明白的很重要的一点就是，它不仅仅指开发这个功能所消耗的时间。它同时还包括带来的额外的给以后扩展造成的困难。不错，任何的功能特性都是能实现的——只要有足够的时间。除了这些将来会出现的问题外，你最终还会使你的程序变得脆弱，最终连一个绝对简单的功能都越来越难以和现有的混乱的web结合起来。应对此问题的办法是你应只接受那些不会导致冲突的功能。

13. 性能的关键是精简，而不是一堆的优化用例。除非有真正显著的效果，否则一定要忍住你那些蠢蠢欲动的小微调的企图。

14. 开发的越早，程序花费你的时间越长。

15. 原型的价值就在于它对你的教育，而不是代码本身。

16. 进行软件设计有两种方式：一种是尽量让它简单，以至于明显没有任何缺陷。而另一种是尽量复杂，以至于找不到明显的缺陷。

17. 丑陋的程序和丑陋的吊桥一样：他们都容易坍塌，因为人类（尤其是工程师们）的审美定义跟人们对复杂事物的处理和理解密切相关。一种编程语言如果不能使你写出优美的代码，那它也就不能使你写出好的程序。

18. 使用一致的注释风格
　　一些人坚信注释应该写到能被非编程者理解的程度，而其他的人则认为注释只要能被开发人员理解就行了。无论如何，Successful Strategies for Commenting Code已经规定和阐述了注释的一致性和针对的读者。就个人而言，我怀疑大部分非编程人员将会去阅读代码，因此注释应该是针对其他的开发者而言。

19. 为自己注释代码
　　当注释代码时，要考虑到不仅将来维护你代码的开发人员要看，而且你自己也可能要看。用Phil Haack大师的话来说就是：“一旦一行代码显示在屏幕上，你也就成了这段代码的维护者”。因此，对于我们写得好(差)的注释而言，我们将是第一个受益者(受害者)。