Unix编程哲学：

1，模块原则：使用简洁的接口拼合简单的部件。

2，清晰原则：清晰胜于机巧。

3，组合原则：设计时考虑拼接组合。

4，分离原则：策略同机制分离，接口同实现引擎分离。

5，简洁原则：设计要简洁，复杂度能低则低。

6，吝啬原则：除非确无它法，不要编写庞大的程序。

7，透明性原则：设计要可见，以便审查和调试。

8，健壮原则：健壮源于透明与简洁。

9，表示原则：把知识叠入数据以求逻辑质朴而健壮。

10，通俗原则：接口设计避免标新立异。

11，缄默原则：如果一个程序没什么好说的，就沉默。

12，补救原则：出现异常时，马上退出并给出足够的错误信息。

13，经济原则：宁花机器一分，不花程序员一秒。

14，生成原则：避免手工hack，尽量编写程序去生成程序。

15，优化原则：雕琢前先要有原型，跑之前先学会走。

16，多样原则：绝不相信所谓“不二法门”的断言。

17，扩展原则：设计着眼未来，未来总比预想来得快。

另外：

一个程序只做一件事情，并做好。

程序要能协作。

程序要能处理文本流，因为这是最通用的接口。

来自《Unix编程艺术》一书。这些原则在很多软件工程，设计模式，敏捷开发书籍中都有提到。

有时因为设计问题受到同事的挑战。解释起来又挺麻烦的，不是三言两语能说明白的。 以后就把这些原则背出来，再遇到挑战就说是根据**原则设计的，如果不清楚看《Unix编程艺术》这本书或者敏捷开发的书，省得解释了。

一些人喜欢使用二进制协议，觉得文本协议太浪费资源。其实文本协议浪费不多（xml格式除外），能处理的程序多，纠错能力强。最主要的是便于人查看和编辑。

一些人为了提高机器执行效率，到处要求优化。其实很多是废的。甚至因为引入了bug起发作用。至少使代码更难理解。应该优化经测试真正的瓶颈，而不是想当然。

一些人喜欢用一个巨大的程序完成任务，而不是多个小程序。因为觉得线程间交互简单；而进程间交互复杂，而且要使用进程间通讯，效率低。多个小程序的好处是，提供了机制而不是策略。便于重用，具有更大的灵活性，能够满足多种需要。

而且能够积累不少可重用的工具，提高日后的开发效率。 有些公司办了很多年，一点积累都没有，每次来项目都要从头开始写。

如果不愿意或者不能分成多个小程序，至少也应该提供service和GUI层的逻辑上的隔离。这样service层等模块可以打包成动态链接库，jar包等，便于重用。

这样，至少如果有一天你的Web程序要提供openAPI（现在很流行）时，不需要大动干戈，重写很多代码。

另外，Linux等开源代码，之所以质量优秀，就是充分的源代码公开和源代码review。 建议公司在项目内形成开诚布公的源代码review风气，改善代码质量。当然这个在一些公司政治严重的团队很难实现。在程序员间容易产生矛盾。

15，优化原则：雕琢前先要有原型，跑之前先学会走。

<!-- @page { margin: 2cm } P { margin-bottom: 0.21cm } A:link { so-language: zxx } -->

一些工程师，喜欢瀑布式的开发方式。一上来设计文档写个几个月，未来描绘得非常美好。代码一行未动。

项目最后是一延再延，最后发现架构设计有根本性的问题，BUG修复很难，项目只能取消，或者彻底重写。

没有深入到问题内部，和它近距离接触，是很难在脑子中凭空想清楚整个技术方案的。

我喜欢先设计原型，搭起架子，找到有风险的技术问题，先予以解决。和问题近身肉搏，然后调整、重构，得到可工作的原型，同时也得到了设计方案。再一步步实施。

我很奇怪，一些工程师对问题还没想透，技术风险还没排除，就敢直接花大量的时间写详尽的设计方案!

如果是概要性质的，还可以理解，毕竟项目总体的设计不会有太大的改变。