引言

软件开发到底是更像工程还是更像艺术一直是业界争论的焦点问题，不管这个问题的结论如何，它都反映了人们实现软件开发的工程化的愿望。但是在这个工程化过程中却被若干问题困扰着，以至于人们产生了软件开发本身就是一种艺术创作，无法用工程化的方法对其进行管理的想法。

软件开发真的不能工程化吗？软件工程真的不能摆脱"艺术创作"的阴影吗？首先让我们来分析软件工程和其他工程发展的差异。

软件工程与建筑工程之对比

《营造法式》可以说是中国版的建筑工程"设计模式"，而人类关于建筑工程的实践则可以追溯到数千年前。古埃及的金字塔，古巴比伦的空中花园，中国的万里长城都是古代的巨型建筑工程的代表。金字塔、空中花园、万里长城绝对是人类历史上最璀璨的结晶，但是他们都是成功的项目吗？我想这个问题谁也不能回答，因为没有一个标准来衡量这些伟大的项目是否是成功的。这些项目在建造的时候是否有投资控制，是否有进度要求，是否有质量目标，这些我们都不得而知。因此，虽然这些都是伟大的建筑，但是我们不能说他们就是建筑工程的成功实践。

有大量的数据表明能够同时满足质量、成本、进度要求的软件项目，即成功的软件项目是少之又少，那么是不是所有的成功的建筑工程项目就是完全满足了质量、成本、进度的要求呢？这个问题我们不得而知。

建筑工程相比软件工程来说，其投资预算的准确性要比软件工程高的多，而质量有标准可以衡量，并且那个标准还是相当的宽松。在进度方面，软件工程不能采用建筑工程中使用的那种增加施工人员和机械台班的方法来使进度按比例加快。种种原因足以让软件工程有充分的理由来让他的成功率低于建筑工程。但是这不是将软件工程的较低成功率归结于"软件是艺术创作"的理由。

另外建筑工程之所以能够获得广泛认可的原因关键在于两样东西：建筑模型（表现图）和施工图纸。这两样东西的存在将最终用户、设计单位和施工单位彻底的划分开来。建筑模型（表现图）联系着用户和设计院，是他们的共同语言，设计院用建筑模型（表现图）来描述并确认用户的需求。施工图纸则能够指导具体施工，虽然它没有规定施工的过程和采用的技术，但是它确定了施工的结果，施工单位根据施工图纸进行施工就能够建造出符合设计的建筑。这两种技术清晰、无二义的表达了双方的意图，这就是建筑工程成功的诀窍。

在软件工程中，软件企业目前只需要和客户打交道，设计和编码并没有分开由不同的企业来实施（软件编码外包除外）。那么这第一条鸿沟就出现在用户和软件企业中间的需求理解和如何由需求导出设计中。遗憾的是软件工程中的需求确认不能像建筑工程中那样将建筑用笔画出来，软件是无法用艺术家的笔来描绘的。

关于软件需求的获取与确认一直是软件工程中的大问题，但是随着UML中用例图的引入而使得需求获取技术得到了长足的进步，用例技术让需求分析简单并且真实，客户也比较容易接受这种图文并茂的方式，解释一堆"小人"的工作让整个需求工程充满了乐趣。

UML很好的解决了需求工程中需求获取和确认的问题，但是却没有给出如何将需求转换成设计的方法，序列图和活动图都不足以正确的将需求转换成软件模型，在这个中间我们缺少一种方法让需求转换成软件设计。

软件的设计和编码不进行分离是产生"软件开发是艺术"、"编码是艺术"的论点的根本原因。设计本来就是一种艺术创作，服装设计是艺术，建筑设计是艺术，软件设计同样也是艺术。但请不要将设计和开发混为一谈，开发描述的实现过程，即编码过程，而设计在软件工程中最具代表性的是软件架构设计。

将艺术创作性的工作剔除除去，将设计与实施分离是任何行业工程化的基础。

鸿沟存在的原因

这两条鸿沟就如同长江和黄河将我国划分为华北、华中和华南一样将软件开发划分为需求、设计与实现三个阶段。如果能够架起这三个阶段鸿沟上的桥梁，我们就完全能够真正的贯彻软件工程的思想。但是这样的两座桥梁为什么迟迟没有出现呢？

1、需求-架构之鸿沟

需求与架构没有一对一的关系，他们虽然相互牵连影响，但是关系却比较模糊。就如同一个酒店投资者告诉设计师他需要建一栋100间客房的酒店，设计师只知道客户需要100间客房，并不知道客户是要10层、每层10间，还是要5层、每层20间一样。投资者也并不知道自己是需要10层还是5层，他只能告诉设计师，他要气派一点还是需要节约投资，或者是两个综合考虑取最佳方案。这就是需求，相当模糊的需求，设计师需要依据自己的经验来为客户做决定，然后他会在自己的头脑中构筑一下整个建筑的模型，最后告诉自己的客户："10层、每层10间的成本太高，没有性价比；5层的性价比比较合适；另外如果改成6层、每层20间，即增加20间房间的话，投资只会增加5%，并且外观上更有气势。"

软件架构的设计如同建筑方案设计一样充满着创造性，并且需要经验来支撑。建筑设计师理解客户的需求，在头脑中思考，然后用手中的素描笔勾画出来。软件架构师根据客户需求，选择适合的软件架构模型，然后用原型告诉客户我们将做一个什么样的软件，客户并不会要求设计师采用什么样的架构，实际上客户也不可能懂得软件架构，不要给客户太多的自由选择机会，架构师必须指导客户选择正确的软件架构，而不要让客户来主导这一切。

可惜的是，我们十分缺少优秀的架构师。那些不合格的架构师无法为客户进行正确的选择，不能对客户提供正确的指导，他们能够做的就是抄袭类似项目的架构设计，谁知道别人的架构是否适合自己的项目呢？试想一下，你将你的酒店设计交给一个有10年建筑施工经验的工程师来做将会是什么样的后果。在软件设计阶段，我们需要选择优秀的软件架构设计师，而不是选择优秀的程序员。

2、设计-编码之鸿沟

在没有将设计和编码完全划分开的软件企业是无法体会到设计和编码之间的鸿沟的，因为同一个人同时兼了两种不同的工作，但是一旦将这两种不同的工作交由不同的人来负责的话，沟通就成为了设计与编码之间最大的障碍。设计与编码之间的沟通问题在实施外包项目的公司中最为突出，很多软件公司只做设计和核心编程，而将外围或者那些不是很重要的软件模块外包给其他公司来做，这样就出现了设计与实现分离的情况。为了保证外包出去的软件模块完全按照要求被开发出来，设计必须要做得很仔细并且不会产生歧义。

采用面向接口的设计和编程很好的保证了开发出来的模块符合设计的要求，设计师不仅需要提供模块实现的功能要求和接口，还需要提供模块内的类的详细设计。只有这样才能够保证最终开发出来的模块不仅能够实现功能，还能够保证模块的稳定性、安全性、可维护性等达到软件的整体要求。

负责编码的外包业务承接公司只需要按要求进行编码，不需要对设计上面任何问题负责，就如同建筑施工企业只需要按照施工图纸施工，由于设计问题而导致的责任事故是不需要施工单位负责的。编码方只需要将设计中的所有类按要求实现并组装成为待提交的模块，进行充分的测试，保证提交的软件模块是按照设计的要求实现的即可。这样将设计与编码的责、权、利进行分开，很好的保证了各司其职，不会导致设计和编码方互相埋怨和推委。

既然设计和实现可以分离，为什么目前的软件开发还是采取这种"一锅粥"的开发模式呢？我想这与设计与实现由同一家公司来承担有着决定性的关系。由于设计和编码由同一个团队负责，因此设计师在编码阶段还能够回过头去修改设计甚至是软件架构，这种宽松的环境使得设计师不会全心的投入到设计中，因为他知道后面还有机会弥补。而建筑设计一旦将设计发布，将要对设计负法律责任，这样给设计师形成了必须要将设计做好、做到位，否则就可能要对自己的设计错误做经济赔偿，严重的甚至可能会惹上法律官司。

外包企业的设计和编码分离得就很好，因为在外包业务中，设计的错误最终引起的是自己的损失，而这种设计错误很容易追查设计者的责任。分工明确、责任清晰的企业中，越容易进行设计与实现的分离。

跨越鸿沟，实现软件开发工程化

"一桥飞架南北，天堑变通途"，这是毛泽东对南京长江大桥的评价。

不管是多么难以逾越的鸿沟，只要找到了沟通的方法，就等于架起了一座桥梁。软件工程中缺乏的就是这样的桥梁，一座是将需求转换成软件模型的桥梁，另一座是软件设计与软件编码之间描述的桥梁。如何才能架设这两座桥梁不是技术的问题，而是人和管理的问题。第一座桥梁需要具有丰富经验和行业知识的软件架构师来担当，需要能够将业务领域模型正确的映射成软件架构，要清晰的掌握软件架构中的优点与缺点，为客户提供正确的决策服务。第二座桥梁需要在管理上将设计和实现分离，采用不同的队伍进行这两种工作，明确各自的责任、权力和义务，采用面向接口的设计和编码，定义好设计表示和理解的标准，要形成整个行业的标准，才能够真正实现工程化。

在这里，我提到的是实现"软件开发工程化"。因为软件工程的整个过程不仅仅是制造的过程，他也包括了设计的过程。艺术创作的过程是无法实现工程化的，这个过程更多的不是需要流水线的生产，而是需要灵感和创新。因此，软件的架构设计无法纳入工程化的范围。而软件的编码则十分适合工程化的管理流程，每个程序员针对已经定义好的类的结构和功能进行填空式的开发，程序员不需要知道他编写的代码用在什么软件，实现什么功能，不需要了解任何业务方面的知识。如何快速的编写符合要求的代码就是他们的使命，从这点来看，程序员有点类似于机器化大生产的生产机器，但是程序员懂得思考，懂得如何以最优化的方法来实现已经定义好的类。

总结

软件总是以一种神秘的形态让人琢磨不定，软件开发过程同样让人无法完全驾驭。在磕磕碰碰中前进，在探索中发展，是软件工程这几十年的艰辛过程。软件工程中，既有严格定义的瀑布开发模型，又有小巧敏捷的编程，这些不同的方法论都有着他们各自生存的环境。软件工程不仅仅是方法论，更多的是管理方法，那些不改变企业和项目的管理方式而抱怨某种软件工程方法不正确的人，根本就没有真正理解软件工程。在实践中查找问题并进行解决，才是软件工程发展的原动力。(csai)