最新公告
  • 欢迎您光临起源地模板网,本站秉承服务宗旨 履行“站长”责任,销售只是起点 服务永无止境!立即加入钻石VIP
  • 参与 Element3 开源项目,使用 TDD 的一些感受

    正文概述 掘金(花果山技术团队)   2021-02-20   409

    本文是element3 的contributor之一,在体验了element3的tdd组件化开发流程后的感想

    本文作者:世风十三

    参与 Element3 开源项目,使用 TDD 的一些感受

    TDD的困惑

    很多项目团队并没有使用 TDD (测试驱动开发)的开发方式,我想这在目前的开发团队中占比非常高,特别是中小型公司的前端开发团队,几乎可以说是“全军覆没”,为什么?原因可能是以下所列的一些:

    • TDD 太麻烦,增加了工作量
    • TDD 太复杂,普通程序员掌握不了
    • TDD 并不是必须的,不必要投入这些时间成本
    • TDD 是个太理想的方式,还是要面对现实
    • TDD 很好,可是我们公司实力弱,招不起那么专业的开发人员啊

    我想这里面有一些可能的原因:

    • 对 TDD 的理解可能还不够深刻
    • 没有给团队一定的空间和时间去尝试和体会
    • 眼光看得不够远,只关注眼下项目的结果
    • 没有真正体会过 TDD 的好处和收益

    TDD的思考

    还有一个极限编程群里的说法是:

    总的来说,这个 TDD (测试驱动开发)就跟很多体验性的能力一样,不亲身体验,不深入体验,不会有深刻的感受,正应了现在流行的“真香”定律,总是要用过了,体会过了,才会说好用的。

    就好比,有人跟我们说,健身很快乐、很上瘾,收益非常大,而我们却没办法体会,也明知这个道理,也不能实践。然后呢?总是有一堆理由和借口来给别人,也给自己开脱。

    • 健身 太麻烦,太累,每天上班工作已经很累了
    • 健身 太难了(要办健身卡,请健身教练),一般人没条件
    • 健身 也不是第一要务,暂时没那么多时间去投入
    • 健身 的生活方式是理想的方式,目前的现况还是要面对的
    • 健身 很好,可是家里的现状不允许啊

    当然,健身还只是一个个人的事情,而 TDD 则是一个团队和一个公司的事情,有时候可能最终能推动会显得更困难。当然,也可以从自身做起,逐渐带动周围的人慢慢加入,这需要一个过程。

    然而这个情况在开源社区中,可能就相对好些。一方面参与开源项目的开发人员通常都是出于对技术的追求,更愿意采用先进的编程思想和理念,市场和业务的压力相对宽松,通常掌控开源项目的社区领袖都是技术方面的高手,能够正确地看待一些技术实践对质量的重要影响,所以整个开源项目的开发过程可能更加科学、合理和有序,尽管参与开源项目的人员分散在全世界的各个地方,却并不影响他们产出高质量的软件和成果。

    Element3里的TDD

    最近参与了开源项目 Element3 的组件开发,整个项目从立项之初,就确立了使用 TDD 测试驱动开发的原则和规范,因此参与的人员要么已经熟悉 TDD 的开发方式,要么是想学习和深入理解 TDD、Vue3 和 ElementUI 的学习者,因此在心态和意愿上具备了良好的基础,团队成员至少是不存在对于 TDD 开发方式的抵触和抗拒问题的。

    在此过程中,我个人也进一步对 TDD 的开发方式体会更深了一些,下面聊一些我个人的感受:

    其实很多时候,我并不想聊具体的技术,我觉得比技术更能改变自身的是心态,具体的技术资料,网上难道还不够多吗?现如今这个时代,怕是穷尽一生也学不完。说回到 TDD 这个开发方式,多数人都是有一知半解的,我自己可能多年以前就知道测试驱动开发是什么意思了,然而也就是近一两年才开始真正入门实践,为什么呢? 自己反思了一下,一个主要原因可能是缺乏见识,不知道这个 TDD 原来是这么好的开发方式,自己也没有深入思考过相关的问题,套用最近我看到的一个文体:

    Progress组件

    我个人目前只重构了一个组件: Progress,两个星期才重构完了一个 Progress 的组件,注意:仅仅是重构/重写,这期间的前提还是需求明确、实现方案已经现成的情况下,我再次重写,只是需要用测试驱动开发,保证代码质量,原来的具体实现方式已经是经过使用验证的,可以大量参考的,这中间减少了大量的沟通需求的时间,研究实现方案的时间等等,我猜如果要完全凭空实现的话,给我一个月时间还不知道能不能达到现在的效果。

    “就这?”也许你会调侃一下我的开发效率了,我也自知是个能力一般、资质平庸的程序员,这很正常,但也很真实,我们最好还是承认我们自己是平凡的大多数,使用 TDD 后一个很大的好处是,即便是平庸如我这样的程序员,也可以写出拍着胸脯有自信的代码了,一种真正的脚踏实地的感觉,软件行业流行着一种观念是说:哪儿有软件没 Bug 的?有 Bug 很正常嘛!的确软件的复杂性,决定了软件出 Bug 的高机率,可是这样的观念和说法,却无行中助长了很多软件代码的粗制滥造,只求快速实现功能,不管未来的可维护性、可扩展性等等。

    我这样的开发速度也许在一些“追求结果”、“唯快不破”的公司项目中是不能接受的,然而,这才是高质量软件的真实开发进度,前些天在极限编程群里有编程能力很强的朋友统计了自己一星期“无异味”(Sonar 扫描没有坏味道,即代码可读性很好)高质量的代码产出量,也不过是每天两三百行而已,放在一般的程序员能力来说,可能也就一天一百行左右吧,一百行代码能做什么呢?可能离很多公司领导心目中那种高速的期望非常远:“我这儿有个想法/需求,下周一能出个 Demo 吗?这个月最好能上线发布”。 这种速度倒也不是说不能实现,只是需要前期有相应的准备和积累,编程开发这件事,其实就是这样,积累得越雄厚,应变的能力才能越强,打造一支这样的开发团队,一种企业文化,一批批高素质的软件开发人才,自然能够做到“唯快不破”高效交付。

    这就好像我们做的这个 Element3 组件库,或者其他的各种前端UI组件库,使用它的人可以非常快速高效地搭建出一个业务需要的界面,在一些中小公司手快的程序员一天做三个、五个增删改查的界面效果都是有可能的,然而公司领导或行外人士怎么会想到,其中的一个小组件居然要这么长时间开发?各种后端的开发框架和其他技术要素也是同样的道理,没有相应的积累,就没有高效的交付能力。

    TDD的好处

    下面结合这次开源组件重构说一些我所体会到的 TDD 的益处:

    TDD 可以帮助我们理清需求和思路,因为上手要先写测试,那么要测试什么呢?这时就会先把最终要的结果分析清楚,然后拆分成可实现的小任务,从简入繁,先写出相应的单元测试,再推导出相应的代码实现,测试通过后,再写下一个单元测试,再倒推出业务代码实现,如此往复,这就是我们说的 TDD 的开发节奏。在这个重构 Element3 项目的 GitHub 仓库 Issues 列表中就可以看到参与项目的成员相应的任务拆解过程,一个组件的重构,都好几十个任务和子任务,整个过程冷静、耐心、严谨,一步一步,看着慢,其实很高效。 实际上越是复杂的组件,越是获益良多。

    TDD 可以帮助我们更有信心地进行重构,真正的重构不只是在原来的代码上改就完了,《重构》这本书出了两版了,第一版是以 Java 语言为例写的,第二版是以 JavaScript 语言为例再版的,其中对重构有着明确的定义:在不改变"软件之可察行为"前提下,调整其结构和代码,关键字是如何确保不改变可察行为呢?根据很多编程大师多年的编程经验来看,只有100%全面覆盖的自动化单元测试才能确保。而要达到100%全面覆盖的自动化单元测试,最好的方法就是一开始就从写单元测试入手,测试驱动着写出相应的业务实现代码,这样整个过程下来自然而然就达到了100%的单元测试覆盖了,即使部分代码不需要测试,达到 90%以上也是非常轻松的事情,有了这样的保障,我们才能大胆地尝试新的想法,不抗拒变化,高质量高效率地持续交付。

    按上面这个重构的定义来衡量,大多数我们平常项目中看到的直接修改实现代码的行为,在权限编程群里有个说法叫:“瞎搞”,体验过 TDD 的同学都明白,确实如此,回想起自己当年的“大刀阔斧”,不禁汗颜,确实是瞎搞。瞎搞带来的危害大家自然也能想到,频繁的 Bug 修复,不稳定的软件质量等,自然就会导致团队成员对任何的修改都心生抗拒,对于业务的需求和变化心生畏惧,对于源代码日渐陌生,即使非常小的改进也没有信心快速完成,每一次的更改和发布都需要大量的人力辅助测试、回归测试等,后续的成本耗费其实非常巨大、不可估算。

    还有些时候不是需求变了,而是自己的想法变了,最初的实现可能考虑得不周到,可能采用的实现不理想,现在想用更好的方式改写,这时就需要有一个可以保障的安全网,这时 TDD 所构建出来的全面覆盖的单元测试又会发挥极大的价值,

    还有就是发现 Bug 的时候,TDD 所构建的单元测试也可以帮助我们快速、准确地定位问题,如果现有的测试都可以正常通过,对照相应的测试和 Bug 产生可能的原因来分析,很快就能有解决的思路,通过补充针对相应 Bug 场景的单元测试,可能很快就能在本地快速重现出问题,相应地解决也将非常快速而准确。

    就在这两三周的重构过程中,项目涉及了更改目录结构、转换到 TypeScript 语言等重大变化,这在一些公司里的项目可能是非常可怕的决策,然而因为有单元测试的保障,团队成员坚持使用 TDD 来进行开发,都非常有序而平滑地完成了这些变动。 在可预见的未来,有这样良好基础的项目,后劲会非常强大,如同飞轮效应,如同滚雪球效应,可以越来越高效地交付价值,满足用户的需求和变化。

    最后,希望此文能引起你对 TDD 的一些兴趣和信心,实际体验一下,寻找一个采用 TDD 的团体,参与其中,真正跨过这个程序员的“分水岭”,是的,没错,在我现在的概念里,程序员可以分成两种,一种是会 TDD 的,一种是不会 TDD 的,这几乎成为了一道“分水岭”。不论语言、框架或者业务方向,都是如此,当你领略了 TDD 的威力后,你会发现,用这样的编程方式,各种编程语言可能都不再是界限,用这样的手法,一种类似工匠精神的手法,用什么语言编程都可以写出质量很高的软件代码,由慢到快,“天下武功,唯快不破” 就只是刻意练习的时间问题……

    其他

    大家可以关注Element3和花果山团队我们会持续更新最棒的内容。 也欢迎star和pr


    起源地下载网 » 参与 Element3 开源项目,使用 TDD 的一些感受

    常见问题FAQ

    免费下载或者VIP会员专享资源能否直接商用?
    本站所有资源版权均属于原作者所有,这里所提供资源均只能用于参考学习用,请勿直接商用。若由于商用引起版权纠纷,一切责任均由使用者承担。更多说明请参考 VIP介绍。
    提示下载完但解压或打开不了?
    最常见的情况是下载不完整: 可对比下载完压缩包的与网盘上的容量,若小于网盘提示的容量则是这个原因。这是浏览器下载的bug,建议用百度网盘软件或迅雷下载。若排除这种情况,可在对应资源底部留言,或 联络我们.。
    找不到素材资源介绍文章里的示例图片?
    对于PPT,KEY,Mockups,APP,网页模版等类型的素材,文章内用于介绍的图片通常并不包含在对应可供下载素材包内。这些相关商业图片需另外购买,且本站不负责(也没有办法)找到出处。 同样地一些字体文件也是这种情况,但部分素材会在素材包内有一份字体下载链接清单。
    模板不会安装或需要功能定制以及二次开发?
    请QQ联系我们

    发表评论

    还没有评论,快来抢沙发吧!

    如需帝国cms功能定制以及二次开发请联系我们

    联系作者

    请选择支付方式

    ×
    迅虎支付宝
    迅虎微信
    支付宝当面付
    余额支付
    ×
    微信扫码支付 0 元