现在说到操作系统，Android、ios、Linux、macos、windows是最受关注的。很少有人使用Unix系统，除了一些内部系统，用来和编程爱好者社区交流之外，基本上已经销声匿迹了。但是在一些行业，因为会和高端服务器配套使用，而HP和IBM是服务器的王者，像AIX这样的类UNIX系统还在使用，orcale和emc等公司还在使用他们。使用。也许你没看懂，但没关系，你可以选择强行背下来，下次可以跟朋友吹牛。说到Unix，不得不提一个人，EricStevenRaymond，他是老黑客，作家，自由软件的倡导者和先驱，很多人可能不太了解他，但是这本书很有名——《UNIX编程艺术》，就算你没看过，也可能在网上闲逛的时候看到了这本书的名字。最近也在看他写的另一本书《大教堂与大集市》，深受启发。读书的时候看过《UNIX编程艺术》这本书，但是完全看不懂。它充满了关于如何更好地编程的抽象事物。然而，我还是咬着牙勉强看了下去。后来更多的是练习编程。之后，你就可以逐渐了解它的本质了。现在想起来，关于思维原理的参考点很多，就拿出来和大家一起细细品味。最著名的是他提出的17条编程原则。经过时间和实践，他发展成为Unix哲学的17条原则，可以在维基百科上找到。先说说我对这17条原则的解读——1.RuleofModularity（模块化规则）原文：开发者应该使用定义良好的接口来连接简单的部分来构建程序，所以问题是局部的，部分程序可能会被替换在未来版本以支持新功能。此规则旨在节省调试复杂、冗长且不可读代码的时间。解读：这个规则，现在学编程的人都知道，代码要模块化，这样既方便别人复用，也能更方便的替换新代码。其实模块化的原则是一个很好的原则，无论是学习还是实践。比如我们在学习写作的时候，如果能把一篇文章分成几个模块，通过逻辑线索把它们串联起来，就可以组成一篇好文章。其实模块化的原理在起作用，我们常说的格式化写作就是这样的。因为模块是可更换的，模块是组成一堵墙的单元结构，可以是漂亮的空心砖，也可以是纯色的实心砖。同样，在工作中也很实用。把不同的大任务分解成不同的小人物和模块，一个一个分解，也很实用。关键是模块化是可重用和可替换的。2.RuleofClarity（清晰规则）原文：开发者应该写出清晰的程序，好像最重要的沟通是给开发者阅读和维护程序，而不是给计算机。这条规则的目的是让代码尽可能的可读易懂，以供以后的代码使用。解读：编程中的清晰度，就是别人看了你写的代码，能明白其中的意思。同样，在学习上也应该如此，就像我们写作是为了整理自己的思路，表达出来让别人理解，看起来你在编码，但实际上你在与他人交流。说一些含糊不清的话很容易，但为了让你的想法得到传达，清晰度非常重要。3.RuleofComposition原文：开发者应该编写能够方便地与其他程序通信的程序。这条规则的目的是让开发人员将项目分解成小而简单的程序，而不是过于复杂的单体程序。释义：又称适当妥协原则。这个道理更多的用在人际交往上，也用在自我思考上。比如有一天我们想运动跑5公里，那么感性会说，算了，有点冷，难得换衣服，床很舒服，但是理智会说，一定要坚持，在为了保持健康。于是，两人开始商量，最终商量后，就变成了跑步穿暖和一点，适当减少运动量的事情。在与人交流时，我们有时会面临自己的时间与他人的时间发生冲突。这个时候，我们就需要适当的调和，达成共识。和好的原则更像是一个做人的原则，让我们不能一味的强调自己，而是要照顾别人的感受。4.分离规则（RuleofSeparation）原文：开发者应该将程序的机制与程序的策略分开；一种方法是将程序分为前端接口和与接口通信的后端引擎。该规则旨在通过允许策略更改来最大程度地减少操作机制的不稳定性，从而防止引入错误。解读：这个有点难理解。其实后来发展成java中的接口编程。简单来说，A按照统一的接口协议与B进行通信，B提供相应的具体功能实现。两者是分开的。互补干涉，但对达成的共识没有异议。一旦这个共识要改变，就需要重新协商和约束。例如，对于汽车轮胎，分离规则意味着轮胎制造商只需要根据统一的接口生产相应尺寸的轮胎。至于产地在哪里，用什么材料生产，组装车的时候不用关心。而与轴承对接的发动机也可以多样化。5.简单规则（RuleofSimplicity），6.简单规则（RuleofParsimony）原文：开发者应该设计简单的方法，想方设法将程序系统分解成小而直接的协作块。这条规则的目的是为了防止开发人员写出“复杂而美丽的复杂性”，这是容易出错的程序的现实。原文：开发人员应避免编写大型程序。该规则的目的是防止由于项目所有者不愿放弃大量工作而导致的次优方法失败或过度投资。较小的程序不仅更易于编写、优化和维护，而且在弃用时也更容易删除。解读：这两条规则意义相同。根据当前的时尚，一切都应该尽可能小，尽可能简单和可执行。因为一旦不朝简单的方向去做，就会越来越大。这对于编程尤其重要。程序越简单，就越容易维护和发现问题。那些看似复杂的程序，大部分都是多余的和不必要的，但其实，要简单，有时候需要的是更强的归纳能力。7.透明原则（RuleofTransparency）原文：开发者应该为可见性和可发现性而设计，通过以这样的方式编写，使他们的思维过程可以被未来的项目开发者清楚地看到，使用输入和输出格式来识别有效输入并正确输出。该规则旨在减少调试时间并增加程序的生命周期。解读：这个原则很容易被误解。对于外部用户，他们只需要知道输入和输出，比如计算器。有必要公开代码，以便更好地理解程序，改进程序。这个原则适用于自我提升，尤其适用于反思。比如把当天的工作思考写下来，然后顺着写好的思路，开始回顾自己当天的思考逻辑，哪些做的好，哪些做的不好。.但这也意味着，这种私密的事情不一定要告诉别人。8、RuleofRobustness原文：开发者应该通过设计透明性和可发现性来设计强大的程序，因为易于理解的代码更容易对复杂程序中不可预见的突发事件进行压力测试。此规则旨在帮助开发人员构建健壮、可靠的产品。解读：我们一直非常重视可靠性。即使在移动互联网发达的今天，我们仍然会遇到程序APP崩溃、手机卡顿等问题。其实这就是我们常说的反脆弱性。当我们遇到一些我们平时写自己的“程序”时，能否应付和处理某些突发情况是最重要的。有些人很靠谱，普通的小打击是打不倒的，有的人就没那么靠谱，稍微受点挫折就会崩溃。这就是鲁棒性的意义所在。9.RuleofRepresentation原文：当面临选择时，开发者应该选择让数据更复杂而不是让程序的逻辑更复杂，因为人类更容易理解复杂的数据而不是复杂的逻辑。该规则的目的是使任何开发项目的开发人员能够使程序更具可读性，从而更易于维护。解读：这个规则现在不太适用，因为有大数据。人类虽然善于区分复杂的数据，但前提是数据量不是特别大。按照今天的大数据量，更适合机器来分析，有一个专业叫数据挖掘，专门从事这种数据分析工作。当然，逻辑清晰，数据详细，是很好的说明文体，也增加了文章的可信度。我们现在的调查研究和审查报告是这样的。也就是说，既要有清晰的思路，又要有多种多样的故事。10.最小惊奇规则（RuleofLeastSurprise）：开发者应该根据潜在用户的预期知识来设计程序。例如，计算器程序中的“+”应始终表示“加法”。该规则旨在鼓励开发人员构建易于使用的直观产品。解读：意思是每个单元尽可能有独立的功能，这也是现在开发的微服务最早的来源。现在因为大数据和分布式的关系，微服务越来越流行。也就是说，不仅在编程中，甚至在我们的日常生活中，我们都应该遵循这个原则。在某个时间，尽量专心做一件事，而不是想着一心多用。11.沉默法则（RuleofSilence）原文：开发者在设计程序时应尽量不打印不必要的输出。该规则旨在允许其他程序和开发人员从程序的输出中挑选出他们需要的信息，而不必解析冗长的信息。解读：本意是程序员为了调试方便，经常敲打大量的日志，很容易造成信息泄露或性能问题。不过，我觉得这个规则更像是一个简单规则的延伸，但是从另一个角度来说，我们在思考的时候，需要适度的沉默。并不是所有的想法都需要说出来。一些没有酝酿的想法可以暂时搁置。不要急于表达你的观点。您应该收集尽可能多的信息。让我们得出结论。12.RuleofRepair（修复规则）原文：开发者应该设计出失败的、易于定位和诊断的程序，换句话说就是“失败”。此规则旨在防止程序的错误输出变成输入并破坏未检测到的其他代码的输出。解读：输入错误不要紧，关键是我们能不能调整修复，就像很多人每天收到很多垃圾邮件一样，他们并没有意识到自己收到的是rachel，而他们没有办法处理它。这个原理告诉我们，当我们有了可修复性的意识时，输入错误的输入是可以控制的。在软件测试中，也叫边界测试——通过输入一些超出范围的值或非常规操作来测试输入——通过这种方式可以验证系统的可靠性。一个软件系统一定有某种问题。有问题不可怕，可怕的是不知道问题出在哪里。13.RuleofEconomy原文：开发人员应该重视开发人员在机器上的时间，因为与1970年代的价格相比，今天的机器周期相对便宜。该规则旨在降低项目的开发成本。解读：这条规则有点矛盾。一方面，我想谈谈人工成本的问题。另一方面我想说，随着硬件价格的下降，成本也会下降。我觉得可以解释为投入成本和产出成本。工作就是花时间和机器战斗，让机器按照人的意志运转。付出成本在所难免，只要能在可以接受的范围内。14.生成规则（RuleofGeneration）原文：开发者应避免手动编写代码，而应编写抽象的高级程序来生成代码。此规则旨在减少人为错误并节省时间。解读：现在很多集成编程环境都有这样的功能。对于一些规则固定的代码，可以快速自动生成，避免手工编程出错。也就是说，我们常说，能被自动化代替的工作就应该自动化，机器比人更能胜任这些工作。但这并不意味着手工书写没有意义。人工操作是纠正一些可能出现的错误，对核心逻辑进行处理。15.优化法则（RuleofOptimization）原文：开发人员在打磨软件之前应该制作原型。该规则旨在防止开发人员为边际收益花费太多时间。解读：目前生产的软件产品，都会经过产品经理提出的原型设计。在写程序之前，会优化很多。这个规则特别适用于思维的迭代升级过程，因为当你使用这个原则的时候，你会发现你的思维并不完美，而是有很多漏洞，但是有没有漏洞不要紧，你可以找到并慢慢优化它们，提升和治疗以获得更好的结果。16.多样性规则（RuleofDiversity）原文：开发者应该将他们的程序设计得灵活和开放。这条规则的目的是让程序更加灵活，从而可以按照开发者期望的方式使用。解读：规则的多样性意味着我们有更多的视角和更多的武器可以使用，因为思维武器越多越好，因为视角会更多，问题也会更准确。.17.可扩展性规则（RuleofExtensibility）原文：开发者应该通过使他们的协议具有可扩展性来设计未来，允许简单的插件而不修改其他开发者的程序架构。解读：扩张有点像多学一门技能，跨界。现在我们都提倡跨界，跨界是指一个人一生的可能性。换句话说，生活是非常可扩展的。有些人继续学习和成长。可扩展性非常大。有的人一开始很好，但是没有扩展性，只能在原来的基础上打转。好了，17条规则说完了，话还是有点多，看到这里，已经很厉害了。您可能已经注意到，我没有谈到规则的具体应用。是的，毕竟有那么多原则，每一个原则都足够写一篇长文了。今天，我们就按照大意来解读一下。如果以后在实践中使用，会详细说明应用是如何发展变化的。希望这些规则能给你一些新的启发。
