the art of unix programming--笔记（chap4）

chap4 modularity:keeping it clean,keep it simple

这一章我理解就是对于“人通过电脑编程来解决问题”这一编程实质的扩展。
如何通过有限的脑力来一步步的创建出可以解决问题的程序？
而且这种解决要求过程要比较快，

这一章我的理解如下：
编程的实质可以描述为：人通过电脑编程来解决问题。
而其中一个天然限制就是人脑的处理能力有限。
那么在设计以及实现的速度质量方面，一个重要原则就是把问题分解简化为人脑可以处理的那种复杂度。
设计思想等等如果是一个人比较显而易见的，那么编程，debug乃至后期维护都是会非常容易的。
在这一章引入一个概念就是“compactness”就是讲很容易可以看明白的设计。
如何用显而易见的设计或者结构乃至具体实现算法去解决问题，是coder应该追求的目标，因为compactness背后
就意味着后期code，debug，maintain的容易性。
四两拨千斤的实现本质上依赖于对问题的透彻理解和对实现方法的透彻掌握，两者的结合应该是coder前进的灯塔吧。

4.1 encapsulation and optimal module size
这一节首先提倡面向接口编程。
并且这也是很多高级程序员的工作方式，想好框架之后只是开始写借口和对接口的comment，之后才着手实现。
据我所知unreal引擎的lead coder很多时候去写接口，然后由其他人来实现，cool!

接口和模块化是紧紧绑定在一起的，至于怎么去分解系统和良好的模块化我想应该是《设计模式》这样书的核心内容，
这节后半部分主要提出模块的大小与bug的密度和总量非常有关系，逻辑代码在200－－400行，物理代码在400－－800行
为最佳，这个数字的通用性也不用在意，但是道理是明显的：一个比较适合coder脑力的模块大小是最佳。

4.2 compactness and orthogonality
orthogonality是指一个部分的变化丝毫不影响另外一部分的运行，那么这两个部分就要分清模块，之间不存在的联系
也就不应该消耗我们的脑力。

spot rule:不要让重复的东西存在多次－－complexity is cost, don't do it multiple times。
strong single center:围绕一个强有力的算法思想来组织模块，整个模块的思想也就是核心的思想，那么相对而言更加容易
理解和掌控，象bsp，bv tree这种，模块围绕这样思想的话是比较好理解，而如果只是把它们作为一个部分再参杂其他东西的话，
可能就是比较困难了。

4.3 software is a many-layered thing
把程序分成多个层是无需多讲的事情了。
这里阐述一个问题设计应该是top down还是bottom up
答案很直接：如果是对于模块都非常了解－－top down
如果是处于摸索阶段－－bottom up
glue layers--看的一头雾水，没看出什么东西，还是根本就是没什么东西？
这里有句明言倒是挺有道理：perfection is not nothing more to add, but nothing more to remove。

4.4 libraries
sorry, I see nothing

4.5 unix and object-oriented language
这里有非常让我共鸣的内容：object-oriented language善于解决特别复杂的问题，深谙这一道理的程序员也常常倾向于把问题复杂化。

4.6 coding for modularity
把模块弄得精巧，规模小。