专访朱雷：昔日的游戏少年，如今的Python工匠

Posted 2022-03-23 图灵教育

print(i, name)

第二段代码相比第一段，就要更Pythonic一点。对于Python程序员来说，追求Pythonic不是「茴字的四种写法」那种浮于表面的形式需求。Pythonic的代码实质上与许多语言底层概念息息相关，比如你可能得掌握：自定义可迭代对象、使用上下文管理器、创建数据模型等知识点，才能在写代码时游刃有余。

作为回报，Pythonic通常会给程序员们带来这些好处：代码更短、速度更快、可读性更强。

说Python难于精通的第二点原因，在于将其应用到规模较大的工程上时。我常听到人们说：「Python只适合做小项目，不适合做大工程。」——虽然片面，但确实有一定道理。因为当你用Python开发大工程时，的确会遇到不少令人恼火的问题。

举个例子，开发小项目时，你可能极少关注Python的类型系统，现写现用。但参与大项目时，为了提升代码的可读性，为了引入静态检查提升程序的可靠性，你可能就得掌握类型注解、泛型、结构化子类等更复杂的类型系统概念，才能让工程质量更上一层楼。

此外，在开发大型项目时，如何用Python做好自动化测试、如何管理项目依赖（包管理工具一只手都数不过来）等，都需要不断学习，从错误中积累经验，着实算得上「难于精通」。

在被几个被称为「坑」的老项目折磨后，

朱雷意识到「代码也分好坏」。

关于代码，有一句话常被人们引用：「程序必须先是写给人读的，然后顺带着让机器执行。（Programs must be written for people to read, and only incidentally for machines to execute.）」，它精准地表达出了「让代码保持可读」的重要性。

评价代码好坏有很多维度，比如可读性、易修改性、编写成本、执行效率等。这里重点谈谈前两个。

好代码一定是比较好读的。也就是说，当读到一段好代码时，我们能比较容易地理解代码的意图，搞清楚它到底做了什么。而烂代码在可读性上则各有各的问题。有的抽象过度，做一件简单的事封装了四层，让人头晕眼花；有的缺乏抽象，相似的代码成片出现，也很难读。

如何写出可读性高的代码，不同编程语言各有各的门道，而有一些准则是通用的：

一个函数内不要包含太多代码

尽量使用精确和有意义的函数名与变量名

在必要的地方编写注释，解释「为什么这么做」

……

评价代码的好坏，除了「可读性」之外，还有另一个着眼于未来的维度——易修改性。现实世界里的软件需求是不断变化着的，「易修改性」提出的问题是：「当需求变更时，你的代码改起来麻烦吗？」要知道，有些代码虽然读起来简单直白，但假如需求发生了一点细微的变化，所有代码都得推翻重写，这当然也是不可接受的。

为了让代码易于修改，程序员们又会引入很多技术来让代码变得更「好」，比如使用恰当的设计模式、设计精准的抽象模型、编写完备的单元测试等等，这些办法都很有用。

3

优秀软件工程师应该具备的「软能力」

谈及如何成为一名优秀的软件工程师，

朱雷认为硬实力固然重要，

但软能力同样不可或缺。

首先，一名优秀的软件工程师，一定要有过硬的专业能力。拿后端开发举例，他不光能写出高质量的后端代码、高效地排查各类问题（debug能力），还能设计出良好的软件架构。除此之外，他也得对各类数据库、缓存系统以及高可用方案的优缺点有所积累，能提出自己的见解。这些东西，网上许多文章都讲透了，我就不再赘述。

我这次主要想提两个与硬实力无关的「软能力」。

第一个「软能力」无关代码和软件，而是和「人」息息相关。具体来说，就是换位思考、高效沟通的能力。

「换位思考」乍听上去是个生活能力，常用于吵架后的自我反省，与程序员的工作似乎没啥联系。但其实并非如此，我来给你举个例子。

在开发一个功能时，除了编写代码完成需求外，你是否试过站在「使用方」的角度做一些思考呢？如果你试过，便会发现许多代码之外的问题一一浮现：「REST API调用起来怎么这么麻烦？它的参数设计真的合理吗？」「这条报错信息这么模糊，其他人看到知道如何处理吗？」把这些基于「换位思考」发现的细节做到位，对你的职业生涯百利而无一害。

而「高效沟通」的用处就更多了。在与同事讨论技术方案时，在沟通代码审查意见时，你是否能做到：既有效表达了自身观点，又不至于搞僵整个讨论氛围呢？良好的沟通技巧，会在无形之中让许多工作变得更简单，当然也会给你带来更好的人际关系。现代职场中，谁又不想要一份好的人际关系呢？

第二个「软能力」是我最近时常想到的一点：「拥抱苦差事」的能力。

程序员们是一个崇尚自动化、极度厌恶重复工作的群体。但在现实世界中，枯燥与重复有时是不可避免的。我去年在博客翻译过一篇文章《拥抱苦差事》，作者在里面就提到：曾连续花了三个星期，将2000多份缺陷报告归类并排好优先级，才把整个团队从bug的泥沼中拉出来，让开发回到正轨。

在你的工作中，相信也少不了这类「苦差事」。它也许是几千份杂乱无章的缺陷报告，也许是上万行质量糟糕但运行着核心系统的遗留代码。面对这类「苦差事」，其他人或许唯恐避之不及。但你如果能调整心态，一步一个脚印，「愚公移山」似的埋头将问题搞定，最后不光能改善你的工作环境，打磨你的工作技能，也一定能帮你赢得许多来自其他人的尊敬和信任。

4

写书，回答「如何写出好的Python代码」这个问题

2016年起，朱雷写了一系列技术文章，

逐渐找到合适的表达，收获诸多好评，

后来以这些文章为骨架写成《Python工匠》一书。

写「Python工匠」的前几篇文章时，我的流程是这样的：挑一个大主题，写一些各自独立的知识点，按「最佳实践」「常见技巧」「常见陷阱」分好类，最后组织成一篇文章。但这样写了四五篇以后，就有点儿腻了，于是我就开始尝试其他形式，比如把一类知识点揉进一个完整的故事里。

在故事的选材方面，我会尽量挑选所谓「接地气」的那种。比如在写 SOLID 设计原则时，我突然想到有很多人喜欢用 Python 写爬虫（我自己也写过不少），于是就杜撰了一个爬虫小项目，把那些复杂的设计原则融了进去。事后发现，读者读起来还挺容易代入的，效果不错。

我写书和写文章都是在业余时间，一般习惯在工作日的早晨（七点左右起床）写一个小时左右，到了周末，如果有精力、没什么别的事儿的话，也会连续写上几个钟。这样算下来，一篇文章大概会花 1~2 周左右。当然，我写东西也不是连轴转，有时写了一篇以后，会「摸鱼」好几个月再写下一篇。

写书这件事能给很多方面带来提升。

通过写一本书，把自己掌握的知识点重新组织一遍，提升肯定不小。但要是说具体哪里有提升，我还真说不上来。能想起来的是，我在写某些章节时，为了保证内容准确无误，特意去读了一本相关的技术书，补齐了几个知识盲点，感觉还挺好。

后来跟帮忙审稿的技术大佬们沟通时，也从他们的审稿意见里学到了不少东西。

除了技术能力外，在写作技巧层面上，写书这事儿对我的帮助也挺大。还记得几年前，我在公司内网发表第一篇「Python工匠」文章时，有一位同事留言道：「这篇文章是翻译过来的吗？」他说这话肯定没恶意，但我当时就意识到：我的文字「翻译腔」太重了——用词别扭，结构也不自然，总之就不像是一个中文母语的人写出来的东西。

在刻意做了许多阅读和学习后，借助写书这个机会，我彻底调整了自己的写作风格，让自己的文字尽量贴近地道的中文表达。这事儿读者买不买账我不知道，但自己还挺开心的。

想写出「好的Python代码」的人，

来读《Python工匠》吧！

如我在前言中所说：《Python工匠》并非一本为零编程经验的新手写的入门书。假如你是一位编程新手，那么我建议你最好先学一些 Python 的基础语法，写上几百行Python代码，找到一些感觉之后再来翻阅本书。

假如那时，你满脑子想的都是：「为啥我的代码就是不如其他人的好？」那么恭喜你，《Python工匠》整本书几乎可以说是为你量身定做的。

END

采访&整理：刘文元

插图：Konami、Bacancy Technology