就你这样的，还能做管理？

今年春节，由于疫情的关系，在家里待了比较长的时间，有了更多跟家人聊天的机会。

一天晚上，我姐夫问了我一个他深埋心底很久的问题：

你这性格，怎么还能做管理？我真的很好奇。

我一想，非常合理的问题啊。

从小就内向，怕生人，基本在大学以后才学会比较顺畅地说普通话，社交技能绝对在平均水平以下，这怎么能在管理岗位上生存呢？

仔细想来，时至今日，TDD 教给我的一些东西，仍然可以让我对一部分程序员进行「降维打击」，这大概是我在管理岗位上的一个优势吧。

具体是什么东西呢？我先分享我 10 年前做 Tech Lead 时的一段经历。

作为 Tech Lead 的一年

目标：推广 TDD

那年，我的前老板 Jacky 管理的其中一个团队，走了一个资深的 Tech Lead，剩下的程序员都比较年轻，所以把我招回去，帮助一下这个年轻的团队。

我那时自认为对 TDD 和 SCRUM 均已有小成，所以我回去后的其中一个目标很明确：推广 TDD。

很有意思的事，接下来的一年，我做了很多事情，唯独没有推广成 TDD 。

以身作则：激发好奇心

很快我就发现，这是一群自信心十足，朝气蓬勃的年轻人。其中的几个佼佼者，甚至对我这个空降的技术主管有些若隐若现的抵触情绪。

所以，我不可能上来就 TDD 了，我要做的第一件事是让他们认可我。

我的方法很简单，照搬从 Daniel Teng 身上学到的：每周从我读过的博客文章中选出 5 - 10 篇，以「每周链接」的形式分享给团队。

重要的不是那些文章本身，我甚至没有期待他们会去阅读；

重要的是我做出了表率：每周挑出几篇来分享，我读的至少要几十篇。这种表率对建立学习氛围是不可或缺的。

记得我当时分享的博客文章，关键词涉及到： Lean， NoSQL，DDD，TDD，Pair Programming， SOLID 等等。很多都是这个年轻的团队没有听过的概念。我相信持续了几周后，团队的好奇心被激发了。

好奇心是一个好的开始。

代码静态检查：一面镜子

团队当时的代码，就如同现实中大家在任何团队大概率可以看到的代码一样：有点烂。

可是如果团队没觉得它有多烂呢？

记得当时一位同事跟我说过：他们几年前的代码是比较差，但是现在新写的模块，采用了新的架构，代码质量已经不错了，言下之意颇为自得的样子。

注：所谓新的架构，其实还是贫血模型，Domain 层啥也不干，直接调用数据访问层，然后所有业务逻辑都写在 SP 里。

我能说什么呢？说什么都没用的。

我做的事情是，给了团队一面镜子：代码分析工具 （NDepend），这是一款 .NET 下检查各种代码指标的工具，比如圈复杂度，包的稳定性和依赖性，类和方法的代码行数统计等等。

我用它分析了一下团队新模块的代码，告诉他们圈复杂度有点高，类有点大；同时在那周的「每周分享」里，着重分享了 SOLID 原则，以及「单元测试」的几个原则（比如：它不能连数据库）。

来自 TDD 的召唤：以终为始

我当时的思路很清晰，把 TDD 作为突破口，但是心里根本没有把 TDD 当作目的。

我只是想通过 TDD 来拉动一些实践：

• 要做 TDD，就得有 OOP 的能力，就要掌握 SOLID 原则；
• 因为 TDD 需要从 Domain 层入手，就要求 Domain 层 对数据库访问层有解耦，这就拉动对架构的重构。
• 有了单元测试，就希望它经常被执行，这就拉动了对 CI 的需求。
• 而 CI， 则会拉动 SCRUM 团队的版本控制工具，和代码分支策略的演进。

而最重要的，就是拉动代码的可测性。

代码道场：实干兴邦

如果一个号称敏捷的团队，却没有任何类似「代码道场」的实践，那一定是在耍流氓。

那一年我印象最深的就是一周一次的代码道场。

我们从代码库里挑出比较有重构价值的代码，然后大家一起重构。

刚开始是他们看我重构。我边重构边讲，背后的原则是什么，为什么要这么做，等等。

有些对我来说显而易见的东西，他们也会来挑战，提出其它的想法。所谓教学相长，就是这样。

后来就采用轮流重构的方式，每次上来两个人坐到电脑前，用结对编程的方式进行重构，其它人观摩，一段时间后有个问答和交流时间。

跟进：事事有回音

每次做完「代码道场」，我都会把过程中记录的那些「为什么」做成思维导图，发给大家。便于大家复习和在现实中运用。

在道场上提及的那些代码原则，重构原则，面向对象的原则，如果只发生在道场内，回到现实写代码时都忘记了或者不再遵守，那这种「代码道场」就不再有意义。

团队会感觉到「现实」和「理想」的反差，这是任何敏捷实践深入的一大障碍，因为他们会觉得这些东西「不现实」，一旦有了这种想法，团队的热情就慢慢消退。

没了热情，就啥也没了。

观点：清谈不误国

除了「代码道场」，我还花了很多时间跟团队「清谈」观点。

比如我鼓励「道术双休」。那时候有一股风气，不管是工作中还是面试过程中，都喜欢聊点「设计模式」，可能对于工作五年以内的程序员来说，这个话题有利于拔高自己的水准。

我告诉团队「设计模式」仍然属于「术」的范畴，而 SOLID，DRY 等原则，更接近于「道」。这样他们至少意识到了「生搬硬套设计模式」的观念错误。

再比如，我解释了「软件」与「建筑」的隐喻。

这个是经久不衰的话题，直到现在，一茬一茬的程序员仍然会认为，如果把「软件」和「建筑」作类比，则「程序员」就对应着「建筑工人」，这种类比造就了一批一批的码农。

而实际上呢？「程序员」对应的是「设计师」；「建筑工人」按照「设计师」的设计图纸施工，建造出高楼大厦，那么，谁把「程序员」的代码施工生产「软件」？是编译器！

这样的隐喻下，人们就可以体会到程序员的幸福：建筑工人施工的成本是很大的，基本上不能把施工了一半的建筑推倒重来；而编译器的施工成本及其小，把代码变成软件的成本几乎为 0 ，所以我们要利用这个特点，不断对代码进行重构。

又比如，我说明了为什么有些程序员的产出为负数。 首先，代码是一种成本。程序员交付了功能 A，它带来的成本包括：

• code review 的时间
• 后续维护时读代码的时间
• QA 测试的时间
• 如果有生产环境的 bug，它引起的团队的定位问题，沟通，修复，和重新发布的时间。
• 等等……

想象一下，假设「程序员甲」开发功能 A 后带来的成本是 10 天；而如果他什么也不做，交由「程序员乙」去开发，开发时间为 2 天，带来的成本为 3 天。则「程序员甲」能对团队做的最大贡献，就是什么都不要做。

这时候我们说「程序员甲」的产出为负数。

又又比如，我分享了架构和设计的关系。 我发现，很多初级程序员不敢去想什么 Domain Model 之类的事情，认为那是「架构师」的事情。

那么，到底什么是架构？

程序员在设计一个类的时候，是不是在做架构？不是。那么架构师在设计大粒度的东西时，就是在做架构，为什么？

Bob 大叔说过一句话：架构无非是设计中不可逆的部分。一切都是设计，只是有些设计的可逆性很弱。

这样一想，代码就是设计，架构就是可逆性差的设计，那么，哪有什么不写代码的架构师？

不结对不舒服斯基

回到代码。

在无数次的「代码道场」中，我悟到一个道理：一个程序员写不好代码，是因为他不会写代码。（废话！）

我的意思是：一个人写的代码不行，是因为他写代码的过程就不行。反过来说：如果不改变一个人写代码的方式，他写出来的代码不会有什么改变。

在那之后，我沉迷了很久的「结对编程」。如果你看到我在座位上如坐针毡，一定是我在等人跟我结对编程。

因为我觉得，我不把我写代码的过程展现给你看，不把我的思考方式，我的重构手法，我的代码提交，我的快捷键的使用，让另一个程序员知道，就太可惜了！

我是这么管理的

以上的经历来自于 2010 年，更详细的，我写进了《敏捷开发一千零一夜》这本书的第十一章。

回头想，这段经历的成功，对我的影响是巨大的。多成功？举一个例子：当时团队一个小伙伴，拿到了外面薪资 double 的一个 offer，他跟我商量后，决定不去，其中一个理由是：留下来可以学到很多东西。

它塑造了我基本的管理风格。

Lead by Example

时至今日，我很少要求团队去做一个我自己没做到的事情。我期待团队是学习型的组织，那么我自己得先这么做。

写公众号也是，我提醒自己，不要写自己没做过的事情，不要把书上看到的东西翻译一下就变成一篇文章。我不贩卖知识，我分享经验。

以终为始

眼高手低是 Leadership 的重要素质。眼睛要看得远，事情却要一步步地做。

就像我把 TDD 看成一个终极目标，它的召唤，拉动着团队一步步地前进，哪怕一年内也没成功推广 TDD，可是团队的进步是日新月异的。

比如把 TFS 改成了 Subversion （那时候 GIT 刚出来，还没有好用的免费服务器），重构了架构，编写了一键编译的脚本，引入了持续集成的实践，等等成就，囿于篇幅（意思是懒得写了）都没有写。

这都是来自于 TDD 的拉动。

洞察力和观点

在一个行业呆久了，必须形成对这个行业的洞察力，对这个行业有自己很清晰的观点。

没有观点，那跟咸鱼有什么区别？

现场管理和过程质量

假设一个砌墙师傅，带着几个徒弟，可是他从来不去看徒弟的墙砌得怎样，你觉得如何？

软件行业还真有不少这样的经理：带着一帮程序员，可是从来不去看程序员的代码。怪哉。

所谓现场，不仅仅指程序员的工位，也包括程序员的 IDE，他们敲代码的习惯，以及他们敲的代码，这一切都是现场。

而质量呢？大家都在吐槽软件的质量，代码的质量，可是鲜有能把质量抓上一个台阶的。可能的一个原因就是没几个经理是懂得质量的：程序员写代码的习惯，才是决定代码质量进而软件的一个根本要素。

结尾

回忆起我姐夫问我那个问题的那个瞬间，我先是感同身受，心头也闪过对自己的一丝怀疑，然后是一丝庆幸（庆幸把我提成管理岗的前老板）。

而如今我回忆了一段十年前的经历，我想我可以大声回答他：我可能不是最适合做管理的。

可是，我会 TDD 啊。