星云前面的文章提到过TL在团队中是一个既要懂技术又要会领导的角色或者可以称之为研发团队的“CTO”。他有在团队中推广和落地技术实践活动的责任，前提是TL对这些技术实践有足够的了解与掌握，所以在TL的能力模型中通常都会指定不少的具体技术以及方法。

在这些技术与方法中有三项非常经典的团队技术实践，即TDD、CleanCode和重构，这次我们就从它们说开去，探讨一下TL如何在团队把这三项技术实践演绎好。

效果尴尬

在不少团队中，TDD、CleanCode和重构这三项技术实践的落地情况有些尴尬，总结起来就是既容易做又不容易做。说容易做是因为它们可以无缝地融合到日常的研发过程中无需“节外生枝”，甚至还有非常棒的流程或工具来帮助团队落地实践，比如说CleanCode，流程上“代码走查”基本上是研发标配而工具上又有各种checkstyle内嵌到代码提交过程，这样说来效果应该杠杠的，那怎么又说不容易做呢？这是因为团队这个对象很复杂。

TL在进行上面三项实践的时候会遇上不同的对象群体，有初出茅庐的新员工，他们中不少人没怎么写过代码（大概率的，上一次频繁地写代码是招聘之前突击训练），空白的甚至连烂代码也没写过，所以不管你怎么苦口婆心他们也未必能体会代码好与坏之间的差别；还有浸淫工作超过5年的“资深”，他们写代码早已自成体系，除非你能够真正触动他们，否则你的建议很有可能只是“清风徐来，水波不兴”；最让人头痛是那些迈过了菜鸟门槛仍在不断成长团队“中坚”，他们有实际经验所以能很迅速地领悟你的建议，但又能在自我的超高速飙车中迅速地“翻车”，所以有时候你不得不花点时间盯着他们，防止他们又走回老路。

因此向TL们提问“你们那儿技术实践做的怎么”，私底下十有八九会得到“这些东西不太好搞”的答复。这是现实，是不能脱离团队复杂性的现实，也意味着TL在技术实践落地时首先要关注目标群体，即究竟是谁要成为技术实践的受益者。如果真打算全团队受益那么也要分清主次；其次才是该采用什么样的方式去契合目标群体，无论是编码道场还是游戏教学亦或是结对实践，“因材施教”才是正常操作。

自我认知

除去团队的复杂性会影响技术实践的落地效果外，自我对成为TL这件事的认知也是不少TL需要跨越的山丘，从普通研发人员成为TL并不只是一个头衔的增减而更多的是能力的认可，或者说负有TL之名就当行TL之责。

在成为TL之前，你只需要管好自己再顺手帮助下别人，所以TDD、CleanCode、重构大多数时候都是对自己而言，只要自己能够理解运用即可；而成为TL后，你就要站在更高的视角去看待以前你做的那些事，比如CleanCode，原来你基本上只需把你自己想要表达的意思用代码清晰地表达出来，然后努力减少重复进行适当地重构，但现在你得从架构和领域的角度去认真思考这个问题了，这时你会发现原来你写的东西放在架构和领域中并不合适，可能是使用领域外的概念增加了沟通成本，或者是原先的代码并不差但在架构演进过程中逐渐变得冗余和重复而成为腐化的起源。更关键的是，之前自己看这些东西总会暗示自己“问题不大，我待会儿来调整”（实际上待会儿可能会过去很长时间，直到有一天其他人找到你向你咨询你这段代码的含义），现在这种心理暗示更多的是提示你“看，这里又有个问题，快点搞定它！”

TL还需帮助团队成员去完成技术实践，你可以被动地提供帮助但更应该主动地提供服务，TL需要将这种对自己实践活动的审视逐渐转移到对团队其他成员的关注上。这话听上去简单做起来可不容易，团队成员会提出一些很不错的重构想法，比如有人发现代码中有大量形式相同的类就提出采用模板来简化这种重复劳动，但可能担心想法不成熟而只是在自己的代码中尝试。当TL看到这样的尝试就应当帮助尝试者将实践夯实、改进并推广，不单是在团队内更需要推广到团队外。这是个真实的例子而且实际的情况还与上面的情景相反，这个不错实践并非来自团队内部而是外团队成员的（外团队也还没落地），在被其他团队的TL发现后引入到TL所在团队。所以成为TL后要“站得更高，看得更远”并不是一句空话，而是确实要拓展自己的接触面，不然马上就有人抱怨“我自己的活还没完，管人家那么多闲事，不是吃饱了撑的”。

知其然知其所以然

技术实践之所以被称之为技术实践是因为它被业界证实有效并能够在一般团队开展的，它能解决实际工作中的问题，对这一点大部分团队了解得少了或者还不深入。回想之前实践TDD、CleanCode及重构的过程，所有人都特别喜欢关注要做什么（What）怎么做（How）或者关注步骤流程却不太关注这么做的原因（Why）或者一带而过，没法让使用者对问题在自我身上产生相同的投射或代入感只能大大降低了使用者对实践有效性的心理预期，让人提不起兴趣。

why-how-what

我在CleanCode的培训中一直会问大家一个问题“平时写代码时，我们是怎么工作的？”，问这个问题的是希望大家都想象一下自己坐在电脑前的场景：读代码，写几句，然后删掉，再读代码，再写几句，如此循环往复（实际上有录屏工具可以帮助大家去重温），这能让大家思考下我们每天的工作时间是花在哪里从而让大家明白读懂代码是一件很耗时的工作，这也是为何要做CleanCode的原因，生动实际的例子远比冷冰冰的理论要管用。现在一说起CleanCode，我脑中出现的还是屏幕中上上下翻动的光标和写了又删的代码。

TL在推进TDD、CleanCode及重构落地时，一定要说明白做这件事的原因而且不能是泛泛之谈或者纯粹地套用书本理论，最好是用研发人员最容易体会到的好处去解读，比如时间、工作量，如果有可能的话采用实际对比的方式更加直观。

结语

上面啰啰嗦嗦地讲了那么多，实际上总结起来就是几句话：

• 明确实践受益对象，精细化耕作，因材施教
• 转换身份与思维、拓展自我接触面，从更高的视角来看到技术实践过程中的技术问题
• 把技术实践要解决的问题阐述清楚，让问题与受益者产生共鸣，才有机会把技术实践固化

TL是研发团队的持续学习和成长的关键一环，推进TDD、CleanCode及重构只是简单却又重要的开始。