Unix_哲学原则
模块原则
计算机编程的本质就是控制复杂度.
复杂度不是机器的短处, 而是人的短处. 过分复杂会大大提升出错的概率和排错的难度. 因此, 模块化主要的目的地于将一件复杂的大事, 变成许多简单的小事.
组合原则
在经典的 Unix 下, 多数程序尽可能采用简单过滤器的形式, 即将一个输入的简单文本流处理为一个简单的文本流输出 ... ... 因为如果程序不采用简单的文本输入输出, 它们就极难衔接.
所以正则表达式, sed, awk 才如此重要. 而所以习惯使用 windows 的中国, 正则表达式没有被很好的推广.
当程序无法自然地使用序列化, 协议形式的接口时, 正确的 Unix 设计至少是, 把尽可能多的编程无素组织成一套定义良好的 API.
定义 API 是在定义编程无素的组织形式.
分离原则
把策略同机制揉成一团有两个负面的影响: 一来会使策略变得死板, 难以适应用户需求的改变, 二来也意味阒任何策略的改变都极有可能动揺机制.
首先, 我们要区分出什么是机制, 什么是策略
简洁原则
过度的复杂度往往来自于项目的要求, 而这一要求常常基于当月的推销热点, 而不是基于顾客的需求和软件实际能够提供的功能.
规模厄杀质量的又一例.
透明性原则
软件系统的透明性是指你一眼就能够看出软件是在做什么以及怎样做的.
一切优雅的代码都应该是透明的.
程序不但应该能够展示其正确性, 也应该能够把原开发者解决问题的思维模型告诉读者.
代码背后是思想, 如果不能清晰的反应开发者的思想, 多多少少也说明开发者的思想本身不够清晰.
表示原则
即使最简单的程序逻辑让人类来验证也很困难, 但是就算是很复杂的数据, 对人类来说, 还是相对容易地就能够推导和建模的.
这就是为什么面向对象, 这也是为什么要进行建模. 抽象是理性之源.
通俗原则
关注受众 ... ... 关注传统惯例.
良好的迭代, 反而需要传统惯例的支撑.
补救原则
"宽容地改, 谨慎的发"
在一般的管理原则中, 也要求谨慎交付. 系统协作必须要求向下游负责.
优化原则
先制作原型, 再精雕细琢. 优化之前先确保能用. 或者说, 先能走, 再学跑 ... ... 先能运行, 再求正确, 最后求快.
正是在这样一个思路下, linux 才在开源社区中被集体开发出来.
也由此可见, 敏捷方法和 unix 哲学的一脉相承.
目前, 最强大的优化工具恐怕就是 delete 键了.
禅?