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

朱雷（@piglei）：曾就职于搜狐、赶集网，现就职于腾讯IEG技术运营部，现任蓝鲸工具PaaS平台负责人。

2008年，他初次接触Python便乐在其中，开启了此后十余年的Python编程生涯。

2016年，他开始创作「Python工匠」系列开源技术文章，其GitHub Star数超过4K，被多家媒体全系列转载，收获诸多好评。

他为何从Java「倒戈」到了Python？如何才能学好一门编程语言？到底怎样才算是好的Python代码？优秀的软件工程师应该具备哪些能力？今天，图灵访谈带你走近朱雷（@piglei），一起来了解他的Python编程之路。

1

从Python编程中获得了乐趣

从游戏少年到计算机本科生

细数起来，我其实不是那种「自幼喜欢编程」的人，我自幼喜欢的就一门：电子游戏。在我小时候，家长为了保障子女顺利发展成「21世纪的综合性人才」，常会往家里买很多新奇的装备，比如当时最流行的小霸王学习机（此处暴露年龄）就是其一。我爸给我买小霸王，是因为听说它可以用来学五笔打字，对大脑发育也有帮助。但相信不少人和我一样——五笔只学到一级简码，《魂斗罗》《忍者龙剑传》和《赤色要塞》等游戏技术倒是掌握得炉火纯青。

读高中一年级（03年）时，家里给我买了第一台电脑。我一开始用它干得最多的事儿还是打游戏。但和小时候玩小霸王不同，那时出现了一个小小的转折，把我从钻研「红警」技术的道路上扳回来了一点儿：

在当时，我有一位很要好的朋友（《Python工匠》一书的致谢里提到了他）痴迷于网页制作、黑客技术等各种奇奇怪怪的东西。他经常兴致勃勃地给我演示各类「高端（上古）」技术：制作Flash动画、搭建BBS、使用Dreamweaver 制作网页等。受他的影响，我第一次认识到：原来电脑除了可以用来打游戏，还能做这么多有意思的事儿！

再后来，到了大学选专业时，我很自然地就选了计算机。父母知道我就爱折腾这些，自然也就没有做任何干涉。

我在前言里说：「读大学时，没想过自己会以写代码为生」，不是因为不喜欢写代码，而是因为当时自己的编程水平真不怎么样。大学四年，我就只是按部就班地学完了所有的专业课程（甚至还因为贪玩挂过科）。到了毕业时，对于自己能做什么、能做好什么，想法非常模糊，没什么底气。

职业规划自然也很混乱。当时我的底线大概是这样：不管是运维、网站开发、嵌入式开发还是安全维护，只要与专业挂点儿钩的工作我都能接受。

2008年初次接触Python，

朱雷很快就从Java「倒戈」向了Python。

我在大学四年里接触最多的高级编程语言就是Java——我的毕业设计就是用Java写的。

如果在今天，我会说Java是一门极度成功，在许多方面都非常优秀的编程语言。但在当时，我从Java「倒戈」到了Python，其实还是因为没在Java上获得太多乐趣（有肯定有，但不多），而接触Python后，突然发现写代码还能这么轻松——不用声明类型、不用事事定义class、不用管啥私有公有。心态轻松后，写代码也变得有趣了很多。

这事儿我们可以拿游戏来类比一下。假如把一个编程的门外汉，类比成一个从来没有接触过主机游戏的人，他要怎么才能突然变成一个主机游戏爱好者呢？有时，能击中他、让他喜欢上主机游戏的是同事手上的《塞尔达传说：荒野之息》。有时，能成功拉他「入坑」的则是视频网站推荐的《最后生还者》游戏片段。

人们会因为不同的游戏关注到主机游戏领域，进而发展成一名主机游戏爱好者，之后各类游戏通吃，这其实和我们因为不同的编程语言爱上了编程一样。Java没能把我成功领上职业程序员的道路，但Python做到了，简单来说就是这样。

2

Python学习：注重实践，向Pythonic看齐

对于Python新手，

朱雷建议要从实际出发，同时要不断学习。

学习一门编程语言，我的建议就是不要光学不练，最好着眼于实际工作（生活）中遇到的问题或麻烦，试着用程序解决掉它们。比如，每天早晨你都得整理一份excel，费时费工，那么是不是可以试着用Python写个脚本，把这件事情自动化呢？在这个过程中，你的编程技能自然而然就会变强。

然后，定期阅读一些优秀项目的源码、读一些编程有关的书籍也很重要。当你学到一些新知识后，务必时常回头Review一下自己曾写过的那些旧代码，找找哪些地方写得不够成熟，做做重构和优化——「温故而知新」，学习效果上佳。

Python是一门「易于上手、难于精通」的编程语言。

说Python易于上手，主要原因在于它是一门动态类型的解释型编程语言。对于初学者来说，不必了解太多编译器、类型声明、内存安全之类的概念，只要装好解释器，随随便便写几行代码就能跑起来，门槛很低。此外，Python语言的语法和关键字设计，都非常接近于自然语言，可读性较高，甚至常在算法文章里被作为「伪码」使用。

至于「难于精通」，这个就有点儿见仁见智了。如果分两点来说，精通Python的第一个难点在于「怎么写出地道的Python代码」。Python程序员们对于「代码是否地道」有着很强的追求（说执念也行），社区甚至专门发明了一个形容词Pythonic，来形容一段代码是否地道。

拿一个常见的场景：遍历列表并获取下标举例。一个Python初学者可能会写出下面这样的代码：

index = 0
for name in names:
    print(index, name)
    index += 1

但一个有经验的Python开发者，写出的代码可能是这样的： 

for i, name in enumerate(names):
    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工匠》整本书几乎可以说是为你量身定做的。