https://ruby-china.org/geniousli en-us <h3 id="简介：">简介：</h3> <blockquote> <p>本书，主要是作者对于 Unix 相关的一些『哲学』讨论，包括，编程，文化，环境相关。当然最主要的还是，编程哲学相关。个人认为其中最新颖的，令人耳目一新的，当属复杂度的讨论。</p> </blockquote> <h4 id="编程的本质是控制复杂度">编程的本质是控制复杂度</h4> <ul> <li> 复杂度的几个来源：实现复杂度，用户程序界面复杂度，系统中的代码行数。</li> <li> 复杂度的分类</li> </ul> <table class="table table-bordered table-striped"> <tbody><tr> <th>偶然复杂度</th> <th>违反 SPOT 原则</th> <th>过早优化</th> <th>非正交性</th> </tr> <tr> <td>选择复杂度</td> <td>方法学开销</td> <td>别的一切</td> <td>有效功能</td> </tr> <tr> <td>本质复杂度</td> <td>开发工具</td> <td>核心数据结构</td> <td>功能需求</td> </tr> <tr> <td></td> <td>大码裤规模</td> <td>实现复杂度</td> <td>接口复杂度</td> </tr> </tbody></table> <ul> <li>偶然复杂度：常常来源于接口设计非正交，没有仔细的分解接口以使得每个接口只能完成一件事情、过早优化、</li> <li>本质复杂度：通常无法消除，除非调整软件的基本功能需求。代码库的本质大小同选择的开发工具有关，其中实现的语言可能是最重要的决定因素</li> <li>选择复杂度：通常很难归纳复杂度的来源，往往依赖于 我们对 是否值得为何种功能付出复杂度的代价判断。</li> </ul> <p>个人认为其中对复杂度的判断，简直了，很少有书谈及，最多的是点到<strong>编程是控制复杂度</strong>这一层面，也就没了。很少又能够分析，并给出方案的。 本来感觉到这里这书已经值了。但是。。。下面的永远都是更精彩的。</p> <h4 id="Emacs 是个反出Unix传统的论据吗？">Emacs 是个反出 Unix 传统的论据吗？</h4> <blockquote> <p>作者，主要讨论了，Emacs，Vim，Wily，Ed 编辑器的对比，以及 Emacs 为什么如此成功，但是却如此庞大。以及对 Unix 简单哲学的冲击。</p> </blockquote> <p><strong>Emacs 为什么如此庞大，却同样成功</strong></p> <ul> <li>所有真正有用的程序都想变成瑞士军刀（Zawinski 定律）</li> <li>Emacs 的庞大是因为其选择的复杂度------对共享上下文的统一控制</li> <li>Unix 风格的小巧伶俐工具存在数据共享的困难，除非他们生存在彼此之间通讯便利的框架中，Emacs 就是这样的一个框架，而对共享上下文环境的统一管理，正是其选择复杂度换来的（共享上下文统一管理的实际效果就是用户不需要负担底层的命名和资源管理问题，旧学派的 unix 中唯一的框架就是管道，重定向以及 Shell，而共享上下文本质上就是文件系统本身，但这并不是进化的终点。）</li> </ul> <p>对于 Emacs 主题的讨论，这关注了对 Unix『哲学』的冲击，以及分析 Emacs 为什么如此成功，其复杂度的来源问题，以及 Unix 最简原则产生的一些问题。 如果看了前面那么多的原则，推论，例证，深陷在 Unix 简单之美的哲学中，可能这一章节，真的是『一盆冷水』。一直以为书主要探讨的是 Unix 之美，没有想到的是，作者并没有沉浸在其中，反而是跳出来对 Unix 的哲学进行审视、批评、纠正。</p> <p>下面是一些其他书中见多不怪的总结：</p> <h4 id="Unix 哲学 本身的体现:">Unix 哲学 本身的体现：</h4> <ol> <li>模块原则：使用简洁的接口拼合简单的部件 计算机编程的本质是控制复杂度。要编制复杂的软件而又不至于一败涂地的唯一方法就是降低其整体复杂度----- 用清晰的接口把若干简单的模块组合成一个复杂软件，如此一来，多数问题，只会局限于局部，而不是牵一发而动全身。 <ol> <li>清晰原则：清晰胜于机巧</li> <li>组合原则：设计时考虑拼接组合 多数程序都尽可能采用过滤器的形式，即将一个输入的简单文本流处理为一个简单的文本流输出。</li> <li>分离原则：策略同机制分离，接口同引擎分离</li> <li>简洁原则：设计要简洁，复杂度能低就底</li> <li>吝啬原则：除非确无它法，不要编写庞大的程序</li> <li>透明性原则：设计要可见，以便于审核和测试</li> <li>健壮原则：健壮源于透明性与简洁</li> <li>表示原则：把知识深入到数据以求逻辑质朴而健壮 数据要比编程逻辑更容易驾驭，在设计中，你应该主动的将代码的复杂度转移到数据中</li> </ol> </li> <li>通俗原则：接口设计避免标新立异 最少惊奇原则</li> <li>缄默原则：如果一个程序没什么好说，就沉默</li> <li>补救原则：出现异常是，立马退出并给出错误信息</li> <li>经济原则：宁化机器一份，不花程序员一秒</li> <li>生成原则：避免手工 hack，尽量编写程序生成代码</li> <li>优化原则：雕琢之前先得有原型，跑之前先学会走 过早优化是万恶之源，先只做原型，在进行细琢，优化之前先确保能用。</li> <li>多样原则：绝不相信所谓的不二法门，</li> <li>扩展原则：设计招眼未来，未来总是比预想快 设计代码时候，需要很好的组织，让将来的开发者增加新功能是无需拆毁或重建整个架构，当然这个原则并不是说你能随意的增加根本用不上的功能。而是建议在编写代码时候考虑未来的需要，使以后增加功能比较容易，程序结合更灵活。 其实其中很不容易取舍。</li> <li>KISS keep it simple, stupid</li> <li>如果不确定什么是对的，那么就只做最少的工作，确保任务完成就行，至少知道知道什么是对的。（善用工具，尽可能的将一切都自动化）</li> </ol> <p><a href="https://geniousbar.github.io/2017/10/21/art_of_unix_programming/" rel="nofollow" target="_blank" title="">详细总结</a></p> geniousli Sun, 05 Nov 2017 16:38:52 +0800 https://ruby-china.org/topics/34513 https://ruby-china.org/topics/34513