Unix哲学

准备操作系统的课程介绍，发现了些大牛们总结的UNIX方面的设计和开发哲学。简单翻译如下

Eric Raymond’s 17 Unix Rules

In his book  that was first published in 2003, , an American programmer and open source advocate, summarizes the Unix philosophy as  of "Keep it Simple, Stupid." He provides a series of design rules:

// 核心的思想是 KISS ， 思路和代码都要简单

• Rule of : Developers should build a program out of simple parts connected by well defined interfaces, so problems are local, and parts of the program can be replaced in future versions to support new features. This rule aims to save time on debugging code that is complex, long, and unreadable. // 模块化原则。程序由多个模块组成；模块要有精制的接口，以便各模块可方便地升级。
• Rule of Clarity: Developers should write programs as if the most important communication is to the developer, including him- or herself, who will read and maintain the program rather than the computer. This rule aims to make code readable and comprehensible for whomever works on the code in future.  // 清晰原则。 代码要写的清晰，要提高代码可读性、可理解性；因为软件生命周期中，更重要的交流不是代码与机器的交流（程序运行），而是开发者之间的交流，包括一个开发者在不同时间段内对同一段代码的理解，还包括不同开发者对同一段代码的理解。
• Rule of Composition: Developers should write programs that can communicate easily with other programs. This rule aims to allow developers to break down projects into small, simple programs rather than overly complex monolithic programs. //构件原则。将大的项目划分为多个简单的、功能集中的程序。比如Oracle数据库管理系统，运行时会有大概三类进程：用户进程、服务进程、后台进程，而后台又由系统监控进程、进程监控进程、数据库写入进程、日志写入进程、检查点写入进程等。 
• Rule of Separation: Developers should separate the mechanisms of the programs from the policies of the programs; one method is to divide a program into a front-end interface and back-end engine that interface communicates with. This rule aims to let policies be changed without destabilizing mechanisms and consequently reducing the number of bugs.//分离原则。前台与后台要分离、业务要与实现机制分离，分离后可对各部分方便地采用最优技术开发、并行开发，也便于后期维护。
• Rule of Simplicity: Developers should design for simplicity by looking for ways to break up program systems into small, straightforward cooperating pieces. This rule aims to discourage developers’ affection for writing “intricate and beautiful complexities” that are in reality bug prone programs.//简单原则。 不要试图写很复杂很高深的程序，任何人写的任何程序都可能出bug。
• Rule of Parsimony: Developers should avoid writing big programs. This rule aims to prevent overinvestment of development time in failed or suboptimal approaches caused by the owners of the program’s reluctance to throw away visibly large pieces of work. Smaller programs are not only easier to optimize and maintain; they are easier to delete when deprecated. //简约原则。 。。。 我没有找出parsimony和simplicity的区别。
• Rule of Transparency: Developers should design for visibility and discoverability by writing in a way that their thought process can lucidly be seen by future developers working on the project and using input and output formats that make it easy to identify valid input and correct output. This rule aims to reduce debugging time and extend the lifespan of programs. // 透明规则。写的代码要能体现你的思路，称之为代码可见化、可发现化；而且要能让别人知道什么是有效的输入、什么是正确的输出。  我认为这个和Clarity原则是一样的，代码要能体现思路，或者通过工整化的行文或者通过严谨的注释。
• Rule of Robustness: Developers should design robust programs by designing for transparency and discoverability, because code that is easy to understand is easier to stress test for unexpected conditions that may not be foreseeable in complex programs. This rule aims to help developers build robust, reliable products. //健壮性原则。在代码透明原则和可发现化的基础上，要能健壮，即让自己和别人很轻松地预见代码运行的情况，做出各种测试用例。
• Rule of Representation: Developers should choose to make data more complicated rather than the procedural logic of the program when faced with the choice, because it is easier for humans to understand complex data compared with complex logic. This rule aims to make programs more readable for any developer working on the project, which allows the program to be maintained.//表示原则（这个词不能说明问题）。程序开发过程中，如果一定要复杂，那就是设计更复杂的数据结构，而不是更复杂的处理逻辑。因为对人来说，数据结构能更直观的体现业务，看到数据组成，即很快懂得其意义及可能的操作；到要让你看一个处理流程，第一步怎么做，第二步有哪些条件，第三步有哪些分支，这种流式的、细节化的方式不能给人以直观的感受，所以尽量不要用复杂的处理逻辑。    这点深有体会，找时间回忆回忆具体的例子。
• Rule of Least Surprise: Developers should design programs that build on top of the potential users' expected knowledge; for example, ‘+’ should always mean addition in a calculator program. This rule aims to encourage developers to build intuitive products that are easy to use. //少惊喜原则。开发的程序要符合大众思维，比如碰到“+”号，在计算器程序中就是加法，不要在代码中设置成乘法，虽然你完全可以这样做，因为你是创造程序的上帝。
• Rule of Silence: Developers should design programs so that they do not print unnecessary output. This rule aims to allows other programs and developers to pick out the information they need from a program's output without having to parse verbosity.//安静原则。 不要整一堆无谓的输入，不必要的信息就不要显示了。
• Rule of Repair: Developers should design programs that fail in a manner that is easy to localize and diagnose or in other words “fail noisily”. This rule aims to prevent incorrect output from a program from becoming an input and corrupting the output of other code undetected. //修复原则。与安静原则相反，对于错误处理情况，一定要noisily，要能容易地进行错误定位，不管是错误代码位置和错误原因。
• Rule of Economy: Developers should value developer time over machine time, because machine cycles as of the year 2013 are relatively inexpensive compared to prices in the 1970s. This rule aims to reduce development costs of projects.//经济原则。不要为了某些性能的节俭，就大费周章地复杂程序，会提升开发成本。
• Rule of : Developers should avoid writing code by hand and instead write abstract high-level programs that generate code. This rule aims to reduce humans errors and save time. //生成原则。尽量避免一行一行地手敲代码。比如设定好类的属性后，通过工具可方便地生成setter、getter，设置好接口后，实现类里的方法就不要手写了。
• Rule of : Developers should  software before polishing it. This rule aims to prevent developers from spending too much time for marginal gains. //优化原则（用“原型原则“这个词应该更好一些）。 软件工程里的”原型开发模型“，尽量不要一步一步地系那个清楚了再做，而是先出个原型，不断优化。
• Rule of Diversity: Developers should design their programs to be flexible and open. This rule aims to make programs flexible, allowing them to be used in other ways than their developers intended.//多样化原则（灵活原则）。 程序内部要更灵活，程序员除了对现有需求完成外，要能预见未来可能的需求变动，程序要进行相应地设计和开发。
• Rule of Extensibility: Developers should design for the future by making their protocols extensible, allowing for easy plugins without modification to the program's architecture by other developers, noting the version of the program, and more. This rule aims to extend the lifespan and enhance the utility of the code the developer writes.//可扩展原则。模块接口预留变动区，协议能可扩展，这个需要很丰富的开发经验。

---

Worse is better

 suggests that a key advantage of Unix was that it embodied a design philosophy he termed "worse is better", in which simplicity of both the interface and the implementation are more important than any other attributes of the system—including correctness, consistency, and completeness. Gabriel argues that this design style has key evolutionary advantages, though he questions the quality of some results.

For example, in the early days Unix was a  (which means that user processes carried out kernel system calls all on the user stack). If a signal was delivered to a process while it was blocked on a long-term  in the kernel, then what should be done? Should the signal be delayed, possibly for a long time (maybe indefinitely) while the I/O completed? The signal handler could not be executed when the process was in kernel mode, with sensitive kernel data on the stack. Should the kernel back-out the system call, and store it, for replay and restart later, assuming that the signal handler completes successfully?

In these cases  and  favored simplicity over perfection. The Unix system would occasionally return early from a system call with an error stating that it had done nothing—the "Interrupted System Call", or an error number 4 (EINTR) in today's systems. Of course the call had been aborted in order to call the signal handler. This could only happen for a handful of long-running system calls such as read(), write(), open(), and select(). On the plus side, this made the I/O system many times simpler to design and understand. The vast majority of user programs were never affected because they didn't handle or experience signals other than SIGINT or Control-C and would die right away if one was raised. For the few other programs—things like shells or text editors that respond to job control key presses—small wrappers could be added to system calls so as to retry the call right away if this EINTR error was raised. Thus, the problem was solved in a simple manner.

//不明觉厉。需要很深厚的计算机底层知识、操作系统实现原理才能读懂。

 

---

Quotes

 

    "Unix is simple. It just takes a genius to understand its simplicity." – Dennis Ritchie 

    "Unix was not designed to stop its users from doing stupid things, as that would also stop them from doing clever things." – Doug Gwyn

    "Unix never says 'please'." – Rob Pike

    "Unix is user-friendly. It just isn't promiscuous about which users it's friendly with." – Steven King

    "Those who don't understand Unix are condemned to reinvent it, poorly." – Henry Spencer