软件开发误区

软件工程沸沸扬扬这么多年了，不知道多少年轻学子痴迷于其中，梦想着自己是软件设计师，软件构架师，而把基本的代码视作蓝领工人做的低级工作。我前面写过，不知道中国国内多少软件公司能够把这些真正做到。

我曾经参加过一个培训，说起印度的软件开发，分层分得很细，构造很清晰，人家只要拿到详细设计就能写代码，并且代码写的非常好。什么设计模式，什么测试用例，什么测试驱动之类的。我只是问了一句话：人家的代码是多少行每月。讲师迟疑了一下，300。我就只能笑笑，除了笑，我还能说什么。

而我们目前的状况是大多数公司都是找米下锅，那么就会面临这样一个问题，找到的米并不一定都是能够安装一种方法炮制，经常是这几个人，这几个月可能在作一个MIS软件，下几个月可能就是一个多媒体开发了。而且业务员为了抢单，通常工期都会压缩，而且大家也知道，现在客户是大爷，动不动就是需求变化无常。

在这种情况下，一味按照软件工程项目管理条款来作，估计是很有问题的。

第一，很多项目对于开发者来说，技术上都是不确定的。软件工程的一些思路都是按照建筑来说的，相对来说，建筑技术不会变化很大，无论是别墅还是小区，都是用砖头、水泥等。而项目而言，系统编程、网络编程、桌面编程等等，VB/VC/DELPHI/JAVA，WINDOWS/UNIX都是很难统一一种技术的。所以那些动辄软件工程挂嘴边的人，如果自身技术不够扎实，没有详细的实战经验，那么只能是添乱，设计的构架乱七八糟。

第二，工期紧张，如果按照前期预研、概要设计、详细设计等等一系列作下来，那么我敢打赌，大多数项目最后的结果就是拖延，为什么，一则前期占用了太多的时间，二则，实际开发过程中总会有未曾设想到的问题，那么这些问题最后就会要命。其实，我们看看房地产开发，我们也能发现，大部分房子很难做到如期交房的。或者交房后发现质量问题。

第三，需求变化大，作为一个建筑设计，至少可以保证一条，设计完后，开始施工，变化的空间不会很大，因为这水泥砖头都是实实在在的，而软件不同，可变性强大，客户需求经常变。

所以，我觉得现在的软件开发其实有点类似于 室内装修，竞争激烈，客户要求变化大，工期要求短。

同样的，与其给我10个软件学院毕业的，满嘴模式UML等等的，还不如给我5个大专毕业，熟悉VB或者JAVA的。也许有人会说，这样我鼠目寸光，软件以后维护很麻烦之类的。

但是，我敢打赌，大多数软件的生存周期不会操作两年或者三年，在这个基础上，开发人员的实际开发周期不会操作5个月，日后真正维护的周期不会操作3个月，而真正麻烦的需求变化，随便你什么样的牛人都无法设计出一个只需简单修改的构架。

真正能够做到这一步的只有一点，没有构架，完全模块封装，即使代码冗余，那么还有可能只改模块。如果按照设计模式等，那么实际更改的内容更多。

而我们就是缺少扎扎实实做事的蓝领，大家都追求作一个人上人，所以人家用ANSI C作了SQLITE等一大队开源软件，而我们却把23种设计模式翻来覆去，UML画的出神入化。纸上谈兵啊

所以，我赞赏XP的作下去再说的方法。不管怎么样，实实在在的代码才是软件的根本！ 

XP和传统软件工程都不免走向极端，都很容易导致噩梦……

个人觉得：

传统软件工程是清清楚楚地感觉到自己在做噩梦（工作量超大）；

XP方法是没有意识到自己是在梦魇的前夕（还没见棺材，当然先不用掉泪了）；

相比之下，折中的方法更可行，前些月程序员杂志上那篇1000英尺软着陆的文章，不知道楼主是否在意过。

我同意楼主所说的“完全模块封装”，但是这是有局限性的，不论是横向还是纵向。问题来源很多，如果楼主仅仅是针对一个个的简单技术问题来说，可能问题不是很严重。但是如果是要给一个变数较大的客户（比如一个涉及多领域业务的企业）做系统的话，XP就不免显得单薄了。

纯属个人偏见，仅供参考。

:)