FO软件编程思想拯救云计算软件危机最佳方案

　　60年代中期，大容量、高速度计算机的出现，使计算机的应用范围迅速扩大，软件开发急剧增长。高级语言开始出现；操作系统的发展引起了计算机应用方式的变化；大量数据处理导致第一代数据库管理系统的诞生。软件系统的规模越来越大，复杂程度越来越高，软件可靠性问题也越来越突出。原来的个人设计、个人使用的方式不再能满足要求，迫切需要改变软件生产方式，提高软件生产率，软件危机开始爆发。

　　1968年，北大西洋公约组织的计算机科学家在联邦德国召开国际会议，第一次讨论软件危机问题，并正式提出一个新的名词：软件工程。从此出现了一门新兴的工程学科——软件工程学，目的就是研究和克服软件危机。

　　软件工程不能解决软件危机

　　刚开始的时候，软件工程的确解决了一些问题。

　　然而进入上世纪80年代以后，尽管软件工程研究与实践取得了较大的成就，软件技术水平有了长足的进展，但是软件生产水平依然远远落后于硬件生产水平的发展速度。

　　当需求比较复杂的时候，软件工程本身也出现了危机。比如当一个需求需要1亿个模块的时候，缺乏必要的文档资料或者文档资料不合格，将给软件开发和维护带来许多严重的困难和问题。

　　云计算必须面对“软件危机”

　　软件开发商很少提“软件危机”的事情，架构设计师根据用户的需求，制定出开发方案后，软件人员只需要按照要求编写代码就可以了。事实上国内的很多软件人员好象不知道有“软件危机”这回事。

　　传统的软件开发可以回避谈论“软件危机”，毕竟是一个简单的系统，比如ERP，也只是一个简单系统，即便出现软件危机，影响也不会太大，最多是影响一个大型企业。

　　然而开发云计算产品的时候，软件危机就成了绕不过去的坎了。同样是提供企业资源管理服务，影响的就不是一个企业，也是很多的企业，以及和这些企业相关联的政府部门，比如税务局、工商局、商业局、统计局等，因为这些部门从企业的“数据云”里获得相关的信息。

　　软件危机的本质难题

　　图灵奖获得者Fred Brooks在1987年所发表了一篇关于软件工程的经典论文——《没有银弹》。认为没有任何一项技术或方法可以能让软件工程的生产力在十年内提高十倍。这篇经典论文的核心论述通常被解释为复杂的软件工程问题无法靠简单的答案来解决。而他的结论到目前为止是对的。

　　软件危机的本质难题在于软件的体系结构和软件的程序代码数量。

　　1、体系结构是指数据、算法、功能在软件系统中的连接形式，尽管数据、算法、功能本身是精确的，但是其连接形式是多样的，也就是说每个构成成员，是通过多条路径和其它成员连接的。比如ERP中库存管理里的家电产品信息，会关联到商业销售、物流、运输等。

　　2、程序是完成一个功能所需要的逻辑过程的集合。程序代码是记录逻辑过程的符号。由于程序员自身的问题，逻辑不清晰或者所使用符号的不准确，将导致程序存在“BUG”。代码的数量越多，隐藏的“BUG”就越多。

　　只有采用革命性的方法才有解决软件危机的可能

　　以软件工程为核心的传统软件开发方法，经过几十年的发展，已经达到了一定的高度，而且也出现了大量的创新方法和思想。比如高级语言的出现，面向对象编程，图形化编程，程序验证，构件技术，UML，MDA，SOA，敏捷开发等等。

　　1、Model Driven Architecture 模型驱动架构

　　UML是MDA所使用的关键技术，任何使用MDA创建的应用程序都基于标准化的，与平台无关的UML模型。这样，就意味着应用程序被定义为与平台无关，所以这样的应用程序就是可移植的。这很容易让人想到Java所宣称的“write once run anywhere”，试图去构建一个平台无关的框架，如Swing UI库。但是这种想法必须在性能和平台集成上作出折衷，而在过去这种折衷是很多产品失败的根源，由于这些失败，业界仍然非常怀疑MDA的宣言。

　　2、敏捷开发

　　AM是一种态度，而不是一个说明性的过程。AM是敏捷建模者们坚持的价值观、敏捷建模者们相信的原则、敏捷建模者们应用的实践组成的集合。 AM描述了一种建模的风格。当它应用于敏捷的环境中时，能够提高开发的质量和速度，同时能够避免过度简化和不切实际的期望。

　　AM是对已有方法的补充，而不是一个完整的方法论。

　　AM并不是要反对文档。文档的创建和维护都会增大项目涉众的投资。敏捷文档尽可能的简单，尽可能的小，目的只集中在和目前开发的系统有直接关系的事情上，充分了解受众的需要。

　　AM也不是要反对CASE工具。敏捷建模者使用那些能够帮助开发人员提高效果，提升价值的工具。而且，他们还尽力使用那些能够胜任工作的最简单的工具。

一直以来，国外优秀的软件工程师和软件