代码不朽：编写可维护软件的10大要则（C#版）
【荷】Joost Visser 著
张若飞 译
出版社:电子工业出版社
出版时间:2016年09月
以下简称“代码不朽“。
这本书我读了几遍，觉得帮助还是挺大的，做些笔记。
《代码不朽》这本书在每一章的开头都引入 了一句名言警句，我在其它编程书上也经常看到这种操作，所以我经常在怀疑，这些大佬的编程是不是语文老师教的。
”上医治未病，中医治欲病，下医治已病。“ --源自《黄帝内经》
这句话是《代码不朽》在序言中引用的一句话，刚看的时候还不知道是什么意思，查了一下，
解释如下：“上医治未病”：以食物味色，聚其精气。食补胜于药补；“中医治欲病”：以药物味性疗之，调其阴阳；“下医治已病”：治疗重症，以毒攻毒救其命也亡其命也。
作者想通过这句话警示我们从写下第一行代码时，可维护性就应该获得开发人员的重视，并成为贯穿始终的基本理念。
《代码不朽》在序言中还说到：”尽管软件近几十年才开始存在，中国传统的哲学理念依旧适用。防患于未然永远好过亡羊补牢。“ 反正我是服气的，这语文功底。
已故伟大武术家李小龙先生在他的武术中也融入了哲学的思想，中华文化真的博大精深啊。
一、软件可维护性简介
1、什么是可维护性
我们将一个软件系统可被修改的难易程序称为它的可维护性。
可维护性是软件质量的一个特征，而性能（程序运行得出结果的快慢）是另一个特性。
可维护性好的代码比无法维护的代码更加稳定。
2、软件维护的四种方式
纠正性维护：发现并修复Bug
适应性维护：系统需要去适应操作环境的改变——例如，操作系统或者技术的升级
完善性维护：系统用户（或者其他能够影响到系统的人，例如股东）有新的需求，或者对之前的需求有变化
预防性维护：确定可以改进质量或者预防将来产生Bug的方法
二、软件可维护性原则1——短小的代码单元
“Any fool can write code that a computer can understand. Good programmers write code that humans can understand.”(任何人都能编写计算机能理解的代码，而好的程序员编写人能理解的代码)
--Martin Fowler
原则：
1、函数的长度最好在15行代码以内
2、如果某个函数的代码超过了15行，最好将它拆分成多个函数，直到它满足原则1
3、短小的函数易于理解，测试和重用
三、软件可维护性原则2-简单的代码单元
原则：
1、限制代码单元分支点的数量，尽量不超过四个。像使用了if、case、?、??、&&、||、while、for、foreach、catch的语句，可以被认作为分支点。
2、如果一个函数内部的代码比较复杂，应该将它拆分成多个简单的函数。
3、代码的分支点越少，代码单元越容易被修改和测试。值得说明的是：拆分成多个函数并不会降低系统整体的复杂度，但对于可维护性来说，却是很大的提升，这样的代码容易测试，也更容易被理解。
至于怎么拆分，这就看实际需求了。个人觉得，如果一个函数主体里的代码很多，可以把功能稍微相近的操作再拆分成一个函数。
四、软件可维护性原则3-不写重复代码
原则：
1、不要复制代码
2、编写可复用的代码
如果重复代码中有一个bug，那么相同的bug会出现多次。但是如果封装成可复用的函数，当发现bug时只需要修改一次。
五、保持代码单元的接口简单
原则：
1、限制每个函数的参数不能超过4个
2、如果函数的参数超过4个，应该将参数提取成对象，结构体也行。
我曾经就维护过函数里参数特别多的代码，感觉还是可以的。没有维护过那样的代码，今天也不能体会到代码单元接口简单的重要性。
过长的接口不是问题，而是实际问题的一个表现--数据模型不够合理，或者你经常去改动代码。因此可以通过长接口来了解是否需要改进你的数据模型。
六、分离模块之间的关注点
原则：
1、避免形成大型模块，以便能达到模块之间的松耦合
2、不同的任务分配给不同的模块，模块之间要独立，并且隐藏模块内部的实现细节
注意：这里的模块对应C#等面向对象语言中类的概念。
这个原则总结起来就是：高内聚低耦合。不同的功能尽量划分到不同的类去实现，不要堆在一个类里实现。
七、架构组件松耦合
原则：
1、顶层组件之间应该做到松耦合，这里的意思就是组件之间应该被很清晰地隔离开，只有几个很少的接入点，并且相互共享有限的信息。
2、应尽可能少的暴露当前模块中的代码给其它组件中模块的相关代码。
3、独立的组件可以单独的进行维护。
这跟第六点原则是有相似之处的，但是这里是站在组件层面，而不是模块层面 。模块耦合度关注某个模块（类）对系统其他部分的暴露程度，而组件耦合度关注的是一个组件中的模块对其它组件中模块的暴露程度。
当组件发生依赖关系时，意味着内部实现过多的暴露给了依赖它们 的其它组件 ，这样的组件不是独立的，当你修改一个地方的时候，就不知道这个修改会不会对其它组件造成影响。
一定要避免模块之间透传，这在进行组件式开发时，很重要。要保证模块的独立性。
八、保持架构组件之间的平衡
原则：
1、平衡组件的数量和体积
2、保持组件的数量接近9，并且使这些组件体积保持一致。平衡的组件可以帮助定位代码、而且可以对这些组件单独进行维护。
个人理解：这一点原则作用不大，因为组件的数量可能会根据功能而变动，而组件的体积会根据功能的复杂程序而变动，应该尽量保证顶层组件代码的独立性。