软件开发中的弊病

关键字：软件开发 弊病  笔者此前从事的是软件开发工作，一直到现在心里总是一个疑问接一个疑问。那就是“对软件开发而言，设计到底指的是哪个阶段呢？”。由软件工程师转行为记者后，笔者有机会采访了形形色色的系统工程师和程序员，这一疑问也越来越难以释怀。 

　　一般来说，商业应用的开发可以分为设计和制造（编程）两个阶段。软件开发人员则有设计人员（主要是系统工程师）和程序员之分，先由设计人员写出“设计书”，然后由程序员来编程。设计书式样各异。由于是第一道工序，所以就有可能会使用DFD(data flow diagram,数据流图)、ERD（entity-relationship diagram,实体关系图），或者最近颇为流行的UML(unified modeling language,一体化建模语言)。如此说来，所谓的设计阶段就是指“设计人员完成设计书然后交给程序员”这么一个过程。 

　　当然，不能否认尽量以简单的模块来实现复杂的软件结构这一工作的重要性。但是，单靠设计书就真的能开发出软件吗？至少笔者还从来也没有听说过“只凭设计书就能自动生成所有代码”的说法。目前能够实现这一任务的CASE（computer aided software engineering）工具也还没有开发出来。 

　　这样一来，程序员就得仔细阅读设计书，深挖“字里行间”的要求，并解决设计阶段无法预见，但在编程过程中出现的问题。特别是随着近来技术革新速度的加快，比起自动代码生成技术来说，还是人更容易跟上形势。但是这种情况下，如果设计书比较含糊，或者程序员能力不足的话，就可能会开发出功能不全或及性能不佳的软件来。 

　　这一点正是软件开发同其它工程领域最显著的不同之处。比如说工业产品的设计书（设计图）是绝对的，只要有设计书，那么拥有相同的制造设备的生产商就能生产出相同的产品（当然也有例外）。而在软件开发领域，软件开发的编程阶段主要依赖于程序员的能力而不是设计书。由程序员完成的软件与设计书的内容大相径庭的例子也并不少见。也就是说设计书并不能起到像机械加工方面的设计图一样的作用。 

　　笔者最近开始思考这么一个问题：与其说问题出在设计书的内容上，倒不如说是设计工程的方法本身出现了错误。促使笔者产生这种想法的契机是美国软件技术人员Martin Fowler写的论文“The New Methodology”（http://www.martinfowler.com/articles/newMethodology.html）。Martin Fowler在该论文中写道“软件开发的全部过程都属于设计，制造阶段仅仅指编译和联接过程”。另外Martin Fowler还主张“源代码才是真正的设计书。直到编程作业都应算做设计阶段”。 

　　笔者认为，这种想法从根本上改变了设计人员与程序员之间的关系。话虽如此，实际上大多数程序员还是仅仅被看作是从事简单的重复劳动的人员，不管他们付出怎样的辛勤劳动从事编程作业，都难以得到公正的评价。实际上，整个软件业界都有这么一种印象“比起程序员来说，设计人员更加优秀”。笔者也曾经接受过上司这样的教导“要朝高级设计人员努力！不要再做程序员了”。这其中的逻辑就是：只有成为设计人员才是升职之道，而程序员随时可以从外面招聘。 

　　如果大家都认为程序员只不过是成为设计人员的一个跳板的话，那么谁也没有情绪老老实实地干活了。这样下去要培养出优秀的程序员可就难上加难了。而且从设计人员与程序员的力量对比来说，程序员也还是处于不利的地位。笔者认为，最近被人们挂在嘴边上的职业道德危机及软件质量低下的问题，实际上原因正在于此。 

　　或许重新审视编程并将其纳入设计过程，就会为目前僵硬的软件开发体制提供一个洗心革面的机会。因为这样一来，比起做出周密的设计来说，人们会更加关注如何才能写出优秀的程序来。



注:这是我在网上搜到的一篇文章,对程序员很有益.

原文转自：http://www.ltesting.net