狂奔 lion

学过软件工程的都知道，软件产品的生产周期是一个经历若干阶段的漫长过程，包括需求获取 - 设计 - 开发 - 维护等等。

需求阶段 - 总想考虑到所有的问题，或是一切按合同办事。但在现实中根本不得能，因此很多公司开始提倡“随需而变”的能力，希望快速的响应用户的需求变化
维护阶段 - 总希望自己开发出来的东西一劳永逸，永远不要再产生任何麻烦，产生了麻烦也不要找到我。甚至有些项目组的人员开发出来一大堆不成熟的产品、项目后撒手不管，走人了事，毫无职业操守，亦是对自身行业声誉（至少是国内IT服务提供商声誉）的一个打击。真正的项目开发不应该这样，一定是非常易于维护的，能够快速地找出问题的所在，或是新需求切入点的所在，然后解决

很明显，前面提到的两个问题都要也只能通过设计和开发来解决。问题来了，怎样开发出的软件才能快速地响应需求，易于维护？可以有很多不相冲突的说法，比如解耦，比如通过POJO封装数据等等。这些东西流行开来以后，很多人有疑问，为什么我的项目中一定要用这些框架？我不用这些框架也可以快速的开发出我要的功能，而且更加简单，等等。如果孤立地从设计和开发的角度看这些问题，这种说法并没有错误，但是如果从整个软件开发的生命周期来看，则不是这样。当然，这里还有一个是否“过度设计”的trade-off在里面，不过那又是另一个话题了。

再说说各种各样的平台吧，它们和框架不同，软件体系结构中有一种架构模型即层次模型，我们现在的TCP/IP协议栈即属于这种模型，我们的软件对于平台产品的依赖是一种朝向稳定的依赖，就好像我们在调试代码时往往不会去调试操作系统API的bug一样，因此在开发这种平台层次级别的产品时就没有必要再去采用那些为了保障“企业应用”Web软件生命周期中所采用的方法了，完全可以用最基础，最底层的手段。只要能够做到高效、稳定即可。因此，平台中间件产品的开发必须和应用软件产品分开来看，虽然它们可能都在用Java这种编程语言。