我所看到的传统软件工程学

     这篇blog我早就想些了，也是因为工作的关系耽搁了，在看这篇blog之前，希望你能先看一下Martin Fowler于6月3日在中国的演讲:http://news.csdn.net/n/20050603/21874.html

      这篇blog的实质是要引出敏捷开发，还是按照我一贯的风格，在说明一个概念之前，先讨论一下需求。鉴于我只有一年的工作经验，可能我会对一些问题的看法很肤浅，但至少这就是我现在感受到的客观事实。让我们谈一下现在的软件开发过程的一些问题。

      在Martin Fowler的演讲里提到了计划驱动，传统的瀑布式的开发方式就是计划驱动，而一些软件开发的认证几乎也都是计划驱动，包括我们熟知的cmm。为什么会有计划驱动？那是因为前人把工程学代入了软件开发，工程学本身就是讲究计划驱动的。造房子先要实地考察，建筑师做设计，打好地基，最后才有工人开始造。这就是工程学里所提倡的一环扣一环，并且先后顺序分明。

      的确工程学在一段时间里给开发大型软件产品和项目带来了效率，至少表面上是如此的，老板总觉得这样更科学，更健壮，更严密，况且由于有文档的关系，也不担心更换团队（甚至有文档驱动的概念）。但是真的是这样吗？传统的工程学真的给软件开发带来了效率吗？或者我也许该这样更直白的说，传统的工程学真的给软件产品和项目带来了质量上的提高，以及开发人员技术水平上的提高吗？

      关于这个质量和效率问题，我想大家都心理很明白，事实上工程学真正带来的是一种软件产品和项目大量的按照一种固定模式的量产化得到可能。它真正做到的是我们大多数人能按一定要求实现这个需求。但是究竟实现的好不好，或者说即使实现了，版本的升级，平台的迁移是否要额外的花费更多的成本，如果没有需求，它不会管。量产化的东西只是会按部就班的达到需求，而不会超越需求。这里有一点可能觉得超越需求是一种完美主义的想法。然而这正是软件产品的特点，因为事实上客户在这个系统没有出来之前，是永远也不知道他究竟最终想要的是什么的。往往当系统出来以后，他才发现这不是他想要的东西！

      至于关于开发者技术水平的问题，我想工程学带来的结果是显而易见的。那就是极其严重的两级分化，甚至总体水平在降低！但是讽刺的是，这似乎是符合中国国情的！什么国情？人多！毕业生多！但是研发不需要这么多人！工程学带来的结果是，软件开发工程中一道道工序所需要的不同角色。而显然，程序员被放在了最底层，就像造房子的工人。或者更直白点，程序员这个单词的解释已经发生了变化，现在处于传统开发模式下最底层的程序员，只不过是在写一些包含许多重复劳动的简单的代码罢了，比如从数据库取数据，放数据等等。于是在中国就有了所谓的软件蓝领的称呼，并且直接导致了对程序员的不尊重，更为严重的是，这种不尊重许多来自程序员本身，因此就有了程序员到30岁还做不到项目经理（管理层）就是没出息的这种畸形，变态的想法！（本人严重BS这种想法，所以用了严厉的形容词）。而目前在这些底层“程序员”之上的所谓的有了几年（比如5年）工作经验的开发人员，所架构，设计出来的框架真的优秀吗？（事实上因为有了上述的变态想法，所以很难在中国找到比5，6年更久的程序员了，虽然我曾经遇到几个，他们是真正的程序员！）我可以说，那不可能！一个真正优秀的架构师，设计师，没有10年以上的开发经验是不可能的？在microsoft，在google，在ibm，在sun，他们真正的财富是什么？正是这些写了几十年程序的开发人员！为什么常说中国的软件业不行？那正是因为你们本身不尊重程序员！你看到过有30以下的大师吗？erich gamma,kent benk,richard stallman哪一个是在30岁以下就成名的？

      需求就谈到这里，否则再说下去要成了一篇批判blog了，提出这些complains的理由正是为了要让敏捷开发来解决上述的问题。下面的一篇blog就要谈一下敏捷开发。