代码不朽：编写可维护软件的10大要则（C#）.md

为什么选择这十条

1. 数量尽可能少
2. 与技术无关
3. 易于测量
4. 与实际的企业软件比较

书籍网站

第一章简介

什么是可维护性

一个系统可被修改的难易程度

软件质量

1. 可维护性
2. 功能可适性
3. 性能效率
4. 兼容性
5. 可使用性
6. 可靠性
7. 安全性
8. 可移植性

维护的四种方式】

1. 发现并修复bug
2. 适应操作环境的改变
3. 系统用户新的需求
4. 预防

可维护性是其他质量特征的推动者

本书的三个基本结论

1. 简单的原则有利于提高可维护性
2. 项目开发一开始就应该考虑
3. 越遵守原则，维护性越高

原则一; 编写短小的代码

1. 代码单元的长度应该限制在15行以内
2. 什么是代码单元

动机

1. 易于测试
2. 易于分析
3. 易于调用

常见的反对意见

1. 分散后难以阅读
2. 过短有不当的格式化
3. 代码不能再分了
4. 拆分没有带来明显的好处

原则二： 编写简单的代码单元

1. 限制每个代码单元分支点的数量不超过4个

动机

1. 易于修改
2. 易于测试

常见反对意见

1. 复杂度不可避免
2. 拆分方法不见得降低复杂度

原则三： 不写重复代码

1. 编写通用的可复制的代码，或者调用自己的代码
2. 至少6行都相同的代码

动机

1. 重复代码难以分析
2. 难以修改

如何使用本原则

1. 提取父类的重构技巧

常见的反对意见

1. 应该允许从其他代码库中复制代码
2. 细微修改的重复代码是不可避免的
3. 这些代码永远不会变化
4. 考伯多分文档相当于多了一个备份
5. 单元测试会帮我发现问题
6. 字符串文本的重复是不可避免的

原则四：保持代码接口的简单

1. 限制每个代码单元的参数不超过4个
2. 将多个参数提取成对象

动机

1. 短接口更易于理解和重用
2. 已与修改

常见的反对意见

1. 构造参数对象过于复杂
2. 构造长接口并没有带来任何改善
3. 一些框架库已经规定了长参数列表的接口

原则五： 分离模块之间的关注点

动机

1. 小型、松耦合的模块允许开发人员独立进行工作
2. 降低了浏览代码的难度
3. 避免让新人手足无措

如何使用本原则

1. 根据不同关注点拆分类
2. 隐藏接口背后的特定实现
3. 使用第三方库、框架替换自定义代码

常见的反对意见

1. 松耦合与代码调用冲突
2. C#接口不适合松耦合
3. 对工具类的高难度使用是不可避免的
4. 不是所有的松耦合都会增加可维护性

原则六：构架组件松耦合

动机

1. 低组件依赖允许独立的维护
2. 可以分离维护职责
3. 易于测试

如何使用本原则

1. 抽象工厂设计模式

常见的反对意见

1. 因为组件之间是相互依赖的
2. 没时间修复组件依赖
3. 透传代码来自于需求透传

原则七：保持架构组件之间的平衡

1. 保持源代码中组件的数量接近于9

动机

1. 易于查找分析
2. 隔离维护带来的影响
3. 分离维护职责

如何使用本原则

1. 确定将功能合成组件的合适原则
2. 明确系统的领域并坚持下去

常见的反对意见

1. 组件不平衡没影响
2. 组件之间的平衡会降低平衡度

原则八：保持小规模代码库

动机

1. 容易成功
2. 易维护
3. 缺陷少

如何使用本原则

1. 控制需求蔓延
2. 功能标准化
3. 不复制代码
4. 重构已有代码
5. 使用第三方库和框架
6. 拆分大系统

常见的反对意见

1. 对生产率的评估会阻碍减小代码库
2. 编程语言会减小代码库体积
3. 复杂系统导致了代码复制
4. 平台架构无法拆分
5. 拆分会带来复制
6. 紧耦合无法拆分

原则九：自动化开发部署和测试

动机

1. 让测试可重复
2. 开发更有效
3. 可预测
4. 测试是对被测试代码的一种说明文档
5. 测试促进写出更好的代码

如何使用本原则

常见的反对意见

1. 我们仍需要手动测试
2. 上级不允许
3. 代码覆盖率低

原则十： 编写简洁的代码

动机

1. 不留痕迹

如何使用本原则

1. 不要编写单元级别的代码坏味道
2. 不要编写不好的注释
3. 不要注释代码
4. 不要保留废弃代码
5. 不适用过长的标识名称
6. 不使用魔术常量
7. 不使用未正常处理的异常

常见的反对意见

1. 注释就是我们的文档
2. 异常处理带来额外的代码工作
3. 为什么只有这些编码原则

后续事宜

1. 将原则变成实践
2. 低层级原则高于高层及原则
3. 对每次交付负责