一,所谓艺术,不立文字,直指人心,见性成佛。
二,Unix之失:安全模型不够完善。
三,Unix的十七大原则。
3.1 模块原则:简洁的接口拼接简单的部件,构件复杂的系统,降低编程复杂度。
3.2 清晰原则:让代码变得清晰,易于理解,而不是为了让程序高效,破坏清晰原则。
3.3 组合原则:设计时考虑拼接组合。
3.4 分离原则:策略与机制分离,接口与引擎分离。
3.5 简洁原则:设计要简洁,复杂度能低就低。
3.6 吝啬原则:除非别无他法,不要编写庞大的程序。
3.7
透明性原则:设计要可见,以便复查和调试。
3.8 健壮性原则:健壮源于透明与简洁。
3.9 表示原则: 把知识叠于数据,以求逻辑朴实而健壮。让数据复杂,而不是代码。
3.10 通俗原则:接口设计避免标新立异。
3.11 缄默原则:如果一个程序没什么好说的,就保持沉默。
3.12 补救原则:出现异常,马上退出,给出足够的信息。
3.13 经济原则:宁花极其一分,不花程序员一秒。如:Java的垃圾收集机制。
3.14 生成原则:避免手工去hack,让程序生成程序是最好的方式。
3.15 优化原则:先让程序运行起来,然后优化。
3.16 多样原则:绝不相信所谓的“不二法门”。
3.17 扩展原则:设计着眼于未来。
四,Unix哲学一言以蔽之:KISS原则。(keep it simple , stupid)
五,设计
5.1
模块化大小:过大或者过小的模块或函数都会导致bug的急剧增加。满足U型曲线。
5.2正交性:可以使复杂的设计变得紧凑。也就是不产生副作用的代码。重构的原则性目的就是提高正交性。
5.3
SPOT原则(Single Point
Of Truth)真理的单点性。
5.4
分离的价值:不要依赖他人,从零开始,从禅的初心开始。
六,分层。
6.1 自顶向下还是自底向上。主要是要看情况。如果能够精确预知的任务,在实现过程中,程序的规格不会有重大变化,在底层有充分自由选择实现方式,那么就适合采用自顶向下,逐步求精。
自底向上更是Unix程序的天性。
6.2 胶合层:要薄胶合层。
6.3 对OO语言的批判:面向对象语言往往让程序员不知道程序在做什么,会隐藏晦涩的bug。
7. 文本化
7.1 文本化配置文件增加透明性,方便修改和调试。
7.2 好的文本格式可以节约空间。
8. 透明性
8.1 清新的设计,清晰的文档,用简单的算法和数据结构贴近基面。
8.2 为可维护性而设计。
8.3 拿不准,用穷举。
9. 分离进程为独立的功能。
9.1 线程是一场噩梦。
9.2 美是抵御负责度的最后武器。
10 生成 :提升规格说明层次
10.1 数据比较程序的逻辑更容易理解。
10.2 数据驱动编程。
10.3 专用的代码生成工具。
11. 配置:
11.1 简化配置,降低负责度,让用户感觉舒服。
11.2 不要区分潜在的空格符号。
11.3 环境变量:到其他操作系统的可移植性。
11.4 命令行选项:
12 接口
12.1 所有的知识都来自我们自己的感知—达芬奇。
12.2 最小标新立异。接口应该尽量通俗化。
12.3标准:简洁,易用,表现力,透明,易于评估。
12.4 过滤器:Postle原则:宽进严出。
12.5 沉默是金:不要产生过多的垃圾信息,妨碍用户体验。
13. 优化
13.1 过早优化是万恶之源。
13.2 先估量,后优化。
13.3 最有效的优化方法:保持代码短小简单,让核心数据结构在缓存中。
14. 复杂度
14.1 尽可能简单,但是不能简单过头了。
15. 语言
15.1 学习C语言是为了帮助我们站在硬件的角度考虑问题。
15.2 自动化内存管理的语言才是王道。
15.3 python语言能够快速构造原型。
15.4 Java开发的项目:freenet有意思。
15.5 日本人开发的杂交体语言:Runy
16. 工具
16.1 vi
16.2 emacs
16.3 版本控制工具:SCCS,CVS
17 重用
17.1 不要重新发明轮子。
17.2 利用开源软件。
18.可移植性
18.1 C语言让Unix具有史无前例的移植性。
19 文档
19.1 简洁的文档,如果真的要复杂,做成手册。发布到网站。
20 开发源码
20.1 尽早发布,经常发布。
20.2 在freshmeat上发布通告。
21 未来: 危机与机遇
21.1 预测未来最好的办法就是创造未来。
完毕