查看: 79|回复: 0

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

[复制链接]

该用户从未签到

发表于 2019-11-4 06:30:09 | 显示全部楼层 |阅读模式
想在园子里写点东西已经好久了,但一直没有落笔,忙着做 一起帮 的开发直播,尚有些软文做推广,还要做奶爸带孩子,还要……好吧,我承认,真正的原因是:
太特么的难写了

但再难写也要写啊,要等到“能写好了再写”,怕是黄花菜都凉了——尤其是技术类文章,时效性非常强的。
刚好坛子里这篇博客:关于拒绝测试驱动开发(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的机会实在是非常渺茫的,就我目前能想到的:

  • 开发团队,尤其是架构师必须有相当的水平。我在架构之路(三) 单元测试就讲过:单元测试不是那么好写的!凡是可(易于)测试的代码,一定是“低耦合”的,模块之间是具有相当大的“独立性”的,不然相互牵连,将非常难以测试。而随着业务逻辑的耦合度(复杂度)越来越高,解耦的难度也就越来越高。反正据我的观察,一般的开发团队根本hold不住。偶然候想想,非常之诡异:耦合度不高的项目,实在又没有多大的必要做TDD?
  • 项目负责人对项目可以或许长期存活具有强大的信心。TDD的实践,是前期投资,后期劳绩。相当长一段时间,你都会觉得写单元测试非常无聊,只有到了后期,业务逻辑越来越复杂,到处都是千丝万缕的联系,牵一发而动满身,经常一改动单元测试就跑不外的时候,你才会觉得“咦?这玩意还真的有效呢!”但是,注意这个但是,项目负责人有没有足够的信心:这个项目能撑到谁人时候?!市场朝三暮四变革无常,险些所有人都是走一步看一步,摸着石头过河,哪里能顾得那么长远?
  • 项目从一开始就不赶工期,允许使用大量(至少是双倍)的时间来写单元测试。就算是我有信心这个项目没问题,但时间允许不允许?商场上争的就是一个先手,快鱼吃慢鱼,要快,要抢先占领阵地。这就和强行军一样,确实有很多问题,不如步步为营稳妥,没有重武器,会有掉队减员,队伍非常虚弱……但只要先到达阵地,其他一切都在所不惜。
所以,我非常好奇,究竟有多少童鞋真正参与过一个严格按TDD模式实施项目?

那么,TDD是不是就不值得学习了呢?
当然不是的!

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

真的顶不住了!
12点了,超级 =_=
展开写尚有很长很长,强写脑力也跟不上了。先如许吧,偶然间我们下次再聊,晚安,各位。


呵呵,偶然中发现的,小小的一个成绩,纪念一下。

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有帐号?用户注册

x

相关技术服务需求,请联系管理员和客服QQ:2753533861或QQ:619920289
您需要登录后才可以回帖 登录 | 用户注册

本版积分规则

帖子推荐:
客服咨询

QQ:2753533861

服务时间 9:00-22:00

快速回复 返回顶部 返回列表