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

想在园子里写点东西已经好久了，但一直没有落笔，忙着作 一块儿帮 的开发直播，还有些软文作推广，还要作奶爸带孩子，还要……好吧，我认可，真正的缘由是：

太特么的难写了！

 

但再难写也要写啊，要等到“能写好了再写”，怕是黄花菜都凉了——尤为是技术类文章，时效性很是强的。

恰好坛子里这篇博客：关于拒绝测试驱动开发（NoTDD），看评论争议不小，而这个问题也是我最想写的，因此，蹭个热点，呵呵。

 

其实我很好奇，博客下面热烈讨论的童鞋，有多少人是真正的在项目中坚持过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，但一旦出现bug，fix bug以前，首先写unit test，而后在fix。（惭愧啊，仔细想一想，这一点我都没彻底作到，(⊙﹏⊙)b）

 

其实我以为呀，固然仅仅是“以为”了，大多数的“大牛”们，实际上是明白这一点的——虽然他们从没有像我这样系统明确的表述出来。

我这样推断的缘由是：现实中确实没有太多TDD实践的项目。

实践TDD的机会实际上是很是渺茫的，就我目前能想到的：

1. 开发团队，尤为是架构师必须有至关的水平。我在架构之路（三） 单元测试就讲过：单元测试不是那么好写的！凡是可（易于）测试的代码，必定是“低耦合”的，模块之间是具备至关大的“独立性”的，否则相互牵连，将很是难以测试。而随着业务逻辑的耦合度（复杂度）愈来愈高，解耦的难度也就愈来愈高。反正据个人观察，通常的开发团队根本hold不住。有时候想一想，很是之诡异：耦合度不高的项目，其实又没有多大的必要作TDD？
2. 项目负责人对项目可以长期存活具备强大的信心。TDD的实践，是前期投资，后期收获。至关长一段时间，你都会以为写单元测试很是无聊，只有到了后期，业务逻辑愈来愈复杂，处处都是千丝万缕的联系，牵一发而动全身，常常一改动单元测试就跑不过的时候，你才会以为“咦？这玩意还真的有用呢！”可是，注意这个可是，项目负责人有没有足够的信心：这个项目能撑到那个时候？！市场朝三暮四变化无常，几乎全部人都是走一步看一步，摸着石头过河，哪里能顾得那么长远？
3. 项目从一开始就不赶工期，容许使用大量（至少是双倍）的时间来写单元测试。就算是我有信心这个项目没问题，但时间容许不容许？商场上争的就是一个先手，快鱼吃慢鱼，要快，要抢先占领阵地。这就和强行军同样，确实有不少问题，不如步步为营稳妥，没有重武器，会有掉队减员，部队很是虚弱……但只要先到达阵地，其余一切都在所不惜。

因此，我很是好奇，究竟有多少童鞋真正参与过一个严格按TDD模式实施项目？

 

那么，TDD是否是就不值得学习了呢？

固然不是的！

 

+++++++++++++++++++++

 

真的顶不住了！

12点了，超级 =_=

展开写还有很长很长，强写脑力也跟不上了。先这样吧，有时间咱们下次再聊，晚安，各位。

 

呵呵，偶然中发现的，小小的一个成就，记念一下。