编程艺术

1.  不要构建大型应用

构建大型应用的秘诀就是“不要构建大型应用”，也就是把你的应用拆分成若干小应用，然后将这些可测试的小应用组装到一起。——Justin Meyer，JavaScript MVC作者 

2.  注重项目质量

当我听到“匆忙做出了能够运行的代码”，我也许不会去使用这些应用程序，因为它们会逐渐丧失可迭代的能力。——Avdi Grimm 

3.  不写代码

“Don’t write code”是每一个开发人员都需要学习的最重要的一条准则。目前存在大量重复的、蹩脚的代码（跨项目），在很多情况下，开发者甚至不去仔细看看周围有什么，他们只是一味地编写代码。 

4.  将减少产品中代码量作为目标

我讨厌代码，我希望在我们的产品中代码尽可能少。——Jack Diederich 

5.  保持最少依赖

经典格言“不要重新发明轮子”并不适用于火车头处的轮子（指项目的核心部分）。 

6.  停止编写类

“这不应该是一个类”，尤其是在类有两个方法，且其中一个是构造函数时。任何时候你看到这种情况时，你也许只应该写一个函数。——Jack Diederich 

7.  忘掉新功能，将同样的东西做得更好

开发者容易忽视而用户通常比较关心的东西是——应用程序中最常用功能的性能和可用性。——Tim Anderson 

8.  重新发明轮子

发明自己的轮子，可以让你更深刻地理解轮子如何工作，以及如何才能做得更好。 

9.  做容易的事情，而不是难的

• 简单比复杂好
• 复杂（Complex）比超复杂（complicated）好
• 顺序比嵌入好
• 可读性应当被重视
• 如果你的代码实现难以解释，这不是一个好的实现

——The Zen of Python（Python禅宗） 

10.  重写>重构

如果你正在更改一个类或方法超过25％的部分，你可以考虑重写，你的代码将会更加整洁。 

11.  重构>重写

重写一个项目的常见借口： 

• 代码很烂
• 我们现在更聪明了
• 我们选错平台/语言了

为什么重写（几乎）不是一个好主意： 

• 它总是需要比你预期更长的时间
• 市场在不断变化
• 现有客户会变得沮丧
• 重构也可以清理代码
• 你无法控制重写的代码，最后会变成它在控制你

12.  你不知道项目将如何增长

从一开始你就要承认，你不知道项目会如何增长。一旦你承认这一切，你就会开始防御性地设计系统……你应该花大部分的时间来考虑接口，而不是实现。——Nicholas Zakas，《高性能JavaScript网站》作者 

13.  避免代码味道（指代码中存在潜在问题）

14.  写单元测试

每个程序员都知道他们应该为自己的代码编写测试，但很少有人会这样做。问其“为什么不呢？”通常会回应“我太忙了。”这很快就会变成了一个恶性循环——你感到压力越大（越忙），你写的测试就会越少，你的代码也会变得不太稳定，你的生产力会越来越低。这样一来，你的压力就更大了（工作更忙了）。正是由于这样的恶性循环，导致程序员的编码热情降低。我们发现，有时一个简单的测试框架，就可以让工作有很大的不同。 

（没有单元测试）你不是在重构，你只是正在改变一堆狗屎。——Hamlet D'Arcy 

15.  测试驱动开发&控制反转（Inversion of Control）

即使你的代码不需要测试，你也应该编写可测试的代码。IoC（控制反转）可以帮你这样做。尝试在测试时注入对测试友好的依赖或模拟实例，并隔离受测试单元。 

16.  避免将对象创建与应用程序逻辑混合在一起

17.  避免创建技术债务

尽管不成熟的代码可以正常工作，客户也完全可以接受，但是最后出现的技术债务将会使你疲惫不堪，整个工作组也有可能会被这些技术债务困在原地。 

18.  过早优化是罪恶之源

一些程序员会浪费大量的时间去思考或担心程序中非关键部分的运行速度，而他们的这些尝试有可能会对最终的调试和维护产生负面影响。我们应该忘掉小的效率，在97%的时间内告诫自己“过早优化是罪恶之源”，但是，也一定不能在关键的3％上错过优化机会。 

19.  计划，计划，计划

首次就做正确的事情比稍后重做的代价要小得多，发现解决问题越早，代价就越小。 

夫未战而庙算胜者，得算多也；未战而庙算不胜者，得算少也。多算胜少算，而况于无算乎！吾以此观之，胜负见矣。——孙子兵法 

计划是无用的，规划是无价的。——温斯顿•丘吉尔 

20.  一个不断学习的编程团队

即使一个团队中的程序员平庸、缺乏经验，但如果他们都为团队利益而编写代码，就有可能会成为一支伟大的团队。这一切都要看该团队是否能够意识到他们的工作只是写代码或将写代码和学习作为首要目标。——Reginald Braithwaite 

21.  不断评估、完善

软件设计是一个迭代的过程，在一开始不可能什么都考虑到，需要在之后的过程中通过经验来不断完善。而且通常情况下，很少有软件项目能够完全按照预期来完成，随着项目的进展，对于项目的预期也会下降。 

22.  什么是架构

你的项目架构反映了什么？是医疗保健系统、会计系统、库存管理系统，还是rails、spring/hibernate、ASP？ 

软件产品的架构应该让所有人都很容易了解产品所要达到的目的，并且系统的架构应该反映系统的用例而不是它使用的框架。架构不是（或不应该是）关于框架的内容。架构不应该由框架支持。框架是我们要使用的工具，而不是要符合的架构。如果你的架构基于框架，那么它就无法基于你的用例。——Uncle Bob Martin，《尖叫的架构（Screaming Architecture）》作者 

23.  X-Windows系统设计原则

• 不用增加新的功能，除非没有它就无法完成一个真正完整的应用程序
• 决定一个系统不是什么和决定它是什么同样重要。你无法满足世界上所有人的需求，好的做法是，使系统可以以向上兼容的方式扩展，以便能够满足额外需求。
• 比从一个例子中归纳，更坏的是，没有可归纳的例子。
• 如果你不能完全了解一个问题，那么最好别提供任何解决之道。
• 如果预期要用90%的努力去完成10%的工作，那么应该用更简单的办法解决。
• 尽量避免复杂性
• 提供机制而不是策略，实践中把用户方面策略放在用户手里。

24.  Unix设计原则

• 模块化准则：编写简单的模块用清晰的接口把它们连接起来。
• 清晰性准则：清晰性优先于巧妙。
• 组合准则：设计可以和其他程序连接的程序。
• 分离准则：把政策和机制相分离；把接口和引擎相分离。
• 简单性准则：设计追求简单性，只在绝对必须时加入复杂性。
• 节俭准则：只在通过原型澄清后才编写大的程序。
• 透明性准则：设计的可见性使检查和除错更容易。
• 健壮性准则：健壮性是透明性和简单性的孩子。
• 表示准则：将知识包入数据，程序逻辑可以是笨拙和健壮的。
• 最小惊喜准则：在界面设计中，总是遵循最小惊喜准则（总是做令人惊喜的事情）。
• 沉默准则：如果程序没有重要的输出，它就应该保持沉默。
• 修复准则：如果你必须出错，尽可能响亮和快速的出错。
• 经济性准则：如果和机器时间比较，程序员的时间是昂贵的。
• 生成准则：避免手工编程，如果可能，编写编写程序的程序。
• 优化准则：在打磨前建立原型，在你优化前先使他工作。
• 多样性准则：怀疑一切声称“只能如此”的说法。
• 扩展性准则：为未来设计，因为它往往来的比你想得快。