IT餐馆—第十六回 驱动

      声明：在写这个系列文章的过程中，园子里有些人投来了怀疑、鄙视、甚至匿名谩骂，当然也有朋友跳出来支持并提出意见或建议的。我这些天想了一下，感觉写文章不一定要让所有人都接受，必定众口难调，有时为了照顾大多数，有时只为与别人进行交流，以提升自己看问题的高度或解决问题的能力。所以在这里我只能对那些反感我所写内容的人提前打声‘招呼’了，千万别再看我写的这个系列了，因为这个系列有些内容在你们眼里只是些‘垃圾’或是‘毒药’，会脏了你们眼的，你们只要看到‘IT餐馆’的字样就权当‘没看见’好了。当然明知‘不应该看’，但‘还要去看’，也许说明你没有管住你手中的鼠标，或只为找个人骂上一通，或出于什么目的。另外对‘这样的文章不应放在首页’这样的话，我相信cnblogs管理团队不是吃闲饭的，他们是有自己的标准来衡量的，请相信他们。如果不相信，非要自己跳出来‘不辞辛苦’的反复说，那就只能悉听尊便了。另外我以后往园子首页发文章的时候也会斟酌一下，考虑一下大家的感受，必定交流的人多了，才能不断学习进步，呵呵。

     开始今天的正文了....

    周六，老杜约雨辰出来吃饭，顺便想问一下关于雨辰公司产品设计方面的一些问题。在酒过三旬之后，雨辰想起了在周五的例行会议时，有位同事提出了测试驱动开发的内容。大家在会上讨论了很多相关的话题，其中的内容也基本上围绕着TDD的一些公认的‘好处’展开。雨辰就随口问老杜对TDD,FDD之类开发方式的看法。没想到这一下子让老杜打开了‘话匣子’。 

    老杜说：“从上大学时学的‘瀑布’，原型方法再到工作后使用的UML，RUP。一路下来，我发现软件工程最不缺的就是方法论了。这几年的MDA,到DDD，以及当下‘火’起来的TDD,FDD。在我老杜眼里看来已不‘感冒’了。我个人认为不管什么方法，只要挑一样用好用精就可以了。而那些过于时髦却没有经过实战检验的方法，我是没精力去追赶了。所谓‘根据公司团队实际情况采用相应的方法’只是一种奢谈。在国内来看，这类方式论的普及和理解层次远没到国外的水平，对于咨询公司而言相应的培训市场也并没理解中那样有利可图。我更认为TDD,这类敏捷实践在国内‘水土不服’。” 

    雨辰听老杜这么说，感觉有些道理，说：“眼下我越来越关注于业务而不是技术本身，感觉这些方法也都是在围绕如何正确理解业务，进行业务领域建模展开的。” 

    老杜听雨辰这么说，接着说道：“呵呵。其实我一直以来有个观点，可能旁人看起来有些极端，我今天就跟你老兄聊聊吧。” 

    老杜接着说：“我一直认为TDD,FDD,DDD，说白了，不就是为了能够让开发人员更清晰的理解所要开发的功能、业务流程、规则，以及对业务模块分解，边界功能的影响，对象的粒度界定等。每种方法都不可能是银弹。只能在其特定应用场景中使用，也许还真有‘不写测试用例就开发不了的情况’，不过可惜的是我没看到。如果不能从中看到可信服的结果或好处，我是不会在产品开发中使用它们的，我只会使用已经过实践‘洗礼’并证明是‘有效’的方法。另外就是使用这些方法论，如果在团队中没有一个有丰富经验的‘过来人’加以指导，任由大家按自己的理解在实际开发中‘滥用’，那这些方法只能让团队成员抛开已成熟的开发流程，投入到这些头晕脑涨的方法论中，这时它们就成了‘搅屎棍’。这些年方法论还不够多吗，还有敏捷那些轻量级的方法，我听这些耳朵已经‘起茧’了。所以如果能有正确‘分析理解业务流程’的方法，那我是真不想再跟它们扯上关系了，靠。使什么方法不是一样开发吗。那些动不动就把这些新概念挂在嘴边赶时髦的开发者，以及那些相关理论的倡导者，还有那些咨询公司，我对他们的做法表示怀疑，我认为成熟公司都已经在市场的竞争中养成了一套适合自己的开发方法，不会轻易被这些方法论搞得‘气血浮躁’。现在我很担心那些自认为理解了那些方法论的开发者，以为自己‘得道’了而去‘挂着羊头卖狗肉’，最后把自己搞的是猪八戒照镜子。” 

    老杜越说越激动，接着说：“比如你前些年的‘偶像’Martin，Martin除了把别人的成果放到自己的书中来炒作外，他自己又有什么真正的贡献。充其量只能算是个‘传教士’，有时我看他更像是个装神弄鬼的。” 

    雨辰叹了口气，想起了当年看重构一书时对Martin的崇拜之情，现在感觉还真是有点‘那个’。不过话又说回来，如果没有这些‘传教士’的工作，那么埋藏在天才头脑中的金子可能不知还要等到何年何月才能发光，必定有些天才不善于与普遍人为伍，在话不投机时，往往选择沉默，而那些‘不识实务’的人还沾沾自喜的以为自己‘占了上锋’呢。 

    老杜接着说：“我现在想到的是从技术领域走出来，进入到业务领域中去。通过对领域模型和业务知识的学习研究，让技术人员成为跨技术和业务的‘两栖人才’。开发产品的人本身就应该成为业务领域的专家。否则自己干的也没劲，冲其量是披着技术躯壳的‘牛’而已。在DDD中无时无刻不再强调业务专家和软件专家的沟通，但业务专家都‘不大可能阅读代码来核对规则，即使在开发人员的指导下’，那技术人员只有自己走到领域中来了。并且国内的企业里有不少岗位是要求‘业务、技术’要求合而为一的，有多少公司的经理，技术高层不是业务技术两手抓呀。另外我是建议开发者真正到应用场景中体验一把，了解一下自己所开发的软件倒底被什么样的人，在什么样的环境下使用，体会他们在使用中遇到的那些令人抓狂的问题，听一听客户是怎么骂自己产品如何如何垃圾的，这样才能使用自己有个清醒的认识。我反对任何在不充分了解业务领域知识的情况下就去开发代码的行为，那基本上就是浪费时间和精力。另外很多人认为领域专家与软件开发人员之间的沟通存在鸿沟，双方都在用自己领域的术语来描述业务和软件系统，导致业务知识从领域专家传递到开发者那边出现断层或误读。所以又费神的提出什么DSL什么的。绕了这么一大圈，而在那些既通业务也晓技术的‘两栖人才’看来，基本上都是瞎忙活儿。还有那些认为‘dsl会将软件开发者从软件领域中驱逐出来’的言论更是扯谈，别人我不知道，我老杜现在就正在不断努力从技术人员扩充成为业务人才，进而完成‘一统软件开发全局’的目标，将那些业务专家赶回老家去。” 

    雨辰听着老杜滔滔不绝的喷着，知道如果不让老杜讲完是不会收兵的，就耐着心听老杜继续说。 

    “说完了DDD,再扯一下TDD，就这个东西，眼下我的观点是‘看热闹’，谁爱做谁做，反正我眼下不打算做，呵呵，还是我之前的那句话，如果通晓了业务需求的话，那TDD的一些卖点就没那么有价值了。因为TDD也无非是通过编写测试用例来不断加深对对软件运行行为的分析以及业务的理解。进而逼近现实的业务需求，并让业务需求更加具体、明确，边界更加清晰罢了。而它里面所说的其它优点比如说：‘TDD不单纯是以测试来驱动代码的编写，而是对整个开发流程的驱动’。我想都是那些狂热支持者头脑发热的产物，真正驱动开发流程的是业务需求（客户那边不断变化的‘需求’）。即‘业务驱动开发’，而最终业务是为了什么呀，不就是钱吗。世上还有什么比‘金钱驱动’更厉害的吗，Money Driven Development （金钱驱动开发）才是王道呀。这是横跨在业务领域和技术领域两方面的驱动方法呀，是我老杜发明的，就暂定为‘杜式定理’吧，开句玩笑，呵呵。” 

    雨辰听老杜这么头脑发热的说着，就善意的解释说：“你说要当什么‘水陆两栖型人才’，但据我所知‘业务专家’不是那么容易练成的呀。不过你到是给技术人员的发展和‘转型’提供了一个不错的方向，呵呵。不过回来头来，为什么眼下方法论层出不穷，特别是敏捷阵营那边，说白了，还是大多数开发者都不是业务专家，要成为某些领域的业务专家，没有十年二十年的光景是练不出来的，那里也需要悟性。更何况有些人可能天生就是做技术的命，他们对技术的兴趣远大于对业务的兴趣。所以多数情况还是“领域专家+软件开发专家”的组合，并希望通过某种桥梁（比如 DSL）让他们两者头脑中的思想起‘化学反应’，让开发出来的软件真正能反映出业务需求。” 

    雨辰接着说：“你刚才说关于业务为中心的观点不错，我眼下是举双手赞同的。但就是眼下方法论过多，你说你的我说我的，外人看着就像是到了集市上，热闹的让人头晕。当然不管是DDD,FDD,TDD还是别的什么DD,我看本质与你刚说的那个观点还真有些碰撞，必定都是为了更好的理解业务（需求），更好更快的设计出可用好用的软件，呵呵。” 

    雨辰喝了口啤酒，想了一想又说：“不过我认为对于国内开发者而言，不可能都有机会与业务专家当面交流，很多都是对着文档或需求说明书（甚至连这个都没有）就直接设计开发了。与其这样做还不如‘先通过写测试用例让自己冷静下来’，分析项目或产品都底应该是个什么样子。也许这不是个适合国情的方法，但它必定提出来了，我想国内很多开发者也是采用‘摸着石头过河’的方式来学习使用它们的吧。另外你之前所说的成修练成‘业务专家’，那你又是从什么方面入手，接触和了解业务核心领域的呢，总不会头脑发热就决定搞一把吧。” 

    老杜说：“目前我也在摸索阶段，不过我的观点是‘与其用那些方法，还不如跟业务人员或业务需求提供方多吃几顿饭，把业务背景，流程，工作场景摸清楚来得实惠’。我们产品目前的业务需求主要来自客户，市场销售人员，技术支持（收集汇总的资料），甚至是某某客户领导或老板的灵光一闪。而DDD中所谓的业务专家目前很难碰到，多数是客户那边找个领导牵头，然后让他们手下的人提意见和需求，最后就把这些问题带回来进行设计了，如果在设计中出现问题再电话或去现场沟通。我想这也是目前国内普遍存在的情况。所以我才说问人不如问已，如果你就是业务专家，自己就代表主流业务需求，那还何必被那些客户牵着鼻子走，一句话，我就是标准，不就结了。” 

    雨辰接着说：“其实我也赞同你关于‘做产品开发的人就应该是业务专家’这一说法，因为产品不同于项目，其生存周期和开发时间都远比做项目充裕，正好可以利用这个时间来研究、学习，‘恶补’业务领域方面的知识，这样才能让自己有‘沉淀’，增加自己的核心价值和竞争力。我之前就觉得做项目除了积累一些通用代码之外，对业务根本就没什么理解，往往一个项目完事，开了总结庆功会就完了。而做出来的东西自己都不太清楚能干什么，感觉自己就是一头上了磨的瞎驴，干一年也是它，干五年也是它。最后没项目做了，大家就转投别的公司。年轻时这样折腾也许行，可上了岁数怎么办，虽然这年岁铁饭碗少了，但相信对于开发者来说还是希望自己能最终踏实稳定下来吧。” 

    老杜笑着说：“我感觉你与我一样，都是在找出路，一条让开发者能将所学技术受用一生而不是一时的‘出路’。我之前也没想过太多，但老刘那档子事让我触动不小，也许老刘的今天就是你我的明天。去年有个叫阿朱的写了本《走出软件作坊》，你看过没？” 

    雨辰笑着说：“我在网上看了两遍，后来买了一本又看了两遍，感觉挺受用的。” 

    老杜叹了口气，说：“我只能感叹他遇上了一个开明的老板，能让他将头脑中的想法变为切实可行的方案。其实他的有些方法我之前也摸索过，只不过老板过于保守，不愿进行变革，再加上公司‘元老派’的阻挠，就一直不能采纳。结果我这些年也变得越来越世故了，热情也在被慢慢耗尽，可悲呀。” 

    雨辰听老杜这么说，感觉他好像变了个人，不再是昔日那个锋芒毕露的老杜了，不禁心生无耐的说：“如果你感觉所在公司做事有种‘被埋没了的感觉’的话，那就跳吧。人挪活树挪死。” 

    老杜一脸坏笑的说：“我已在给我自己找买家了……”


    之前文章链接：
    IT餐馆—第十四回 架构
    IT餐馆—第十五回 云端