点击上方“中兴开发者社区”,关注我们
每天读一篇一线开发者原创好文
作者简介
作者张均,中研院认证敏捷技术教练。代码匠艺精神的推广者和实践者。致力于TDD、重构、DDD、TLA+和DSL等实践的落地。这篇文章主要回忆了在实际项目中如何运用TDD进行实践的一个历程,和总结了对技能提升的僵化优化固化过程,欢迎大家拍砖交流。
管理进步讲究“僵化、优化、固化”三步曲,能力提升包含“学习、思考、分享”三层次。
僵化式学习,优化式创新,固化式提升,进一步学习,个人能力扩展的一种框架。
僵化式学习:了解框架流程
人的思维和行为容易固化,学敏捷,学TDD等,容易产生抵触情绪。“如何学”就成为一个重要问题。僵化就是学习初期阶段的“削足适履”。是一种学习方式。先僵化,说起来容易做起来难,削足适履肯定是个痛苦的过程。变则痛,但世界上唯一不变的事情就是变化。学习TDD时,一定要重复的“红灯-绿灯-重构”,抵制诱惑,快速实现。不经过多次僵化练习,是很难感受到TDD内涵、放弃抵触情绪的。
个人学习:
熟悉《整洁代码》、《重构》、《敏捷软件开发:原则模式实践》,并有一定见解。
坚持参与外部代码静修活动和TDD讨论群,找到志同道合的小伙伴,拉其一起入群讨论,参加外部代码静修,多向业界TDD实践者进行学习。
社群学习:
1、开展团队内每周一晚上1题练习活动,采用TDD方式完成Code Chef练习题;
2、代码COP活动;
3、新员工培养:整洁代码、编码规范、重构和TDD的系列代码道场活动。
通过僵化式学习,对TDD有一定的理解,单元测试和场景拆分的技能有一定提升。
优化式创新:融入工作
优化就是改进,优化就是创新。优化的目的是使知识变得更高效更适用。僵化而不优化一定会僵死。“TDD很好,但是不实用”,听得最多的这句话,是错误的。TDD是流程或框架,在使用时需要借助方法和工具,比如:实践结对编程,以点带面,形成氛围;善用TDD的驱动设计,容易忽略的重构加强,改善设计;对存量代码补充UT时,以业务场景驱动而不是代码驱动,黑盒测试。
TDD与结对开发:
为了解决软件项目开发团队人员技能参差不齐和重交付轻质量思维,团队内部可设置代码专家守护团队代码,每日代码走查活动中,针对逻辑修改和新增,关注UT覆盖率和代码圈复杂度目标。对人员能力的提升,就需要代码专家和开发人员对走查提出的问题进行结对修复。代码专家引导开发进行UT用例补充和技巧传授。
收益:通过该实践,开发人员实际写单元测试的意识获得提升。
TDD与业务梳理和故障定位:
对代码流程中一个超过1000行的复杂方法,涉及多个业务分支,如何梳理代码进行故障清理?我们选择了TDD,从外部流程上看走该部分代码的所有可能场景,对每个场景,我们需要的结果是怎样的,挨个场景补充单元测试,尽可能完成场景覆盖后,再去发现和修改对应故障。
收益:除解决问题,还发现很多潜在的问题;同时由于有完整UT场景的保证,通过驯服烂代码活动(工作之外大家对这块烂代码集体重构活动),额外收获做到了业务知识的传递。
TDD与复杂场景需求:
对接口的稳定性和异常处理要求很高的项目,针对AC开发需求时,TDD开发就为场景细化提供了保障,对需求代码要求严格的UT分支覆盖完全,需求开发过程中不断的TDD三部曲无疑解决了找不到集成环境自测的问题。
收益:除单元测试覆盖和代码健壮性提升,减少了QA的手工验证工作量。
固化式提升:能力提升
将僵化阶段优化阶段的成果心得,进行固化。固化的目的是为了总结分享,以便别人或者自己进一步学习。固化的方式有多种,比如总结文档,最佳实践,模板化等。 这里的模板化举个例子,比如存量代码单元测试的依赖隔离使用mock,可将使用到所有mock技术的一个实例模板化,那么对新人就不必再去摸索,如果完成这个模板,就可认为mock的技能达到初级阶段。固化也是简化。
上述实践,不断总结回顾,反馈和调整。最终人员形成如下意识:
走查代码的习惯发生了变化:对代码评审活动,习惯关注测试代码的业务场景描述。达到知识分享和消除每日代码走查的疲劳的目的。
解决故障的思路发生了变化:不在因为为了解决故障而改代码,而是更多得梳理代码,发现故障周边的场景;解决故障不引入新故障不再是底线,而是解决一个故障规避一堆故障。
对特性和场景拆分站得更高:我们的AC变得更细,我们的场景变更更全,这都依赖于澄清会和计划会上小伙伴们都能提出更多的场景来。
结语
TDD的争议性,项目的导向性,个人能力限制,导致普遍软件从业者认为对TDD落地很疑惑。
关于“TDD如何落地?”,关键在于我们面临的具体问题,我们想要用TDD框架来怎么解决。也许有人会问你实践的TDD不是TDD,但那又怎样?解决了我们的问题或者提升了我们的技能,就够了。