软件内部质量

　　代码内部质量指的是代码的可读性， 可修改性， 复杂度（圈复杂度，函数深度），  可移植性等软性质量。 （像BUG率指的是外部质量）

　　软件的内部质量只对开发者有直接影响， 对公司来说间接影响是开发的维护成本。

　　为什么程序会有这么多偶然复杂性呢？

　　基本都会有这个问题， 在传统公司，每半年会有个大版本，质量改进可以放到一个大版本中来完成（因为大版本有完全的回归测试）。

　　互联网公司采用的快速开发，但没有完备的单元测试和自动化测试； 都是小版本发布， 很少大版本，也很少有完全回归测试的机会；这些原因导致互联网企业的代码质量往往是差的。

　　原因分析：

　　1、快速开发周期，初都是简单设计并实现功能。（设计欠账，但这很好，很经济）

　　小版本发布（这也很好），  因为多是手工测试，导致的问题是没有完全回归测试的机会。

　　2、后期修改逻辑时，大家也是快速修改。没有过多去考虑代码质量，很多可以改进的地方没有及时改进. （缺乏重构的意识）。

　　3、很多人修改代码的原则是尽量少改代码，保持已有代码，通过添加新代码来实现目标。

　　这样的做的原因是代码没有被测试覆盖， 好处是减少了出错率，并减少了BUG数（对应的绩效也更好）。但这样的缺点是，代码不断引入偶然复杂性，复杂度只增不减， 项目后期维护成本不断增加。（编码欠账， 本次经济，长期可能是亏本的）。

　　4、代码所有者经常变换，初A编写，后来B维护，再后来C维护。 这样代码对后续者（B，C）来说是缺少所有感的，也会缺少质量的责任感。

　　后面的编写者在对老代码都是坚持谨慎原则，只改一定要改的部分，多次易手后，偶然复杂被累积。

　　5、代码内部质量一般不会纳入公司绩效考核，所以关心的人也会相对较少。（投资回报率低，对个体而言）.

　　影响分析：

　　1、对于新项目，代码质量可能不是重要，快速反馈才是；

　　2、对于已经存在较长，并且以后好长时间都会存在的项目，代码质量很重要，质量改进，可以带来更低的修改成本，新成员也更容易理解业务；

　　3、对于老项目，后续很少修改的，或存活不会很久的项目，质量提高可能是没有必要的。

　　改进方法：

　　1、防止恶化，有效的方法是引入单元测试和自动化测试，这样任何人的修改都可以被测试到， 代码也可以真正做到集体所有。 但在中国这个技术要求过高了。

　　可以先只对公共代码和核心代码进行单元测试。

　　2、写代码的时候，坚持“低耦合，高内聚”，做到一个函数一个功能。这样可以在修改BUG和添加特性的时候做重构，这样可以保证你修改的部分会在这次发布中被测试到。

　　3、提交代码前进行code-review， 这样可以相互检查并相互提高。

　　4、在小版本中安插大版本（比如半年一个），大版本的目的是为重构，提高内部质量，并提供完全的回归测试（成本较高）。

　　5、使用代码内部质量度量工具（sourcemonitor， simon）， 并集成的持续集成环境中。

　　6、把代码内部质量度量纳入绩效考核 （本质的保证）。

　　软件内部质量，不能产生立杆见影的效果，质量提高也需要成本，故以上只是个人的简单看法，投资回报未必是划算。