也谈TDD，以及三层架构、设计模式、ORM……：没有免费的午餐

其实我很好奇博客下面热烈讨论的童鞋有多少人是真正的在项目中坚持过TDD的。我公司里的项目从来没有哪一个项目是要求TDD、能够TDD的我自己的项目坚持过TDD一段时间而且应该是非常久的一段时间尤其是Entity部分但现在我基本上都已经放弃了。为什么呢可以洋洋洒洒千言万语也可以简简单单三个字不划算。其实不仅仅是TDD还包括三层架构、设计模式、ORM等等这些东西存在大量的争论莫衷一是说它好的把它捧到了天上去说它不行的批得它体无完肤双方都有大牛为其站台都可以一二三四五的列出长长的清单而且每一条都很有道理……当讨论变成了一种辩论当辩论变成了一种骂战最后拼的就是谁的态度更坚决谁的言辞更犀利谁的声音更大……所以双方的观点更加的偏激、对立而这其实无助于我们客观冷静的来分析问题。说理太枯燥了点还是听飞哥讲故事吧呵呵。最早我刚接触“设计模式”。什么玩意儿啊整本书就一个感觉“脱了裤子放屁”。明明一个对象new一下不就OK了么什么Factory啊Builder啊搞毛线呢所以一直是云里雾里的包括那些开闭原则、依赖倒置都似懂非懂的没帮上我什么忙。直到有一天也不知是在哪里我看到了三个字“上下文”或者说一句话大意是只有理解了上下文理解了设计模式想要解决的“问题”你才能真正的理解设计模式。不知道是不是那时候积累也差不多了茅塞顿开恍然大悟我在架构之路一目标里说过设计模式是药看评论其实很多同学没有理解对照这句话看能不能明白过来理解了设计模式想要解决的“问题”……要解决的问题就是“病”没病就不要乱吃药同理没有“问题”你也不要乱用设计模式。一通百通。所以从最基础的面向对象、到三层架构、ORM、以及敏捷开发、TDD……所有这些概念方法本质上都是要解决问题的而且基本上也是能够解决问题的。而你认为它“没用”其实最大的原因是你还没碰到这方面的问题。在这里大家一定要区分两个概念“它解决不了问题”和“它对我没用”。还是用药做比喻“这药治不了病”和“这药对我没用”是两个概念。而且尤其要注意的是这两个字对我。换到项目中就是这种架构这种开发模式适不适合这个项目能不能解决这个项目开发中遇到的问题。其实之前我也看到过类似的提法比如xxx适合“大”项目。但用“大”和“小”来区分项目毛糙了一些很多时候并不见得正确。最正确的做法是你了解项目的特点同时也了解各种模式的优劣从而能够正确的匹配和选择。当然这是一个非常庞大的话题这里没办法展开了。好上面我们提到了“优劣”所谓优势和劣势但其实这个提法并不准确。优势大家都可以承认解决了问题嘛但劣势……什么叫做劣势不服……我更愿意用另一个词成本。“天下没有免费的午餐”。这是一个经济学上的谚语。一提到这话我就想起我大学的时候坐在教室里听老师讲《西方经济学》……往事历历在目谁曾想我会是今天这个样子再说点题外话吧。【野生程序员】优先招聘是意气之作但并非完全意气用事在我该不该转行一野生程序员的优势一文里我就较为详细的阐述了野生程序员的优势。简单的说做架构做项目管理需要一个更宏大的视野而不仅仅是二进制和计算机原理。这里我们还是回过头来看什么叫做“天下没有免费的午餐”不要理解为“做人不要贪心以免上当”之类的哟你可以理解为做任何事情都需要成本。但我更喜欢另一种说法凡是选择必有代价。具体到项目中不管注意是不管无论随便……你选择是不是遵循TDD的规范要求只要你选择了就必然有代价不使用TDD就会在代码的重构、维护、健壮性等方面付出代价使用TDD就会在测试代码的开发和维护上付出额外的代价。无论你怎么选一定是要付出“代价”的。换言之代码的“低耦合”“可测试”“便于重构”……不可能从天上掉下来一定是有成本的这本来是一个最简单不过的道理。然而当我们迫切的想达到一种目标——尤其是这种目标是美妙的、神圣的、寄托了我们某种强烈情感的时候我们常常会忘记达成这个目标的成本。就个人而言就是通宵达旦废寝忘食乐此不疲这是你自个儿的事但对于团队对于项目呢“不计一切代价”就是一种蛮干就是瞎搞后果往往是灾难性……另一个很有意思的现象我们的舆论我们的文化是鼓励“不惜一切代价”是鼓励“克服重重困难”的这会让我们有一种莫名的冲动、一种热血沸腾的快感。理智和感性天然就是不兼容的那么我是反对TDD的如果你心里还有这样的想法说明你还是没弄明白我在说什么。无所谓支持和反对没有这样简单化的答案。事实上你需要的是做一个成本和收益的分析针对特定的、具体的项目没有一个放之四海而皆准的准则。不同的项目有不同的要求应该因地制宜的采取相应的策略。这样谈下去还是会很空我以 一起帮 为例。我为什么要放弃TDD因为我对这个项目没有太大的信心我目前最需要的是尽快的把项目的原型拿出来放到市场上进行检验大家喜不喜欢有没有前景收集正面的反面的意见反馈……如果大致符合预期我就继续做下去否则就要快速的进行调整。而我现在的人手又非常有限好吧其实就我一个人所有的代码都得我一个人写好在网站出bug问题不是很大所有的用户都是种子用户他们可以直接的给我反馈而不会因为一两个bug离我而去……所以综合上面种种考虑我并不需要TDD至少暂时不需要。也就是说代码质量差一点就差一点可以忍受。如果项目击中了用户的痛点我可以以后花更大的代价来“补”如果项目针对的是一个“伪需求”我就应该尽快止损。你看并不是TDD不好并不是TDD没用而是我现在“用不着”——这才是三观最“正”的最无懈可击的理由。·顺便说一下我现在采取的策略我把它称之为“懒人策略”一开始不写unit test但一旦出现bugfix bug之前首先写unit test然后在fix。惭愧啊仔细想想这一点我都没完全做到(⊙﹏⊙)b其实我觉得呀当然仅仅是“觉得”了大多数的“大牛”们其实是明白这一点的——虽然他们从没有像我这样系统明确的表述出来。我这样推断的原因是现实中确实没有太多TDD实践的项目。实践TDD的机会其实是非常渺茫的就我目前能想到的开发团队尤其是架构师必须有相当的水平。我在架构之路三 单元测试就讲过单元测试不是那么好写的凡是可易于测试的代码一定是“低耦合”的模块之间是具有相当大的“独立性”的不然相互牵连将非常难以测试。而随着业务逻辑的耦合度复杂度越来越高解耦的难度也就越来越高。反正据我的观察一般的开发团队根本hold不住。有时候想想非常之诡异耦合度不高的项目其实又没有多大的必要做TDD项目负责人对项目能够长期存活具有强大的信心。TDD的实践是前期投资后期收获。相当长一段时间你都会觉得写单元测试非常无聊只有到了后期业务逻辑越来越复杂到处都是千丝万缕的联系牵一发而动全身经常一改动单元测试就跑不过的时候你才会觉得“咦这玩意还真的有用呢”但是注意这个但是项目负责人有没有足够的信心这个项目能撑到那个时候市场朝秦暮楚变化无常几乎所有人都是走一步看一步摸着石头过河哪里能顾得那么长远项目从一开始就不赶工期允许使用大量至少是双倍的时间来写单元测试。就算是我有信心这个项目没问题但时间允许不允许商场上争的就是一个先手快鱼吃慢鱼要快要抢先占领阵地。这就和强行军一样确实有很多问题不如步步为营稳妥没有重武器会有掉队减员部队非常虚弱……但只要先到达阵地其他一切都在所不惜。所以我非常好奇究竟有多少童鞋真正参与过一个严格按TDD模式实施项目