模型都是进行阶段性的客户确认再开发，等开发完或者客户的需求变了，或者需求分
析有错误，完全符合客户要求的几乎没有。所以我们是否考虑一下能否在条件允许的情
况下，在以后的项目的开发中多征求客户意见，而不是在一阶段完成后再请客户看，
这有利于我们降低开发大规模修改的风险。这也是

“极限开发”模式中很重要的一点。当

然这也不是绝对的，但这是经过证实的成功率比较高的一种方式。

 在前期需求调研和需求分析都做好了之后，就可以做概要设计和详细设计了，我认

为这部分很关键的一点是确定界面风格和关于代码复用的考虑。一个符合客户习惯的界
面是最保险的方案，这里面包括客户的操作习惯和审美习惯。但对开发人员更需要注意
的是代码复用，一个好的代码应该是注释详细、代码可读性强、代码复用率高的集合。而
要做到代码的高复用率需要高度的抽象能力和对类的粒度的划分，对于粒度的划分应
该遵循很多教材上多次提到的

“高内聚，低耦合”，也就是说一个函数或方法的功能越

单一越容易被组合起来复用，和其他的方法或函数或其他类的关联越少越好，这样在
与之关联的对象或方法改变后不需要改动或很少改动就可以被复用。

另外

“设计模式”也是很重要的，“设计模式”为开发人员提供了一系列其他人经过

多次试验证实成功的可以放心使用的解决套路，能够按照

“设计模式”的思路开发系统

可以获得很好的扩展性和强壮性，这也是经过无数案例证明过的。举个简单的例子，如
果将获得数据的部分和显示数据的代码混在一起，如果将来在改动显示部分或改动获
得数据部分则要到混在一起的代码中去挑自己要改动的部分，这可能造成不该动的代
码被改动了，或者因为一部分改动了，另一部分必须被改动，这样也带入了被迫改动
代码的正确性的问题。对于这样的改动需要在测试时增大测试力度，才能保证代码是正
确的，当然这是以增大测试成本为代价的。用另一种方式，使用设计模式，遵循

MVC

模式，将获得数据部分作为

C（控制部分）封装在一个函数里，将显示部分作为 V（视

图）封装在另一个部分，他们之间的数据传递用函数的参数或其他数据结构（如记录、
集合等），这样就可以保证改动一部分不会影响另一部分的正确性，测试时只要针对
改动的部分测试就可以了，不会因为不知道是那部分出现的错误而做更多的测试用例
来确定错误来源。

软件维护也是个重要的阶段，软件在运行一阶段后，可能会发现一些测试时没测

出的错误，也可能客户觉得有些地方改变一下会为他们的工作提供更多的方便，这是
就需要软件维护。这时需要的开发人员不会很多，但这时维护人员可能不是原来的开发
人员，这是就设计到了代码的可读性和可维护性。良好的代码应该有详尽的注释，当然
最好还要有简单明了的文档。维护后应该有维护记录，要说明维护原因，变更部分的说
明。如果在维护阶段不知道原来的代码的意义，则维护工作根本无处着手。我在维护南
昌市民卡项目过程中遇到这样一件事，因为南昌方面急着要操作员卡，而这边制卡程
序需要改动，但这边什么文档都没有，程序没有业务方面的注释，根本看不出什么意
思，只好重做。如果当时有一份良好的注释，可能重新开工的可能就机会没有了。

另外功能齐全的公用单元有利于减少开发重新编写的代码量，可以节省开发时间，

增强代码的复用性。这在多个项目中可以看到好处，能够非常迅速的就搭建起了系统框
架，对于一些功能需要的技术实现已经在公用单元提供了，所以可以拿过来直接使用。

如何组织软件开发过程中的每一个步骤，就是软件开发周期模型要解决的问题。我

认为开发软件，其实就像是解决一个逻辑问题。想想自己平时是怎样写程序的。首先是
要有一个想法，即我写的这个程序是要干什么的；然后就是对要实现的核心功能大概
构思一种或多种实现方法，并从中选出一种自认为是较好的；接下来就是将涉及的各
种主要或次要功能分成各个模块；最后就是分模块来编码和差错。在我看来，除了第一
步外，其余的步骤应该是一个循环的过程。在编码的过程中，你总是需要不断地回过头