结束语 | 对代码的信心要从测试里来

我已为老师想好下一个专栏的名称《TDD项目实战》，很多人一提到TDD第一感觉就是听过、没见过。耗子叔早年写过《TDD并不是看上去的那么美》https://coolshell.cn/articles/3649.html，我对TDD还是很感兴趣的，一直自己摸索感觉还是不得其法。老师在极客时间的其实为TDD做了不少铺垫，是时候综合运用一下来一个中型的实践项目，把ThoughtWorks的TDD实战经验在实际项目中展示一下。 以下是我自我摸索出的想要玩转TDD需要的能力/技能： 1. 需求分解 《10X程序员工作法》 -- 解决测试用例从哪里来的问题？ 2. 设计能力 《软件设计之美》 -- 设计/抽象/建模让产品代码更具可测试性，同时完成第一创造 3. 测试能力 《程序员的测试课》 --- 扬长避短，写出好的测试代码，别让测试成为负资产 4. 编程能力 --- 熟练掌握所用语言的核心语法、常用标准库、第三方库等（含数据结构与算法），能写出符合该语言规范的代码，判断标准：在TDD循环中尽量不卡壳、少用Google减少打断循环的次数。 5. 转换能力 -- TDD循环是在两个思维层次来回跳转，写测试时抽象需求What，写代码时具体细节How 6. 重构能力 《代码之丑》 -- 识别坏味道，运用恰当重构手法提高代码质量 7. 工具能力 -- 熟练操作Git、IDE、及其他自动化工具，使其能跟上TDD的节奏 （比如，编写测试时，产品代码还没实现但写出其接口后可以利用IDE快捷键自动生成产品代码的框架。重构时，运用IDE提供的重构快捷键，快速修改名称、抽取方法、内联函数等。完成几次TDD循环后可以用Git提交，设置“游戏存档”随时重新开始，如果一切顺利合并多个提交为一个然后提交） 最后就是各种场景实战，小型场景练习并熟练上述技能，中型场景强化上述技能的同时，培养在工期压力下完成任务的能力，大型场景就是在实际工作中实践。 我没把TDD当银弹，希望能达到“对于同一个业务功能，大多数人用X天完成产品代码然后提测，我同样用X天完成产品代码和测试代码然后提测”的标准就可以了。希望这种工作方式能给我带来更多自信（对代码也对自己）。谢谢！

🤔☕️🤔☕️🤔 我个人写代码近20年 不肯写测试，第一原因是无知，以为写出代码就可以，第二原因是懒惰，因为无知和自大，发现既然配置了测试，那就毫无顾忌把测试抛出去，代价就是数年下来楞是把自己逼成一个修简单问题引起的难查问题的加班狗 最根本的原因，还是自己缺乏追求，对自己所从事的事业的热爱感 上述就是我自己的经历，在最近5年我越来越清楚自己的问题，也越来越努力去克服自己的问题，寻找意义感和热爱点，只有自己能点亮自性之光

郑老师的专栏文章语言很质朴，优秀的专栏读来酣畅淋漓，受益很多，接下来就该要自己多刻意练习了，加油！郑老师 再见👋🏻

“不愿意相信”，说到重点了，相信就意味着要做出改变，对自己下手是需要很大勇气的。 在一个进度优先的氛围下，完成功能，成绩是显而易见的。软件质量如果没有一个量化的指标，做的多也未必能被看到个认可

期待郑大新专栏哈哈哈哈

关注公众号又可以拉进与老师的距离了

感谢老师，我个人觉得结束语比之前章节写的好，更深入人心。无知之错，无能之错，受教了

老师能出一个讲透权限设计的课程吗？

四门课程终于学完了。听着郑老师侃侃而谈，不胜感慨，TWer出来的程序员就是能说啊。从量，这个角度来看，这门课无疑是最少的；而从实际收获（有点唯心），又无疑是最满的。P.S. 一路跟下来的学生，能不能给点附加优惠，比如郑老师的联系方式啥的。

无知之错和无能之错这个分类太真实了，不过很多时候，我们没法分清自己是无知还是无能，比如老师举例说的程序员对于质量内建的理解。 内建质量的意义我理解大家都知道，但现实情况是，很多开发被进度逼着往前走，恨不得每写完一个函数就提测给测试，以表示自己「提测」了，根本顾不上自测（作为一个测试，还在给开发找借口，感觉有点别扭），久而久之，就懈怠了。 我也想过从测试侧通过流程，强制要求自测，不过这样就变成解决「无能之错」了，所以还是要让团队都意识到内建质量的重要性，特别是让项目负责人接受，通过解决「无知之错」来促成这件事。