构建信息系统的主要原则

读了"多些时间能少写些代码" （http://news.cnblogs.com/n/119370/），有点感慨。

构建信息系统的主要原则究竟是哪些？下面是俺心目中最重要的几点。如果大家有不同的看法，欢迎讨论。

1. 构建一个好系统的愿景
如果相关人员（经理，小组负责人，程序员）只是想混饭吃，就注定无法构建优秀的系统。

2. 理解业务需求
虽然不可能像业务人员一样熟悉所有细节，但整体上应该超过业务人员。如果可能，要让所有程序员都真正地理解业务。正如乔布斯，他基本上不会去询问客户的需求，因为他对“需求”的理解远远超过了普通大众。唯有如此，才能建造出杰出的系统。

只有真正理解了需求以后，才能在系统设计中加入未来可能需要的接口和模块（而不是过度设计），才能在开发过程中“抵制”客户的不合理需求改动要求，才能避免种种业务陷阱，开发出客户喜爱的功能。

3. 尽量利用已有的主流软件平台，减少开发
在软件开发过程中没有“银弹”。即使对优秀的程序员来说，要减少BUG，也必须做大量的测试和BUG修订。这意味着惊人的时间和成本。

成熟的商业软件系统虽然价格高昂，但其质量也远远高于一般公司里IT部门开发出来的东西。自己开发的系统，复杂性一旦到达某个级别，往往会事实上不可维护。这不仅仅意味着直接的维护成本，更会对公司的业务造成严重破坏和阻碍。

应该在成熟的系统里，通过少量二次开发来实现需要的功能。

4. 分阶段实施
不要试图实现所有的功能，不要试图构造完美系统。
业务需求中，总有一部分至关重要。实现了这一部分，就能为业务人员节省超过80%的时间。

一般都应该迅速构造这样一个1.0版本，并让业务人员尽早在上面工作。等系统稳定以后，再去构造2.0版本。

在系统的构造过程中出现的绝大部分新需求或者需求改动，都应该放入下一个版本。

5. 代码: "轻耦合", "模块化", "易读"
代码模块相互要独立，每个模块功能必须单一，而且同样的功能不应该在不同的模块中重复实现。

除了上面列出的这几条，易读性就是最重要的。在99%的场合下，性能一类的要素都不需要考虑。合理的系统架构本身就已经解决了性能问题。合理的程序代码（包括SQL语句）都足够快。

代码中嵌入的注释应该很少----优秀的代码本身就能解释逻辑。注释一般应该集中在模块的开头部分，阐述业务逻辑，帮助程序员理解业务需求。

在一个应用系统中，为了把局部性能提高10000倍而牺牲代码可读性，一般是不可接受的。（除了一些极其罕见的特例）

6. 代码: 垃圾进，垃圾出
这是最近才悟到的一个诀窍。

一般来说，对任何一个模块，都不应该去检测传入参数是否合法，更不应该试图去处理非法数据。唯一需要保证的是，合法的传入数据将产生合法的传出数据。这也是为了防止"过度设计"

为了避免垃圾数据，必须在源头上卡住。避免垃圾数据进入系统。

7. 代码: 只有异常，才抛出异常
可以预见的错误，都不应该导致异常（exception）

（"多些时间能少写些代码"是好文章，推荐！）