项目管理和质量控制之编码控制(第一天,发布以前写的测试观点文章)

大多数软件工程文章都没有对编码过程做很多的描述，几乎所有的观点都认为软件重心在开发前期（需求分析阶段和设计阶段），毫无疑问，这是正确的。为了保证后期工作的正确性，有些公司提高了开发前期的时间比重，于是近年出现了一个新的名词“过度设计”，这种“过度设计”勿视了实际编码与设计的差异，浪费了大量的人力物力，给软件开发带来反效果。编码过程到底该占整个软件开发过程多大比重，谁也说不清楚。近年来还有一个观点认为编码过程就是设计过程的一部分，程序员在这个过程中不停地编写修改代码，调整软件结构，如果盲目的修改和调整，又会造成“永不完工”，软件开发时间失去控制。

一个好的软件设计知道该实现哪些功能（需求），这些功能由哪些对象完成（现实），这些对象可以归纳为哪些类（设计），对象之间如何进行交流（接口），这些类能够进行哪些操作（方法），操作过程如何（实现方法）。

不管设计如何完美，实际编码总是与设计有一些差异，差异越小，说明编码后期的改动越小，代表设计水平越高，项目控制可预见性相对越好，反之，编码后期的改动就会很大，项目控制可预见性相对变坏，项目成员就会无所适从，无法保证自己的编码质量和进度。

设计的粒度控制

项目经理必须控制好设计的粒度，保证设计的效率和质量，防止在错误的设计上越走越远，浪费时间。

一般来说，总体设计需要清楚有那些子系统，概要设计需要清楚子系统之间的相关接口和内部对象之间的关系，详细设计需要清楚所有对象和对象必须的操作方法。

假设一个项目有3个子系统，每有子系统有5个基本对象，每个对象有大概5个公共方法，每个方法大概需要编码300行。可以得知，如果估计错误一个方法只会影响进度一两天（可以通过加班的方式进行弥补），如果估计错误一个对象就会影响进度五到八天，如果估计错误一个子系统，可能就需要增加额外的人员，项目进度将很难控制。

设计的水平的提高不是一朝一昔而成的，这依赖于项目成员的长期开发经验，以及对系统的把握程度。需要根据项目组内的现实情况，控制好设计的粒度和进度，在适当的情况下，可以进行回归设计，重新调整项目开发。

总之，认识设计过程的风险，做好预防工作是没有错的。在设计风险比较大的情况下，可以适度提前进行编码，把一些设计放在编码中进行。

编码过程控制

在设计无误的正常情况下，编码过程会很顺畅，项目完工指日可待。但往往实际过程会出现很多问题，需要调整程序结构，修改设计，这些修改必须是有的放矢，尽量减少盲目的重复修改。

在修改代码之前，尽量考虑以下因素：

1．方法是否功能单一化。

类的每一个方法的功能应尽量保持清晰，功能不清晰的方法应尽量拆分为几个子方法。从维护的角度来看，功能清晰的方法远比功能庞大不清晰的方法容易维护，在局部功能发生变化时能够收窄修改范围。

2．类管辖的范围是否太大，有没有拆分可能。

一个类如果方法众多，通常需要考虑有没有拆分的可能，一个功能强大包罗万象的类总是令人头痛，远没有几个简单类组合实现简单灵活。

3．类有没有扩展的可能性。

一个具有功能扩展的类，应该考虑使用基类，把原始的固定的功能放在基类中实现，把可变化的功能通过重载在表现类中实现。

一个项目的可扩展的类越多通常意味着该项目的可持续开发性越好，生命周期长。

4．大而复杂的孤岛函数是否有封装成类的可能。

项目经理关注项目的开发进度，这个进度不光是完成了百分之几，而是做了哪些东西，增加了哪些东西，返回修改了哪些东西，还有哪些没有做。在增加和修改了很多额外的代码后，项目经理应该反省是否该暂时停止编码，整理已经完成的代码，重新设计程序，保证后期开发正常进行。

工作流程参考

一般原则:

1.       公共类和方法的修改需要得到大家的认可。

2.       代码与文档需要同步修改。

3.       文档修改需要及时入库并通告。

4.       代码和文档需要定期审查。

5.       bug的修改需要及时得到审查。