关于代码即设计的随想

记得大三的一堂软件工程课上，留洋归来的老师说，编码在国外已经是蓝领了，想当白领，一定要做设计。根据这种分法，很不幸，我一直都是蓝领。一直以来，有个问题困扰着我。设计是什么？或者设计包括什么？如果把编码看作是工厂车间里的制造环节，为什么工厂加设备加人就能显著的缩短生产周期，而在软件开发过程中，多加几个码农有时候甚至会适得其反？而且如果生产线上经常出错的工人很快就下岗了，但是经常导致编译失败的码农却并不太担心被抄鱿鱼。就像Fred Brooks所说，生孩子要怀胎十月，找来十个孕妇能一个月生出一个孩子？

我们先回顾一下软件工程的两个重要的模式，瀑布模式和敏捷模式。瀑布模式的惯用流程是由SE/DE分析设计并形成文档，然后把文档交给码农编码，最后码农把最终的软件交给测试人员进行测试（一般是黑盒测试）。这样的机械分割的问题至少有两个。首先，冷冰冰的文档言未尽意，再加上人的变化，导致信息的丢失甚至误解。其次，设计由于缺少验证，而且需求的不断变化，编码时甚至测试时才发现设计必须要修改。编码这种对设计的反作用直接的后果是设计文档往往跟代码风马牛不相及。

于是各大门派的大牛们痛定思痛，放下门户之见，集思苦修，终于练成敏捷，江湖为之一振，虾米们竞相转投敏捷门下。敏捷一扫瀑布的文档化和流程化的僵硬死板，展现出拥抱变化的灵活快速。敏捷模糊了设计、开发和测试的界限。从敏捷背后的机制来看，代码即设计虽然“犹抱琵琶半遮面“，但好歹”千呼万唤始出来“。

不同于传统工业的设计和生产之间的关系，软件设计和编码之间的关系非常紧密。现在已经有越来越多的工具，虽然还不够完美，但是可以实现UML图和代码正向和逆向的转换。从某种程度上看，设计文档和代码也许是等价的。从代码即设计的角度，设计和编码是同一头大象两条不同的腿，而构造和测试则是另外两条腿。也就是说，设计包含传统的设计、编码、构造和测试。传统的设计在其中更多是顶层设计，代码则是完备的设计清单，构造和测试是为了验证和优化设计。整个设计过程是一个螺旋上升的环，测试的结果会促使设计和代码的修改和优化。代码即设计，可以很好的解释开头提出的问题。编码并不是工厂里的制造环节，而是设计环节。设计中出现问题是很常见的情况，只要及时改正就不会出大篓子。

在刚接触代码即设计的时候，经常出现一知半截就满腔热血开始践行。很容易把代码绝对化。很潇洒的抛开文档和设计，直接编码，眼前是长发飘飘的Richard Stallman坐在电脑旁不断敲键盘的情景。走了各种弯路而疲惫烦躁时，回过头来断言，代码即设计不对。代码即设计不并是说不需要画UML图，而是说代码也是设计的一部分，好吧，是最重要的一部分。设计拼图中还有另外三个部分。

代码限设计要求人员的融合，而人员的融合又促使组织结构的调整。就像代码架构的调整无异于涅槃一样，组织结构的调整也是举步维艰。除非严重的危机发生，调整很难执行。