软件内部质量的一些思考

软件内部质量

 

　　代码内部质量指的是代码的可读性， 可修改性， 复杂度（圈复杂度，函数深度),  可移植性等软性质量。 （像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. 把代码内部质量度量纳入绩效考核 (最本质的保证）。

 

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

转载于:https://www.cnblogs.com/napoleon_liu/archive/2010/10/21/1857593.html