HTML5技术

也谈TDD,以及三层架构、设计模式、ORM……:没有免费的午餐 - 自由飞

字号+ 作者:H5之家 来源:H5之家 2017-07-07 08:01 我要评论( )

想在园子里写点东西已经很久了,但一直没有落笔,忙着做 一起帮 的开发直播,还有些软文做推广,还要做奶爸带孩子,还要好吧,我承认,真正的原因是: 太特么的难写了! 但再难写也要写啊,要等到能写好了再写,怕是黄花菜都凉了尤其是技术类文章,时效性非

想在园子里写点东西已经很久了,但一直没有落笔,忙着做 一起帮 的开发直播,还有些软文做推广,还要做奶爸带孩子,还要……好吧,我承认,真正的原因是:

太特么的难写了!

 

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

刚好坛子里这篇博客:关于拒绝测试驱动开发(NoTDD),看评论争议不小,而这个问题也是我最想写的,所以,蹭个热点,呵呵。

 

其实我很好奇,博客下面热烈讨论的童鞋,有多少人是真正的在项目中坚持过TDD的。

我公司里的项目,从来没有哪一个项目是要求TDD、能够TDD的;我自己的项目,坚持过TDD一段时间,而且应该是非常久的一段时间,尤其是Entity部分,但现在我基本上都已经放弃了。

为什么呢?

可以洋洋洒洒千言万语,也可以简简单单三个字:不划算。

 

其实不仅仅是TDD,还包括三层架构、设计模式、ORM等等这些东西,存在大量的争论,莫衷一是:说它好的把它捧到了天上去,说它不行的批得它体无完肤,双方都有大牛为其站台,都可以一二三四五的列出长长的清单,而且每一条都很有道理……

当讨论变成了一种辩论,当辩论变成了一种骂战,最后拼的就是谁的态度更坚决,谁的言辞更犀利,谁的声音更大……所以双方的观点更加的偏激、对立,而这其实无助于我们客观冷静的来分析问题。

 

说理太枯燥了点,还是听飞哥讲故事吧,呵呵。

 

最早,我刚接触“设计模式”。什么玩意儿啊?!整本书,就一个感觉,“脱了裤子放屁”。明明一个对象,new一下不就OK了么?什么Factory啊Builder啊,搞毛线呢?所以一直是云里雾里的,包括那些开闭原则、依赖倒置,都似懂非懂的,没帮上我什么忙。

直到有一天,也不知是在哪里,我看到了三个字“上下文”,或者说一句话,大意是:只有理解了上下文,理解了设计模式想要解决的“问题”,你才能真正的理解设计模式。不知道是不是那时候积累也差不多了,茅塞顿开恍然大悟!

我在架构之路(一):目标里说过:设计模式是药,看评论其实很多同学没有理解,对照这句话看能不能明白过来:理解了设计模式想要解决的“问题”……?要解决的问题就是“病”,没病就不要乱吃药;同理,没有“问题”,你也不要乱用设计模式。

 

一通百通。

所以从最基础的面向对象、到三层架构、ORM、以及敏捷开发、TDD……,所有这些概念方法,本质上都是要解决问题的,而且基本上也是能够解决问题的。

而你,认为它“没用”,其实最大的原因是:你还没碰到这方面的问题。

在这里,大家一定要区分两个概念:“它解决不了问题”和“它(对我)没用”。还是用药做比喻,“这药治不了病”,和“这药(对我)没用”是两个概念。而且尤其要注意的是这两个字:对我。

换到项目中,就是这种架构这种开发模式,适不适合这个项目,能不能解决这个项目开发中遇到的问题。

其实之前我也看到过类似的提法,比如:xxx适合“大”项目。但用“大”和“小”来区分项目,毛糙了一些,很多时候,并不见得正确。最正确的做法是:你了解项目的特点,同时也了解各种模式的优劣,从而能够正确的匹配和选择。当然,这是一个非常庞大的话题,这里没办法展开了。

 

好,上面我们提到了“优劣”,所谓优势和劣势,但其实,这个提法并不准确。优势,大家都可以承认,解决了问题嘛;但劣势……什么叫做劣势?不服……

我更愿意用另一个词:成本。

“天下没有免费的午餐”。

这是一个经济学上的谚语。一提到这话,我就想起我大学的时候坐在教室里听老师讲《西方经济学》……往事历历在目,谁曾想,我会是今天这个样子?

再说点题外话吧。

【野生程序员】:优先招聘是意气之作,但并非完全意气用事,在我该不该转行?(一)野生程序员的优势一文里,我就较为详细的阐述了野生程序员的优势。简单的说:做架构,做项目管理,需要一个更宏大的视野,而不仅仅是二进制和计算机原理。

这里,我们还是回过头来看,什么叫做“天下没有免费的午餐”?不要理解为“做人不要贪心以免上当”之类的哟!你可以理解为:做任何事情都需要成本。但我更喜欢另一种说法:凡是选择,必有代价。

 

具体到项目中,不管(注意是不管,无论,随便……)你选择是不是遵循TDD的规范要求,只要你选择了,就必然有代价:

  • 不使用TDD,就会在代码的重构、维护、健壮性等方面付出代价;
  • 使用TDD,就会在测试代码的开发和维护上付出额外的代价。
  • 无论你怎么选,一定是要付出“代价”的。换言之,代码的“低耦合”“可测试”“便于重构”……不可能从天上掉下来,一定是有成本的!

     

    这本来是一个最简单不过的道理。

    然而,当我们迫切的想达到一种目标——尤其是这种目标是美妙的、神圣的、寄托了我们某种强烈情感的时候,我们常常会忘记达成这个目标的成本。

    就个人而言,就是通宵达旦废寝忘食乐此不疲,这是你自个儿的事;但对于团队,对于项目呢?“不计一切代价”就是一种蛮干就是瞎搞,后果往往是灾难性……

    另一个很有意思的现象:我们的舆论,我们的文化,是鼓励“不惜一切代价”是鼓励“克服重重困难”的,这会让我们有一种莫名的冲动、一种热血沸腾的快感。理智和感性天然就是不兼容的?

     

    那么,我是反对TDD的?

    如果你心里还有这样的想法,说明你还是没弄明白我在说什么。

    无所谓支持和反对,没有这样简单化的答案。

    事实上,你需要的,是做一个成本和收益的分析:针对特定的、具体的项目!

     

    没有一个放之四海而皆准的准则。

    不同的项目,有不同的要求,应该因地制宜的采取相应的策略。

     

    这样谈下去还是会很空,我以 一起帮 为例。

     

    1.本站遵循行业规范,任何转载的稿件都会明确标注作者和来源;2.本站的原创文章,请转载时务必注明文章作者和来源,不尊重原创的行为我们将追究责任;3.作者投稿可能会经我们编辑修改或补充。

    相关文章
    • C#开发移动应用系列(4.调用系统应用,以及第三方应用(调用与被调用)) - GuZhenYin

      C#开发移动应用系列(4.调用系统应用,以及第三方应用(调用与被调用))

      2017-07-07 09:01

    • html5中cookie介绍,封装以及添加,获取,删除 - Hero^

      html5中cookie介绍,封装以及添加,获取,删除 - Hero^

      2017-06-14 12:00

    • JVM的内存区域划分以及垃圾回收机制详解 - 青玉伏案

      JVM的内存区域划分以及垃圾回收机制详解 - 青玉伏案

      2017-06-04 12:00

    • DIV 行内关联 box-shadow对象盒子阴影以及图片阴影 - yueyang2017

      DIV 行内关联 box-shadow对象盒子阴影以及图片阴影 - yueyang2017

      2017-05-22 10:00

    网友点评
    i