【IT168 分析评论】

    想省掉一些功夫，必须是知道有某种因素存在，所以可以省去，绝对不能忽略风险，贸然地取捷径。

    许多团队的开发流程，看似井井有条、制度完整，但流程中所规画的活动，无法在开发参与者的进行下，达到它应有的效用。很容易让开发人员产生一种负面的印象──开发流程的活动不过是表面文章、敷衍了事、徒做虚功。也让许多开发者，对于开发流程的活动敬而远之。

    不认同徒具形式的流程，许多团队转向轻量级方法论

    因此，在光谱的另一边，也有一类团队，尽可能地裁减所需的开发流程活动。这样子的团队，多半是以开发人员为主的团队，对他们来说，程序撰写以外的工作几乎都会被归类为“额外负担（Overhead）”，就像我们很常见到的，开发人员视写文档为额外负担，因为文件的内容往往不能直接转换成为代码，而且有时候甚至和代码的产出一点关系都没有。

    对他们来说，开发想要更有效率，就要尽可能减少额外负担。当然，文挡的撰写肯定是他们首先要打倒的万恶罪魁，非到万不得已、山穷水尽的局面，绝对不撰写任何文档。

    我甚至看过有些团队的管理者，认为版本管理活动是一种额外负担，因此，虽然他们也设置版本管理服务器，但是，开发者并不利用它进行版本管理的活动。这某种程度算是管理者体贴开发者的一份心意，因为管理者希望让开发人员专心撰写代码，尽量避免其他活动干扰到这最主要的工作。

    对这类的管理者来说，追求制度不过只是形式上的表面功夫，事实上，里子更胜于面子，产品应该以更有效的方式开发。为了达成这目的，应该尽量摒除各种额外负担。

    尤其近来轻量级的开发方法大行其道，这更让这类团队找到一个依靠，当中有许多人宣称他们自己是轻量级的开发方法，因为他们摒除了许多开发流程所带来的额外负担，所以他们认为自己的开发方式轻盈无比。

    XP有12项准则，不能只选甜头，忽略苦差事

    我曾经听过不只一位朋友说过类似的话：“我们采取的开发方法是XP（eXtreme Programming），我们的交付周期很短、需求也变更得很频繁、甚至没有太详细的需求记录文件，几乎不做细部设计。”这看起来，应该算是误解了XP，而且只从XP挑一些对开发人员来说是“甜头”的东西出来实行。

    怎么说呢？XP有12项施行准则，其中有许多准则是互为支持的。例如，倘若你希望小版本的持续交付（也就是说，需求能够变更得很频繁），你得强化单元测试及重构。因为当你的需求变更频繁时，自然造成代码的变更频繁，倘若没有足够的单元测试做为后盾，那么变更频繁的代码，势必经常地造成副作用，对程序的稳定度造成很大的冲击。同样的，倘若没有持续地重构，那么代码最后也会形成叠床架屋的情况。

    小版本持续交付是甜头，因为提出需求方可以很快看到自己的愿望被实现。允许需求变更频繁也是甜头，因为这使得提出需求方能更快地反馈他对开发成果的修正意见。

    但是，许多号称是采用XP开发方法的团队，都不做单元测试，他们也不持续重构，因为这两个工作都是苦差事。单元测试的确是苦差事，在XP强调“测试先行”的情况下，还没写代码之前，就得先写好测试用例，而且每个代码单元都应该搭配相应的测试用例。要开发人员养成写这类用例的习惯，简直比要他们写文档还要命。

    重构也是苦差事，不仅许多开发人员不具备重构的技巧，即使具备重构的能力，也抱着“做好的事，何必再改变”的心态，对于整理代码渐渐产生的遗毒，始终兴趣缺缺。像单元测试及重构这类工作，在许多人的认知里，都是对开发人员的某种“额外负担”。

    所以，许多团队其实是挑软柿子吃，他们的眼里只看到可以抄捷径的地方，却没有在意这些轻量级的开发方法之所以能抄捷径，是因为有其他的配套。

    比如，XP之所以允许对需求的描绘尽量精简，是因为施行准则中有一则是要求客户和开发团队位在同一个地点，因此，客户能够很快看到系统的面貌及行为，也能够面对面和开发团队沟通，减少了所需的文件。倘若没有客户的条件配合，那么过于精简的需求描述方式就会产生极大的危机，因为开发团队对于需求产生误解的机会就会大增。