软件的可持续性

    做过多个项目，有的是参与，有的是负责。但是回想一下，都存在一个问题-------软件不可持续。说白了就是当时可以适应业务、完成客户的需求，当需要对系统进行扩充、升级或是重复利用时，就显得力不从心了。我反思了一下可能引起这个问题原因，主要有以下几点：

1. 需求分析时只是考虑能完成当前的业务，没有考虑其涉及到的和以后可能扩展的业务。

2. 系统开发时，一般是一个人负责一个模块来完成开发。这样就是给开发人员提供了很大的“发挥”空间，造成了后期难于维护。

3. 系统代码不规范。

 

    我一直在想，怎样才能避免上述问题呢？或是怎样才能尽量减少上述问题带来的“麻烦”呢？

    对于第一个问题，一般做项目时都不会给自己找“麻烦”，但恰恰相反后期会出现更大的麻烦。当时只是想只要完成了客户的需求，能满足客户当时的需要就ok了。如果想的太多、涉及到太多，可能根本用不到还给项目带来了压力，所以说一般都是尽量让客户能少点需求，少提几个功能点，这样项目就省事多了。这样的需求分析下来，后期可就有的忙活了。客户当时没提到的问题会陆续提出来，难道你能说：“你以前没提出来，不能满足这个需求！”，当然不行，因为“客户是上帝”。然后就开始了无休止的需求变更，设计变更，代码修改。

    其实只要前期多投入一点，就能省下很多麻烦！

    第二个问题，一般的项目都是这样来做的，我经历的项目也全部是这样来做的（我没经历过大项目，呵呵！）。一人一个模块，符合把大问题化小的分治策略。但是一个项目就那么几个人来开发（尤其是小公司），没法分到很细，只能是一人一个模块来完成。这样完成这个模块的人就“自由”了，我可以把业务逻辑放到展示层来完成，可以任意的修改本模块的服务接口（这里说的是分层设计项目）等等。当时来说还行，谁开发的模块谁来维护，问题还发现不了。过一段时间或开发此模块的人离开了就有问题了，时间长了就是当时开发的人都要看好一段时间才能做出正确的修改，换了人就要费更长的时间了。

    我的想法是按层次划分来完成项目。展示层、业务层、数据库持久层（不在考虑其他的层）分别有专人进行开发，各层定义好服务接口，不允许随意修改接口，开发人员只能实现这些接口或使用接口。这样即使是长时间后或换人维护，即使看不懂当时开发人员的思想，也可以重新来实现这个接口。

   

    第三个问题，代码的规范我不细说了，只要写过代码、看过其他人代码的人都明白。

    这我主要提一下文件的命名，还是那句话“太自由了就会产生麻烦”，我一般是把各功能模块的命名前缀规定好，所有此模块都是以此为开头的文件名，在建立一个命名的文档。这样以后要修改某个功能时，就可以很快的找到了。

先写这么多，以后想起其他的再补充！