Is anything more important than happiness? 

                                                          -- nosix

       最近在极客时间上学习《从0开始学架构》的课程，给自己充充电，晃晃悠悠敲了好几年代码了，也没有做出啥牛逼的事，还是得提升提升，这本书也是在学习课程的时候看到，正好赶上二手东618活动就入手了，学习笔记主要是记录下看书想记住的部分，没有啥高深的见解。

    上图就是本书提到的UNIX系统的设计哲学的精髓，之前一直没有听到过这么一个原则，作为一个程序员想想还是挺惭愧的😄。

    UNIX哲学（同其它工程领域的民间传统一样）是自下而上的，而不是自上而下的。UNIX哲学注重实效，立足于丰富的经验。

    每个人对事情都有自己的看法和总结

    一、Unix管道发明人，Unix传统的奠基人之一 Doug Mcllroy在[Mcllroy78]中曾说：

  （i）让每个程序就做好一件事，如果有新任务，就重新开始，不要往原程序中加入新功能而搞的复杂。

  （ii）假定每个程序的输入输出都会成为另一个程序的输入，哪怕那个程序还是未知的。输出中不要有无关信息的干扰，避免使用严格的分栏格式和二进制的格式输入。不要坚持使用交互式输入。

  （iii）尽可能早地降设计和编译的软件投入试用，哪怕是操作系统也不例外，理想情况下，应该是在几星期内，对于拙劣的代码别犹豫，扔掉重写。

  （iv）优先使用工具而不是拙劣的帮助来减轻编程任务的负担，工欲善其事，必先利其器。

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

二、Rob Pike, 最伟大的C语言大师之一，在《Notes on C Programming》中从另外一个稍微不同的角度表述了对Unix的哲学[Pike]:

    原则1：你无法断定程序会在什么地方耗费运行时间，瓶颈经常出现在想不到的地方，所以别急于胡乱找个地方改代码，除非你已经证明那儿就是瓶颈所在。

    原则2：估量，在你没对代码进行估量，特别是没找到最耗时的那部分之前，别去优化速度。

    原则3：花哨的算法在n很小时通常很慢，而n通常很小，花哨算法的常数负责度很大。除非你确定n总是很大，否则不要使用花哨算法（即使n很大，也优先考虑原则2）。

    原则4：花哨的算法比简答算法更容易出bug,更难实现。尽量使用简单的算法配合简答的数据结构。

    原则5：数据压倒一切，如果已经选择了正确的数据结构并且把一切都组织得井井有条，正确的算法也就不言自明，编程的核心是数据结构，而不是算法。

    原则6：没有原则

    Ken Thompson ---- Unix最初版本的设计和实现者，禅宗偈语般地对Pike的原则4做出了强调：拿不准就穷尽。

三、Unix 哲学中更多的内容不是这些先哲们口头表述出来的，而是由他们所做的一切和Unix本身所作出的榜样体现出来的。从整体上来说，可以概括为以下几点：

    1.模块原则：使用简介的接口拼合简单的部件。

    2.清晰原则：清晰胜于机巧。

    3.组合原则：设计时考虑拼接组合。

    4.分离原则：策略同机制分离，接口同引擎分离。（这句话我其实一点都理解不了）

    5.简洁原则:  设计要简洁，复杂度能低则低。

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

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

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

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

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

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

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

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

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

    15.优化原则：雕琢前先要有原型，跑之前先学会跑。

    16.多样原则：决不相信所谓“不二法门”的断言。

    17.扩展原则：设计着眼未来，未来总比预想来的快。

好记性不如烂笔头，好的原则在于不断用于实践，不是每一条都适用，让适用的规则提升自己的代码就好了😄。