四月的西安，春意盎然。

一个阳光明媚的下午，我们在西安研究所见到了传说中的软件高手：吴世龙。如果在西研提起软件高手，很多人都会提起他，眼前的吴世龙阳光开朗，他却自称自己奇奇怪怪，爱看书——家里塞满了奇奇怪怪的书，比如：哲学游记《禅与摩托车维修艺术》、运维武侠《凤凰项目》、玄幻励志《你当像鸟飞往你的山》等等；爱游泳——小学游小河，初高中游汉江；另外，厨艺尚可——仅限饿不死自己……

加入华为仅仅两年，他就已经成为公司云化先锋产品ManageOne核心成员、SRE CMG成员，拿到了“SRE金代码10强”、西安研究所“软件精英个人”，多次获得“研发部长奖”“SRE云鹰嘉奖令”等等。

带着好奇与崇拜，我们开启了与他的对话。

问：如果用几个词来描述你对代码的态度，你觉得会是什么？

答：作为一个资深的编码发烧友，如果你问我对代码的态度是什么，我会脱口而出两个词：洁癖+强迫症。

其实很多开发人员都有代码洁癖，干净整洁（Clean Code）是最基本的要求，看到不好的代码、技术方案甚至社区帖子，就会忍不住吐槽。提交代码前，要用各种技术手段来验证它们。对满意的代码，我会拉上很多同事来看写得怎么样，可以说“秀”代码是我最大的爱好之一，哈哈！

问：为什么喜欢“秀”代码呢？

答：在我看来，“秀”代码不仅让人很有成就感，还能和更多高手PK，如果大家可以提出一些改进点就更好啦，让我们的代码更优秀嘛。去给别人Review（检视）代码时，我也会问很多很多问题，犀利地去找问题点（哈，洁癖又“犯了”）。当然，我也会非常佩服写得好的。这也许就是很多程序员的习惯吧——享受代码过招的刺激感！

问：那再来说说“强迫症”。

答：而强迫症就更好理解了，我是一个绝对痴迷于最新技术的人，包括：新的库、新的框架、新的技术，我喜欢游走在GitHub、Stack Overflow、开源中国、InfoQ等等的社区里，看解决问题的思路还有方法。写代码时，无论是JAVA还是Python，一定要符合它自身的规范，容不得一些奇奇怪怪的代码，哪怕只是命名不规范，也会直接打回让“作者”改好。

在我看来，一个优秀的程序员最大的体现就是解决问题的能力，解决的问题越复杂，他的能力越高。而“洁癖+强迫症”会让我们持续去追求可信、高质量的代码，我们的产品也才会更有竞争力。

问：还记得你来到公司后，第一个项目是什么吗？

答：2019年5月，我刚刚加入华为，来到了公司云化先锋产品ManageOne团队。当时，为了让众多微服务满足Clean Code诉求，ManageOne决定开发定制门禁系统，代码合入库前必须通过门禁系统的各类规则检查，防范低级错误，让代码更可信、质量更高，这就像我们回家进门前，一定要用钥匙来经过门锁的检验一样，这是我收到的第一个任务。“容器”是门禁系统的必备技术点之一，而刚好我对容器也有比较多的积累，所以还是很有信心的。

前两个星期，我主要在取经和挖需求。我去找了装备部的康哥取经，想搞清楚报告如何更好地呈现；找了公司可信使能部规范组，看如何更好地定义规则；还有部门的软件总工张赛专家等等，他们更关心系统如何使用等等。经过大量的面对面和电话会议，最终汇总成了几十条的规则要求。

接下来，就是逐一来梳理匹配它们的问题了，这其中涉及的就很多了，包括：“门禁的报告应该呈现为什么样子？”“与报告相关联的规则是什么？”“应该用什么工具去落地？”“工具如何在多个机器上部署？”等等。而且，在此之前我曾发现2000个测试大概需要花5~10分钟，效率实在太低，让人无法容忍。所以我就在想：“能不能对JAVA的单元测试做一些性能优化呢？给门禁系统加一些并行测试能力？”

因为容器本来就是我的技术特长点，所以很快就完成了四层结构的系统初步架构设计。接下来就是编译了，刚开始在虚拟机上编译需要两个多小时，很慢；后来就改到物理机上编译，大概30分钟，后来还是觉得慢，就找到了一些官方的快速编译指令，最终提升到十几分钟。

问：过程中有没有印象比较深的事呢？

答：那时本地的机器配置是优于门禁系统所在的机器的，我联系了东莞和西安的小伙伴一起来测试，却意外地发现本地配置虽然更好，却运行得更慢，当时真的很有成就感，不禁感慨：“虽然本地配置好，但通过自己的优化手段，却能让配置差一些的机器比配置好但是没有做优化的机器运行得更快。”

大概经过一个多月，整个门禁系统就部署起来了。得益于门禁系统的四层结构，我们可以对单独的项目实现特定的优化、引入并发测试等等。以前2000个测试用例，现在UT（Unittest，单元测试）执行时间缩短了一倍，性能大大提升。之前门禁系统升级需要几个小时，现在也只需要5分钟就可以搞定。后来，我们通过公司可信总体组的例会等多个平台，将门禁实践分享给了很多其它团队，我也因此获得了智能计算与IT研发管理部的研发部长奖。这是我在华为获得的第一个奖，心里挺高兴的！

问：你的代码写得那么好，有什么秘诀吗？

答：上班以来，我一直有一个习惯，那就是坚定地做“最佳实践”的实践者。那么，什么是“最佳实践”呢？比如写代码或学一门语言，怎么学、怎么写、怎么用呢？官方或者开发者们会有最佳的使用方法，这就属于最佳实践，也可以说是我的秘诀吧。

问：具体怎么用“最佳实践”来解决问题呢？

答：我可以举一个例子，还记得2020年底，PL找到我，问“世龙，XX模块的代码质量堪忧啊~每个版本出的问题都比较多，维护起来成本高，搞得项目组的小伙伴们花大量时间来投入。质量不高引发了频繁的修改，而新的修改又容易引入新的问题，维护起来太累了……看能不能重构整改一下？”

这块代码是用Python语言写的，所以我想，本来Python就是追求可读性的，写得再烂又能多烂呢？何况这个模块确实苦项目组久矣，PL的话刚好也契合我的想法，于是就领了这个任务。从模型建立到最终上线，我的“闭关”重构之旅正式开始。

当我真正深入研究后，才发现跟自己想象的差距很大，例如：代码调用关系不清晰导致很难快速系统地摸清整个逻辑关系；作为一个有代码洁癖的人，面对风格迥异的命名，更是不能容忍各种大驼峰、小驼峰、下划线……

不够好的代码就像身体的小毛病，也许看起来并没有什么大碍，但其实隐藏着很多问题。特别是当增加或修改功能时，它的负面影响则更加突显。

为了解决这个问题，第一步需要回答：“最佳实践是什么？”这个代码到底有多少和最佳实践不匹配？最表象的呈现就是模块组织关系不匹配，语言的用法其实也不太对，模型关系也不够清晰……就这样，梳理出来了很多与最佳实践不相符的点。

第二步，找根源，需要回答：“这些不相符的点是出于什么原因呢？”是当时写代码的人不会写呢？还是有什么深层次的特殊原因呢？经过分析，根因还是建的代码模型不够好，模型关系不清楚就导致有很多冗余代码，进一步导致了很多“散弹式”修改（修改一处代码后，需要同时修改很多处代码）。

既然问题出在了模型，那第三步就要回答：“什么样的模型是最好的模型？”于是，我试图从K8s、Swarm等工具上寻求一些答案，它们到底是怎么组织、安装对应的机器关系，我也研究了很多技术社区的解决方案，学习它们是如何来建模。从早到晚对着电脑研究，看似安静，实则大脑飞速运转，遇到一个又一个坑，再一遍又一遍地从中爬出。这，就是程序员最日常的状态——安静却“疯狂”。

当模型有了以后，就要开始组织关系，最后再结合“门禁”等等让代码看起来更清晰、质量更高。以前我们要改个东西其实很难，因为不知道究竟应该去哪里改，但新的代码则不再有这个问题，增加新功能、新场景或测试时，都是非常完备的，效率更高，可靠性也更好。

问：听说你入职才两年，就已经在带徒弟了，有什么经验和趣事吗？

答：随着自己的成长，我也将自己的编程习惯和开发经验尝试传递给身边更多的人，因为我相信：一点一滴的改变和积累，终将为团队带来一些不同。

记得之前大军和思思加入我的重构任务，一起参与开发，那时模型已经写好，由他们来负责“工步”部分的代码开发。

当时，我提出“这部分代码要写单元测试（UT），满足覆盖率”，要通过门禁的设想。由于之前的编码习惯以及对Python语言的不适应，刚开始大家还有点小吐槽，因为着实让大家痛苦了一段时间，也有同学对我愁眉苦脸地说：“世龙，UT让人很难受啊，能不能把门禁去掉？我们花这么多精力来做这些，有什么好处呢？”

我就笑着告诉他们“先不用管有什么好处，你先按这个写，‘痛’一段时间就会体会到它的‘好处’了……”其实，在我看来，开发者测试本身可以帮助我们看护代码质量，减少低级错误，提升验证效率；在后续的新增或变更需求中，可以快速识别我们的修改是否对之前的功能产生了影响；开发者测试也会让我们的代码保持Clean，帮助我们理清代码结构，把代码写得更好。所以，除了专注代码开发以外，也不能忽视开发者测试的环节。

那段日子，结合部门的软件培训和结对编程，我把自己的方法和经验手把手地教给大家，比如：如何用等价类划分/边界值等等的方法去设计UT、UT工具的使用、常见的UT实践等等。后来，我会让他们先写，再来点赞或吐槽——

“这个代码实现，其实还能写得更好……”

“这么写，其实还可能会带来一些问题……”

大军还是很有疑问：“世龙，这些我也思考过，但为什么我还是想不到这个点？”

其实这个就是我前面说的最佳实践的魅力啦！最佳实践到底是什么？我们结合最佳实践可以怎么做，才能得到更好的效果，这是需要我们细致去思考的，也是需要实践和时间去积累的。比如，我们的代码仓，合入代码难度很高啊！先过门禁，132条规则、UT覆盖率等等，然后还得代码review。同学们其实觉得合入代码要过五关斩六将的，有点害怕，我也会告诉他们以前吃的亏不能重蹈覆辙，小毛病积累成大问题，届时就后悔莫及。不如先把问题在前期发现，

问：通过这些努力，你是否看到了大家的一些改变呢？

答：后来，他们也慢慢接受了这种“设定”，因为感受到了UT的价值，它确实能在测试过程中提升代码的质量、提升效率。直到现在，UT已经成为了他们编码过程中不可缺少的一部分，成为了一种自然而然的习惯。

以前，我们在项目中讨论最多的是“这个业务应该是什么样的？这个东西应该安装到哪儿、写在什么位置？”，但最近却发生了一些变化，大家开始问我：“你这个做法用的什么技术？为什么那么做？”这些问题会更加偏向于技术本身，针对一个问题，大家会去深究它的“最佳实践”是什么，更多地从技术的角度去探讨，这也是让我感到最有成就感的事情。

问：对研发新人，你有什么经验或者想说的话吗？

答：有两句话送给所有研发新人，我们一起共勉：

（1）对研发体系的人来说，做事之前，先问“什么是最佳实践”。然后想一想：“基于当前的知识储备，我们如何提升到最佳实践所需要的能力？”最后，才是具体的开干。

（2）IT人员的能力组成大概分为三部分：通用能力（OS、算法等）、专业技能（语言开发、用法等）、编程习惯（最佳实践、写UT等）。如果你想把研发的路走得更远，这三部分一定要同时发展，并始终保持一颗学习的心。