程序员修炼之道-从小工到专家

1、避开“破窗理论”
熵（Entropy），原本是一个物理学术语，软件行业却借用这个词来描述软件源代码混乱状态。

知名的“破窗理论”告诉我们，如果某地区的建筑老旧、窗口破裂，却不马上去休整，该地区就会被加速破坏。“反正这个地方都这样了，每人在乎。我多打破一个窗户，多砸烂一个路牌又如何？”居民是这样的心理，程序员也是这样的心理。不能让本位主义思想占据，不好的决策，不好的架构，不好的代码都是破窗，都要及时修正、重构。


2、用现有的资源做出合理的第一版系统是很关键的一步
我们可以用现有的资源做出合理的第一版系统，引起大家围观，然后不经意地说，“如果有人能帮我设计画面和交互，这系统一定会狠棒”、“如果有人能帮我设计数据库，这系统一定会更棒”......这样，大家会渐渐的加入，一同为这件事努力。要大家加入一个正在顺利进行的项目，会比要大家加入一个什么都没有的项目更容易。

3、一开始就要严格避免程序中存在重复的代码，并持续保持这样的态度。
程序中的两个地方可能会存在具有同样逻辑的代码，随着时间的变迁，逻辑需要作出改变，于是，一个地方的代码被修改，另一个地方的代码却被遗漏，这样，一颗定时炸弹正等着呗引爆。

4、正交系统
在数学上，X轴和Y轴成90度角相交，就是正交。也就是说，两个事物之间互相独立，改变其中一个不会影响另一个。良好的系统设计应该让系统的组成分子之间互相独立。

正交的目的是解耦合。除了要解系统内部的耦合，也要解系统与外面真实世界的耦合，设计系统时要特别注意这一点。
例如，会法规变了，行政区域变了、电话区号变了等状况发生时，系统中是不是也只有一个模块会受到影响呢？总之，设计系统时，不要对我们不能决定的事由任何依赖。

正交可能导致运行效率降低，且不好的正交设计可能导致耦合提高、代码重复。

评估正交程度的方式：如果团队之间需要密切的沟通，那就表示正交性很差。


5、曳光弹式开发
先动手，然后观察各种反馈，立即改进。
曳光弹的做法与原型系统的做法不同--我们希望写出来的曳光弹代码以后能被保留下来，但是原型系统的代码却是要被丢弃的。曳光弹系统会逐渐长大、逐渐完善。这是一种增量式的开发方式。

6、原型系统
快速地做出最终系统的某些部分，并用它来做概念证明或者沟通，然后丢弃之，不会真正在系统中使用这些代码。
适合用原型系统的场合：有风险的地方、以前没尝试过的地方、关键的地方。
原型系统可用来验证架构、新功能、外部数据的结构或内容、第三方工具或库、效使用者操作界面设计。

7、不管你的选择如何，我都建议你要选择精通一种方便的文字处理语言。如Perl\TCL等。

8、契约式设计
理念:每个函数都有被调用前要符合的条件及调用之后要符合的条件；每个类都具备调用过程中维持不变的条件。通过契约式设计的做法，代码中的问题可以尽早曝光，debug比较容易。


9、假设是很不明智的，任何假设都不应该存在。
如果我们确定某个假设一定成立，那么我们还是得在代码中使用断言。

写断言要注意以下事项：
A、断言的断言的语句用来判断真伪，执行断言的过程中不可以产生副作用（也就是不能造成任何环境的变化）。
B、编译器的选项可能会关闭断言，所以不能将一定要运行的代码放在断言中。
C、断言用来判断某个“绝对会（或绝对不会）成立”的假设，不可以用来进行正常的程序逻辑判断。


10、应该把细节独立出来，不要将其混在代码中。
多多把细节变成外部的配置。既然是配置，就可以随意调整，也与代码无关。这样的配置也称为“Metadata”。通常，Metadata在运行期间才会载入程序，不在编译期使用。
原则上，将抽象些在代码中，将细节写在Metadata中，