软件的可维护性 

软件维护的四种类型
纠正性维护 : 这是改BUG 
适应性维护 : 这是更换操作系统与数据库等外部环境时的修改
完善性维护 : 这是有新需求的修改
预防性维护 : 确定可以改进质量或者是预防未来出现的BUG的修改

1. 坚持简单的原则最有助于提高可维护性.
2. 可维护性不是项目开发完成后才去考虑的,而应该是在项目开发的一开始就加以考虑.
每个人的贡献都应当计算在内.
3.各个原则的影响不同

可维护性与编程语言无关,与行业无关,也不等价于BUG数量的多少.

可维护性表示高效,有效地进行修改的程度.

可维护性的原则有
1. 编写短小的代码单元
2. 编写简单的代码单元
3. 不写重复代码
4. 保持代码单元的接口简单
5. 分离模块之间的关注点
6. 架构组件的松耦合
7. 保持架构组件之间的平衡
8. 保持小规模的代码库
9. 自动化开发部署与测试
10.编写简洁的代码

1. 要求不超过15行代码
2. 分支点不超过4个
3. 不要复制代码
4. 参数不超过4个
5. 模块中所有的方法被调用的总次数尽可能少于10次.
6. 含有传入调用与透传调用的模块的数量和 与总模块数的比例值小于14.2%
7. 顶层系统组件数接近9, 组件大小的修正基尼系数应该不超过0.71
8.代码库重建成本不超过20人年,C#的代码应该是不超过175000行.

SIG2015年的四星级可维护性标准
方法中代码长度      4星代码单元允许的百分比
大于60行            最多6.9%
大于30行            最多22.3%
大于15行            最多43.7%
小于15行            最少56.3%

方法中代码复杂度    4星代码单元复杂度允许的百分比
McCabe大于25            最多1.5%
McCabe大于10            最多10.0%
McCabe大于5             最多25.2%
McCabe小于5             最少74.8%

重复代码四星评级
代码分类           允许评为4星的行数百分比
非多余的           至少95.4%
多余的             最多4.6%

代码单元接口程度
参数个数           允许评为4星的百分比
大于等于7个         最多0.7%
大于等于5个         最多2.7%
大于等于3个         最多13.8%
小于等于2个         至少86.2%

模块中所有的方法被调用的总次数   允许评为4星的百分比
51+                               最多6.6% 
21-50                             最多13.8%
11-20                             最多21.6%
1-10                              无限制

组件独立性
含有传入调用与透传调用的模块的数量和 与总模块数的比例值小于14.2%

组件平衡性
顶层系统组件数接近9, 组件大小的修正基尼系数应该不超过0.71

代码库体积
175000行以下