[沧海拾遗]读＜Linux/Unix设计思想＞个人所思

＜Linux/Unix设计思想＞一书主要介绍了unix系统设计中的一些原则，其中包含了九个主原则和十个原则。

九大主原则

• SMALL

即“小即是美”。小则灵活，并易于改变去适应变化。而大则牵一发而动全身，一旦改变就会伤筋动骨。说到这个原则，就想起我们it界那个长久以来口口相传的笑话，说工程师老是被pd说改需求改需求，从而狂燥甚至发狂。笑一笑后，是不是该想一想，之所以出现这么难以改变的情况，是不是将系统设计和实现得太过大了呢？所以才会在有变化的时候如果痛苦？

• 1THING

即“让程序只做一件事”。这类似于OOP编程思想中的SRP原则(单一职责)，以前理解这个原则大约是觉得这样做的一个理由这样易于维护，或者可读性强上。但是看了这本书的介绍后发现，单一职责的优点不仅在可读性和维护性这些上面，还在性能上。因为一个方法如果小，则在调用完毕后，它使用的局部变量等就可以马上回收，降低资源的开销。

• PROTO

即“尽快建立原型”。这里提到的一个产品的三个系统感觉相当有意思。所谓三个系统分别是：第一系统，是指在资源紧迫情况下，而开发的预研性质的系统；第二系统是在第一个系统出现后，看到第一个系统的价值后，也看到第一个系统实践的结果后而产生的，在第一系统的基础上做出大量的优化和扩展；第三系统是在第一和第二系统出现后，去芜存精，最终比较完美的一个产出。如果投身于第一个系统的开发，你要冒很大的风险，因为它极有可能失败，但是在开发第一个系统的团队中工作将是一件最有激情的事.如果投向第二个系统，前期还好，你有可能接触到最顶尖的设计，但是到后期，就没意思了，就是重复的添加功能而已。不过不经历第一系统的后期也无法进入第三系统，所以在工作中，评估产品的阶段，选择投向其中，未尝不是一个好的方法。

• PORT

即“可移植性高于效率”。之所以推崇这个是因为作者认为计算机的性能总是越来越强，因此效率应该不是程序关心的第一优先级，但是向更高性能计算机的移植性却是程序应该关注的。这个我觉得倒是有所保留，近年来随着处理数据的海量化、什么云啊，大数据啊，就说明现在的计算机的性能增长速度还赶不上我们要处理的数量量增长速度。而且最近几年并发编程为什么这么火，因为硬件生产商已经无法保持业界的摩尔增长率了，所以只能通过软件的方式来保持性能的增长。而并发多核的编程就是在这种情况被程序员所追捧。

• FLAT

即“使用纯文本来存储数据”。为什么呢？因为这样可以使数据具有最大的可移植性。

• REUSE

即“充分利用软件的杠杆效应”。在编程中有一个原则尽量去重用别人已有的代码，来提高自己的工作效率。但是有时候你不得不承认，去读懂一些人写得代码，远没有自己重写来得简单。因此如果你要重用别人的代码，那么尽量重用一些优质的代码吧，并且要时刻提醒自己，别人的代码是不安全的。。。

• SCRIPT

即“尽量使用shell脚本”。普适地来讲，就是我们在实现程序时尽量选择一些可移植性高的编程语言，比如说java。

• NOCUI

即“避免强制性用户界面”。这个不是太好理解，也没遇到过这种场景，以后再说。。。

• FILTER

即“将程序用途过滤器”。就是使程序拥有输入、输出和异常处理，这样就可以将一个大型程序分解成若干个过程，并相互约定沟通方式，这不就是我们多人并发完成某项功能所需要做的事情吗？

十大次原则

• custom

即“让用户定制系统”。这个对于选择linux的人来说很有感受，什么东西都想控制在自己手中。但是说到底还是要了解你的产品所面向的群体对这个产品的定位，有些人就是想傻瓜一点，那就傻瓜一点吧。

• kernel

即“使内核最小化”。这也符合了小即是美的原则，如果将系统内核设计得小而轻量，然后其他人可以自由的在此基础上扩展，这就是一个完美的方案了。成为其他人的平台，进而构建一个生态圈，是由小变大，立于不败的不二法则。

• lcase

即“统一小写”。这个属于个人风格了。

• trees

即“不要将数据固化到纸上，节约树林”。

• silence

即“沉默是金”。指有些场景不需要向用户反馈信息时，就不要反馈。

• parallel

即“并行思考”。多核计算机总要发挥它的作用吧。

• sum

即“部分之和大于整体”。这个取决于一个好的设计，如果将各部分组合成整体的成本太大，则有可能部分之和小于整体了。

• 90percent

即“寻找90%的解决方案”。这个大家估计深要体会，有时候为了解决那10％甚至1％才会出现的问题，往往要投入巨大的精力，这个时候舍弃那1％的杞人忧天也许未尝不是一个好的抉择。不过如果你要冲向巅顶的话，你势必要面临这1％的挑战，这也是程序员乐此不疲的事情。

• worse

即“更坏就是更好”。不过理解起来似乎是与其做不好，还不如选择一个已有较差的方案。

• hier

即 “层次化思考”。对系统、软件分层，有利于维护开发。