计算机编程的本质就是控制复杂度
要编写复杂软件而又不至于一败涂地的唯一方法就是降低其整体复杂度——用清晰的接口把若干简单的模块组合成一个复杂的软件。如此一来,多数问题只会局限于某个局部,那么就还有希望对局部进行改进而不至牵动全身。
清晰原则 (清晰胜于技巧)
维护成本是高昂的,在写程序时,要想到你不是写给执行代码的计算机看的,而是给人——将来阅读维护源码的人,包括你自己看的。
在Unix传统中,这个建议不仅意味着代码注释。良好的Unix实践同样信奉在选择算法和实现时就应该考虑到将来的可扩展性。为了取得程序一丁点性能的提升就大幅增加技术的复杂性和晦涩性,这个买卖做不得——这不仅仅是因为复杂的代码容易滋生bug,也因为它会使日后的阅读和维护工作更加艰难。
组合原则 (设计时考虑拼接组合)
如果程序彼此之间不能有效通信,那么软件就难免会陷入复杂度的泥淖。
在输入方面,Unix传统极力提倡采用简单、文本化、面向流、设备无关的格式。在经典的Unix下,多数程序都尽可能采用简单过滤器的形式,即将一个简单的文本输入流处理为一个简单的文本流输出。
Unix程序员偏爱这种做法并不是因为它们仇视视图界面,而是因为如果程序不采用简单的文本输入输出流,它们就极难衔接。
要想让程序具有组合性,就要使程序彼此独立。在文本流这一端的程序应该尽可能不要考虑到文本流另一端的程序。
分离原则 (策略同机制分离,接口同引擎分离)
把策略同机制揉成一团有两个负面影响:一来会使策略变得死板,难以适应用户需求的改变,二来也意味着任何策略的改变都可能会动摇机制。
可以将应用程序分成可以协作的前端和后端进程,通过socket专用应用协议进行通讯。这种双端设计方法大大降低了整体复杂度,bug有望减少。
简洁原则 (设计要简洁,复杂度能低就低)
来自多方面的压力常常会让程序变得复杂(bug更多),其中一种压力就是来自技术上的虚荣心理。Unix程序员相互比的是谁能够做到”简洁而漂亮”并以此为荣。
更为常见的是,过度的复杂性往往来自于项目的需求,要避免这种状况,就需要鼓励一种软件文化,以简洁为美,人人对庞大复杂的东西群起而攻之。
吝啬原则 (除非确无它法,不要编写庞大的程序)
“大”有两重含义:体积大,复杂程度高。程序大了,维护起来就困难。由于人们对花费了大量精力才做出来的东西难以割舍,结果导致在庞大的程序中把投资浪费的注定要失败或者并非最佳的方案上。
透明原则 (设计要可见,以便审查和调试)
软件系统的透明性是指你一眼就能够看出软件是在做什么以及怎样做的。显示性是指程序带有监视和显示内部状态的功能。
设计时如果充分考虑到这些要求会给整个项目全过程都带来好处。至少,调试选项的设置应该尽量不要在事后,而应该在设计之初便考虑进去。这是考虑到程序不但应该能够展示其正确性,也应该能够把原开发者解决问题的思维模型告诉后来者。
程序如果要展示其正确性,应该使用足够简单的输入输出格式,这样才能保证很容易地检验有效输入和正确输出之间的关系是否正确。
出于充分考虑透明性和显见性的目的,还应该提倡接口简洁,以方便其他程序对它进行操作。
健壮原则 (健壮源于透明与简洁)
软件的健壮性指软件不仅能在正常情况下运行良好,而且在超出设计者设想的意外条件下也能够运行良好。
大多数软件禁不起磕碰,毛病很多,就是因为过于复杂,很难通盘考虑。如果不能够正确理解一个程序的逻辑,就不能确信其是否正确,也就不能在出错时修复它。
这也就带来了让程序健壮的方法,就是让程序的内部逻辑更易于理解。要做到这一点主要有两种方法:透明化和简洁化。
上面曾说过,软件的透明性就是指一眼就能够看出是怎么回事,即人们不需要绞尽脑汁就能够推断出所有可能的情况,那么这个程序就是简洁的。程序越简洁,越透明,也就越健壮。
----烟台软件开发----