第一章：哲学

1.机制，而不是策略

机制是解决问题的框架步骤，策略是解决问题得具体方法。策略相对短寿，而机制才能长存。

2.一个程序只做一件事，并做好。程序要能协作。程序要能处理文本流，因为这是最通用的接口。

不要向程序里加入花哨不切实际的内容。可以通过进程间通信来进行协作，书中认为不如文本流（不知多进程协作的程序和并行编程是不是有同样的效果和效率）。

3.在没有对代码估量前不要优化速度。

尚未触及的东西：优化速度。

4.模块原则：使用简洁的接口拼合简单的部件

Brian Kernighan说“计算机编程的本质就是控制复杂度。”用清晰的接口把模块组合到一起就是降低整体复杂度的方法。

5.清晰原则：清晰胜于机巧

做好代码注释，在选择算法和实现时就应考虑到将来的可扩展性。复杂代码容易滋生Bug

6.组合原则：设计时应考虑拼接组合

使用文本流衔接程序。

7.分离原则：策略同机制分离，接口同引擎分离。

分离方法之一：将应用按照一个库来编写，这个库包含许多由内嵌脚本语言驱动得C服务程序。而至于整个应用的控制流程则用脚本来撰写而不是用C语言。例子就是Emacs。

分离方法之二：将应用程序分成可以协作的前端和后端。通过套接字通信，前端实现策略，后端实现机制（？）。

8.简洁原则：设计要简洁，复杂度能低就低。

“过渡复杂来源于项目的要求，这些要求被公司当做推销热点。庞大臃肿变成了业界的标准，每个人都在使用臃肿不堪、bug极多得软件，连软件开发人员也不敢敝帚自珍。”目前确实如此！比如现在的搜狗输入法。我要的只是一个输入法。

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

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

编程开始就设计调试选项。实践用调试脚本调试程序。

11.健壮原则：健壮源于透明与简洁。

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

数据比程序逻辑更容易驾驭。设计中要主动将代码得复杂度转移到数据中。（怎么实现？）

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

认清“默认”这种意识。

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

“沉默是金”。

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

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

正确使用高级语言。

17.生成原则：避免手工hack,尽量编写程序去生成程序。

“用程序生成程序”！

18.优化原则：琢磨前先得有原型，跑之前先学会走。

类似极限编程：先求运行，再求正确，最后求快。用C前可先用解释性语言搭建程序。不要迷信需求分析。

19.多样原则：绝不相信所谓“不二法门”的断言

不止运用于编程方面。科学的精神就是怀疑一切。

20.扩展原则：设计着眼于未来，未来总比预想快

21.K.I.S.S

Keep It Simple,Stupid!!!

发表评论