Unix哲学
共享文化（Sharing Culture）
UNIX 开发哲学重视知识和技能的分享，不仅传递显性的操作方法，还传播隐性的文化和理念。Unix 社区通过共享文化，鼓励开发者学习并内化良好的设计思想，而不仅限于操作技巧。
设计理念与实用性
Unix 强调简洁、高效、可维护的设计，这不仅是一种方法论，更是一种哲学信仰。Unix 哲学提倡避免臃肿、难维护、难移植的软件设计，注重“做一件事，且做到最好”的单一功能性设计，适合在多环境下进行扩展和维护。
良好设计的标准
Unix 认为良好的设计具备轻量、可移植、易维护和可扩展性等特征。这种设计不仅解决当前需求，还应具有面向未来变化的灵活性。良好设计的标准是使软件更加“Unix 风格”，即通过小而精的组件组合，实现复杂功能。
000.wiki/《Unix编程艺术》 总结
- 模块原则：使用简洁的接口拼合简单的部件
- 清晰原则：清晰胜于机巧
- 组合原则：设计时考虑拼接组合
- 分离原则：策略同机制分离，接口同引擎分离
- 简洁原则：设计要简洁，复杂度能低则低
- 吝啬原则：除非却无它法，不要编写庞大的程序
- 透明性原则：设计要可见，以便检查和调试
- 健壮原则：健壮源于透明与简洁
- 表示原则：把知识叠入数据以求逻辑质朴而健壮
- 通俗原则：接口设计避免标新立异
- 缄默原则：如果一个程序没什么好说的，就沉默
- 救补原则：出现异常时，马上退出并给出足够错误信息
- 经济原则：宁花机器一分，不花程序员一秒
- 生成原则：避免手工 Hack，尽量编写程序去生成程序
- 优化原则：雕琢前先得有原型，跑之前先学会走
- 多样原则：决不相信所谓“不二法门”的断言
- 扩展原则：设计着眼未来，未来总比预想快
道格·麦克罗伊 总结
总结：Unix 哲学是这样的：一个程序只做一件事，并做好。程序要能协作。程序要能处理文本流，因为这是最通用的接口。
具体：
- 每个程序做好一件事。如果有新任务，就重新开始，不要往原程序中加入新功能而搞得复杂。
- 假定每个程序的输出都会成为另一个程序的输入，哪怕那个程序还是未知的。输出中不要有无关的信息干扰。避免使用严格的分栏格式和二进制格式输入。不要坚持使用交互式输入。
- 尽可能早地将设计和编译的软件投入使用，哪怕是操作系统也不例外，理想情况下，应该是在几星期内。对拙劣的代码别犹豫，扔掉重写。
- 优先使用工具而不是拙劣的帮助来减轻编程任务的负担。工欲善其事必先利其器。
Rob Pike 在 《Notes on C Programming》 中的总结
- 原则1：你无法断定程序会在什么地方耗费运行时间。瓶颈经常出现在想不到的地方，所以别急于胡乱找个地方改代码，除非你已经证实那儿就是瓶颈所在。
- 原则2：估量。在你没对代码进行评估，特别是没找到最耗时的那部分之前，别去优化速度。
- 原则3：花哨的算法在 n 很小时通常很慢，而 n 通常很小。花哨算法的常数复杂度很大。除非你确定 n 总是很大，否则不要用花哨算法（即使 n 很大，也优先考虑原则2）。
- 原则4：花哨的算法比简单的算法更容易出 bug、更难实现。尽量使用简单的算法配合简单的数据结构。
- 原则5：数据压倒一切。如果已经选择了正确的数据结构并且把一切都组织得井井有条，正确的算法也就不言自明。编程的核心是数据结构，而不是算法。
- 原则6：没有原则6。
- 肯·汤普森 对原则4的进一步总结：拿不准就穷举。
Brian W. Kernighan
- （i）让每个程序做好一件事。要做一件新的工作，就构建新程序，而不是通过增加新“特性”使旧程序复杂化。
- （ii）预期每个程序的输出都能成为另一个未知程序的输入。不要用无关的信息来干扰输出。避免使用严格的分栏对齐或二进制输入格式。不要执着于交互式输入。
- （iii）设计和构建软件，甚至是操作系统，要尽早试用，最好是在几周内就用起来。大刀阔斧砍掉笨拙的部件，重建它们。
- （iv）宁可绕道构建用后即弃的工具来减轻编程负担，也别依赖经验欠奉的帮助。
本文作者：Maeiee
本文链接：Unix哲学
版权声明：如无特别声明，本文即为原创文章，版权归 Maeiee 所有，未经允许不得转载！
喜欢我文章的朋友请随缘打赏，鼓励我创作更多更好的作品！
