和谐软件过程--和谐宣言之创新变通

和谐软件过程--和谐宣言之创新变通
创新变通
和谐的目的在于永续，永续需要提高效率、简化过程、简便实用、节约资源。
好变者亡，忘变者殆
易，穷则变，变则通，通则久。
不期修古、不法常可、论世之事、因为之备。
CMM是国际上公认的、最成熟、最有效的一种提高软件工程化水平的方法和标准。然而评估费用非常高，评估时间也非常长，在实施CMM的过程中，将过程复杂化了，增加了软件开发的难度和复杂性，整个过程操作起来非常困难，尤其是第一次评估；效果也不理想，很多评估形式大于内容，很多评估项目、文档都有杜撰的痕迹，因此效果自然大打折扣。而且，评估都是和个别项目联系在一起的，如何在整个公司内推广是一个非常大的问题。
UML、设计模式前几年在IT行业是无人不知、无人不晓，曾一度有不知它们者非IT从业人员之说，然而发展到今天，骂声却越来越多；从实践来看，真正在大量应用GOF23种设计模式的可以说只是凤毛麟角，UML最多也只用来画USE CASE图，结果却是昙花一现、刹那光辉。
UML、设计模式曾经辉煌，到现在基本上只用USE CASE、工厂模式，这在一定程度也说明他们并不像想象中那么有用，因此也就没有那么受欢迎，使得不少人弃暗投明，转而采用更加有用、实用的IT技术。例如，类图在UML中很核心，可以用来描述系统的继承关系、系统架构等，但是在实际开发中，如果按部就班，先绘制类图再实现代码，那样根本无法适应快速有效的IT行业，事实上相同的编码规范必然导致相似的类图，我们根本没必要绘制那么多无谓的类图，另一方面，即使绘制了类图，但是与我们实际想要的代码却还有一段距离。基于DB应用的系统，以表为基础，CLASS往往对应了TABLE，因此O/R MAPPING风起云涌；另一方面，ECLIPSE等开发工具本身就可以根据实际的类来得到UML类图，而.NET的自说明机制也很好地说明了这一点，因此导致了现在的状况是，只用他来描述系统而不是系统设计的基础，与UML的本意大相径庭。设计模式也一样，根本无法适应IT行业的特殊性，尤其是业务需求的特殊性，因此基本上只剩下风雨飘摇中的工厂模式。
这里我们在惋惜之余，不得不反思，他们的出现作为一种新技术、新思想，多少人曾经为之努力付出，结果却不实用，浪费了大量的人力物力，失去了多少创造社会财富的宝贵时机，这许多的浪费，难道是IT从业人员无鉴别能力吗？还是他们为宣传、为增加自己的知名度？现在已经众说纷纭、莫衷一是。
在纷繁复杂的软件行业，我们不能强调求同存异，应当无为顺势、存异不求同。我们不可以轻易接受别人的观点，也不应当把我们的观点强加给别人。一方面不能固步自封，守着低效的方法；也不需要一味跟风，以为不学所谓的新技术就是落伍。方法无对错，技术无高低，关键在能够有效地解决问题。和谐在于务实。
和谐软件过程关于创新，认为有3个前提条件：为解决技术难点、提高系统运行效率和工作效率、系统整合的需要。除此之外没有其他，而现在很多人却过于浮躁，为了用新技术而引进新技术，或者为了显示自己知识面广，而忽视了最基本的原则，置效率于不顾，焉有不败之理。
那么我们究竟应该如何来看待技术爆炸的IT行业和如何采纳的问题呢？IT行业根本不存在永恒的技术、理念。或许大家认为C语言经受住了历史和现实的考验，但是它毕竟难以适于图形化开发；或许大家觉得VC大有可为，但它毕竟只能在WINDOWS上运行；或许JAVA是各位的受选，然而它的内容庞杂而缺乏统一，因而显得十分臃肿混乱；或许你还看好XML，又有谁能保证在不久的将来，或许就在明天，又有新的方式取代XML呢？我们要做的不是去追求那些虚无缥渺的东西，把心态放平，立足现实，做好自己的事，以团队、企业、行业为基础，取代XML的新技术必将出之我们团队！
非变通不足以明方向，我们惟有立足现实，才能展望未来；非深究无以通达，我们必须以系统工程为基础，以不变应万变，才能真正地创造IT行业的天地大同式。