编码阶段，要成功，必须牢记一条：能做到少修改，不重做，力争一次成功！！

在编码阶段，只要不是原则性的错误，尽量不要推倒前面所做的一切，重新做，毕竟以前做的时候也是考虑了方方面面的因素的，现在出现的问题只是在某方面考虑不周而已，一切都作废，太浪费了。还有，要是数据库字段已存在，除非万不得已，千万不要修改数据库字段，能可添加字段。因为已经存在的字段，很有可能已被软件开发小组的其他成员在使用，不要因为你的修改而令其他人也要跟你做相应的修改。后，软件界面的修改要慎重，界面的修改很容易使你忽略修改相应的内容，造成软件大问题没有，小问题一大堆。

要想做到不修改，不重做，很不容易，要考虑的因素很多。

首先从软件的角度来说吧:

对于专用软件，很多时候，一般用户对于软件要完成哪些功能已经有了一个比较清楚的轮廓，而且往往在开发合同中已经大致地规定了。但是，开发合同上规定的只是一个大概的框架，用户心目中的产品究竟是什么样子，有时不要说开发人员不知道，连用户本人也不知道。所以很多时候，都是到了开发工作的后期才发现开发人员的理解和用户的要求有一些误解，那么必然造成时间上的浪费。　

对于通用软件，很多时候是到了开发工作的后期才发现某方面的功能不足，或要添加新功能等等。

在小型软件公司中，由于开发人员少，这样意味着不同人员的程序之间交互、接口相对少一些。开发周期短意味着往往是同样的几个人从头到尾负责一个项目。这两者都让人容易犯些错误。往往是几个人碰一下头，讨论一下基本的数据结构、函数接口便分头去做自己的工作了，没有一份较正式的文档。当有的人会对讨论出的接口、结构理解有偏差(应该承认人是会犯错误的)，一个误解可能造成以后的返工。

其次从管理的角度来说吧:

1、 有效的团队组织。

提高团队组织的工作绩效，提高组员的团队精神。这非常有利团队有效，有序的工作。有效的团队建设，这是管理的重要内容。
　　
2、 小组成员的沟通、协调。

　沟通，也许在各行各业都已提到了一个相当重要的位置。在一、二十年前，也许您会经常听到某位大侠单独完成了某种创举，成了人们崇拜的对象。可，这种大侠，已经很难有生存空间了。取而代之的是，某军团，又攻克了一座什么样的宝垒。这样，沟通，可以说已经变得无比的重要。在软件业，沟通可以说是快速学习和掌握新知识，达到技术上的更高层次的佳途径。 小组员的沟通，可以很好的加强团队组织的凝聚力。可能更好的让项目良性的进行。而培养这种气氛，形成有效的沟通，这也是项目管理的基本内容。协调几个人的工作比自己完成一段编码更重要。如果小组成员在协调上出了漏洞，可能导致很大的问题，所以项目负责人必须随时监控各开发人员的工作，包括内容是否与要求发生偏差，进度是否滞后等等。

后从测试的角度来说吧。

传统观点认为，测试是在编码后的工作。其实，测试和编码是两个密不可分的阶段，交叉进行的，测试在编码后期进行的较多！！主要有两方面:

1、 不经过单元测试而直接进入系统测试;

造成这一现象的原因是每个模块相对比较简单，但是为了测试一个模块需要建立一些测试环境。例如，为了测试一个函数是否正确，应该用一些测试数据去调用该函数，需要编写一些测试数据。但很多开发人员嫌麻烦，觉得反正其他模块也很快出来了，直接用真正的数据来运行几次行了。殊不知，一旦直接进入系统测试，发现运行结果不正确后需要一步步查找。不但耗费了大量的查找时间，而且后面的模块已完成了，修改前面的模块又会影响后面的模块，使的修改的难度增加，修改后导致新的错误产生的概率增大，另外，每个人的潜意识都不想否定自己，这种情况下很难真正去修改。还有由于这种测试不完全，真正运行系统，当调用某模块时，可能大部分时候都是正常数据，极少出现边界情况，可能某些边界情况容易被忽视，很久之后才被发现。但是如果对每个模块进行单元测试时都进行一下边界测试，会很容易消除一些隐患。真可谓欲速则不达也！

2、 如果在项目人员配置中设置了专门的测试人员，编码人员会认为软件所有的内部测试工作全部应该由测试人员完成。

众所周知：软件程序测试可以分为“白盒法”和“黑盒法”两种方式。由于使用“白盒法”对测试人员各方面素质的种种要求，在进行程序测试时测试人员总是优先使用“黑盒法”。他们的工作方式往往是先对程序进行“黑盒法”测试；如果测试没有通过，不得已这才考虑对程序代码进行“白盒法”测试。显然，这种对“白盒法”有意无意的“逃避”，对软件的可靠性和稳定性构成了威胁，造成在编码后期，甚至是在试运行或运行阶段需要进行大量的修改。如何解决这个问题？一方面需要提高对测试人员的要求，另一方面也需要程序员完成部分的“白盒法”测试（实际上，程序员往往也是进行“白盒法”测试的佳人选）。

在代码阶段，除了要想做到不修改，不重做外，还需要对软件的质量进度等进行控制，必须做到以下几点：

1、 定期召开项目工作会议，向项目开发人员及时了解项目进展情况及存在的主要问题。一旦发现问题，管 理人员应迅速查明原因，尽快采取措施，争取在尽可能小的范围内解决问题。

2、 在软件开发过程中，请专家和用户按照里程碑评审阶段性的成果，判定开发进度 是否与软件项目定义的里程碑保持一致，开始时间是否与计划时间一致。

第四章 编码后的管理

编码完成后，是软件实行试运行、运行阶段，并生成相应的版本，并进行相应的备份。这个工作很重要，特别是版本生成备份，很容易出错。笔者在曾经犯过这样的错：给了老版本给用户；把为甲做的版本给了用户乙；备份时把以前有用的版本覆盖了等等，不一而足。要避免犯这些错误，必须要在每次生成不同的版本或者备份时，都要建立相应的文章。在文档中，尽可能详实地记录本版本或备份的时间、目的，特别是和其他版本的不同之处。写的越详实，出错的概率越小！！