2、设计—编码之鸿沟

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

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

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

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

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

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

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

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

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

　　总结

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