Art of UNIX programming(复杂度)

Posted 2021-04-30 NASA迷

As simple as possible, but Note Simpler

当简洁不能胜任

对于Unix坚持简单的精神，常常伴随着一种错误的理解方式， Unix程序员常常认为似乎所有的可能复杂度都是偶然复杂度, 更为甚者， 在Unix传统中存在一个强烈的偏好，宁可去掉功能，也不能接受可能的复杂性。

计算资源以及人类的思考，同财富一样，不是靠储藏而是靠消费来证明其价值的。同其他美学形式一样，我们需要设计上的简约已经不在是有价值的自律形式，——而开始成为一件伪装的苦行者外衣—— 实际上把美德作为接口来敷衍工作的纵容方式。

编辑器的适当规模

1. 所有真正有用的程序都想变成瑞士军刀， Unix世界之外大型的成功商业整合应用程序套件通常也证实了这一点，而且直接挑战了Unix的最简（基础）哲学。

2. Zawinski 定律是正确的，他表明有些程序需要小巧，有些程序需要庞大，但中间的路是行不通的。vi编辑器的表面问题可以归咎于历史，然而更深次的问题应该追溯到增加功能的压力同vi信徒，添加新功能根本考虑不到对整体设计的复杂度影响。

3. Emacs和Wily的例子进一步证明， 为什么有些程序需要做的如此庞大： 这样几个相关任务就可以共享环境。从实现者的角度，编辑和版本控制是独立的，但是用户更愿意有一个大的环境让他们能够指向文本部分，无需要在程序之间切来切去。

4. 更普遍的， 让我们假设整个Unix环境可以视作是社区的单一设计工作。那么『小巧锐利工具』的教义，降低接口复杂度和代码库规模的压力，可能正好导向过手工陷阱——– 用户不得不自己维护所有共享的上下文环境，因为工具并不会替他们完成此项工作。

5. 选择 复杂度的价值依赖于对目标的选择。而在所有与任务相关的面相文本工具间共享上下文环境的能力是非常有价值的。  

Emacs 是个反传统Unix的例子吗？    

Emacs 这样庞大的程序会使Unix程序员极不舒服，恰恰因为他们强迫我们面对这些冲突， 这些程序表明， 旧学派的Unix的简约主义作为一个原则虽然有其价值，蛋我们可能已经陷入教条主义的错误中

Unix风格的小巧伶俐工具存在数据共享的困难， 除非他们生存在彼此之间通讯便利的框架中，Emacs就是这样的一个框架，而对共享上下文环境的统一管理，正是其选择复杂度换来的（共享上下文统一管理的实际效果就是用户不需要负担底层的命名和资源管理问题， 旧学派的unix中唯一的框架就是管道，重定向以及Shell，而共享上下文本质上就是文件系统本身，但这并不是进化的终点。）

复杂度

复杂度的不同来源必须以不同的方法应对： 代码库规模可以采用更好的工具来解决， 实现复杂度可以选择更好的算法来处理，接口的复杂度必须着眼于更好的交互设计。
处理各种复杂度： 必然更依赖于见识而非方法，通过发现更简单的方法，可以去除偶然复杂度，依赖上下文环境判断哪些功能值得去做，可以去除选择复杂度。而要去除本质复杂度， 只能依赖于对现实真谛的洞察和顿悟，从根本上重新定义所要解决的问题。

最简原则暗示： 选择需要管理的上下文环境，并按照边界所允许的最小化方式架构程序。 这就是『尽可能的简单，而不是过于简单』，集中关注选择共享上下文环境，实际上，这并不仅仅适用于框架，也是用于应用和程序系统。

然而， 究竟共享上下文环境该有多大实在很容易草率对待，隐藏在Zawinski定律后的压力往往驱使应用程序需要为便利性而共享上下文环境，很容易因为负载太多任务， 太多需求设想而最终失败，也很容易就把程序编制的过于复杂、臃肿、庞大。
矫正这种趋势的方法直接来源于旧学派Unix的赞美诗集。这就是吝啬原则： 只有实证了其他方法行不通时才写庞大的程序—-也就是，已经尝试过分解问题但遭遇失败。 格言表明对待庞大程序的一种严谨怀疑态度以及一种谨慎的做法： 首先寻找小巧程序的解决方案，如果单个小程序无法完成任务，尝试在现有框架结构内构造一个协作小程序工具包来解决问题，如果两者都失败了，才可以自由的构建一个巨型的程序，而不会觉得已经完败于设计。

但编制一个框架时，牢记分离原则。框架实际值，尽可能少的包含策略。再多数情况中，根本就不需要策略，尽可能多的将行为分解到使用框架的模块中。编制或重用框架的好处之一，是能够有益于将『不这样做会是大块策略』的东西分离到独立的模块，模式或工具—- 可以有效的同其他程序重新组合起来的部分中去。

这些准则是颇有价值和启发性的方法，但是Unix传统深处的这种矛盾冲突，并不能将任何给定的工程划分为合理的最佳规模，并分而治之。具体情况具体分析，而锻炼良好的判断力和品位恰好是软件设计者所追求的。行程才是目的，顿悟在每日的实践中。