一，所谓艺术，不立文字，直指人心，见性成佛。
二，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 预测未来最好的办法就是创造未来。
完毕
3699
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
