关于项目开发和服务的讨论

本人希望能够在此引出一个话题，就是关于项目开发和维护需要注意的问题！事实上这不是一个什么新颖的话题，只能说是一个没有引起足够重视，培养作为程序员的一种基础素养的话题。

为什么这么说呢？笔者一直认为IT行业的发展趋势是服务高于一切，服务是盈利模式，服务是最终竞争力！

本人曾经做过几个项目，有很多感触。一个是耦合性、这是一个非常基本的问题！只要稍微研究一下有关IT方法论，就很明显可以看到，从过程到OO，从AOP到SOA，总是试图以最简单的方式解决问题，从耦合非常紧密的架构到松散耦合的架构。主要是架构师是否能够考虑到扩展的可能和具有松散耦合的素养，有非常多的书籍讨论这些问题，在这里就不多说了。

一般项目都会有一个免费的维护期！或者免费的服务期！有必要先区分一下维护和服务的概念，维护的对象是已有的系统，要保证已有系统的正常运转；服务的范围比较广，是在系统之上的企业业务，使实际业务通过系统得以有效实现！企业的业务很少有一成不变，当企业业务变化时如何能够通过已有系统快速、有效的实现，是服务的重点！此时，已有系统已经开发定型，如何在已有系统中实现新的要求？已有系统可能是任意架构的系统！在此提出最佳解决方案不太现实！主要阐述一种思想“松散耦合”，这不是在构造已有系统时考虑的问题吗？在做服务的时候为什么也要提到！

当你准备做一个服务的时候可能已经发现原有的系统耦合性非常强，要添加一个新的功能难度比较大！那么从现在开始，把你的新功能设计的松散一点吧！原有的接口尽量不变（对原有业务影响比较小的情况下，如果对原有业务需要修改，则最好是添加新的接口），因为你可能对原有系统比较熟悉，也可能根本不熟悉，此时修改原有接口需要在原有的文档基础上反复论证不会造成原有业务的非预期变化（实际上国内很多时候根本没有完整的文档供参考），为了避免反复论证，详细研究原有系统的几乎所有方面，快速提供新服务的实现，只要完全清楚新业务对原有业务的影响就足够了！不需要研究原有系统的所有业务和代码。

这里说的只是雕虫小技，重要的是在整个系统开发初期就要设计好合理的架构，符合业务可能的扩展需要。软件工程的思想是否真的在你开发软件整个生命周期体现，还是仅仅为了一期的交付！