推荐文章|Article

入行14年，我还是觉得编程很难

作者 朱雷 策划 Tina

2020年，我在公司小组内做了一个分享，当时的PPT标题是《编程十年后的十个感触》。将资料分享在内网后，有位同事看到，评论说光看PPT不过瘾，希望我能将其扩展成一篇文章，我回复说没问题。如今3年过去了，我总算是兑现了自己的承诺。当时的PPT，最后一页，我用纯白色背景给出了一行黑体大字：”十年很短，编程很难”。如今，第二个十年也已快行至中途，而这句话的后半部分好像对我仍然适用。

很多年前，当我还是一名学生的时候，偶尔也会点开一些“高级工程师”的招聘帖，这些帖子里，写着让人眼花缭乱的技术名词，但让我印象最深的是常出现在第一行的岗位年限要求：“本职位要求：工作经验5年以上”。作为一只一天班都没上过的小菜鸟，这些年限要求在我眼里简直长到夸张。不过，望洋兴叹之余，我有时也会在心中暗暗憧憬一下：“五年工作经验的程序员，那该多厉害啊？写代码对于他们来说，是不是像吃饭一样简单？”

时光荏苒，一晃十几年过去了。如今回头一望，自己也成了一名有着14年工作经验的光荣打工人。在软件开发行业摸爬滚打这些年后，我发现很多事情，与我在大四时所想象的大不相同，比方说：

• 随着经验增长，编程并不会变简单太多，“像吃饭一样简单”只出现在梦里

• 给许多“大项目”写代码不光没意思，还很危险，远不如在LeetCode上做一道算法题有趣

• 只从技术角度思考问题，成不了好程序员，有些东西远比技术更重要

细想起来，这类关于编程的感触还有许多。我整理了其中8条，写成了这篇文章。如果其中某些观点引起了你的共鸣，我会非常高兴。

1. 写代码很简单，但写好代码很难

编程曾经是一项门槛很高的专业技能。从前，一个普通人想学编程，最常见的做法就是通过教材和书本学习。不过大部分编程专业书，十分艰深晦涩，对于初学者来说很不友好。因此不少人在尝到编程的乐趣前，就早早地半途而废。

但如今，学编程正在变得越来越容易。学习不再像以前那样，只能硬啃书本，而是多了许多新途径。观看教学视频、参加Codecademy的交互式课程，甚至直接在CodeCombat通过玩游戏来学编程，每个人都能找到适合自己的学习方式。

“妈，我真没在玩游戏，我在学编程呢！你看屏幕右边！”

此外，编程语言也在变得越来越易用。经典的C和Java不再是大多数初学者的首选，许多更简单、更易上手的动态类型语言如今大受欢迎，与之相关的IDE等工具也变得越来越完善。这些因素进一步降低了编程的学习门槛。

总而言之，编程早已褪去了它的神秘面纱，从只有少数人才能掌握的神秘技能，变成了一门人人皆可学习的普通手艺。

但更低的学习门槛、更友好的编程语言，并不意味着人人都能写出一手好代码。如果你已经工作，参与过一些项目，那我很想问你一个问题：”你日常接触的这些项目的代码质量如何？是好代码多，还是烂代码多？”

不知你会怎么回答，我先来说说我的答案。

好代码还是很少

2010年，我跳槽到了一家总部位于北京五道口的大型互联网公司。

加入这家公司前，我只在十人规模的小公司待过，因此，我对新公司在各方面都有着很高的期待，尤其是软件质量方面。当时，我心里想的大概是这样：“这可是支撑了有着千万用户量的产品的‘大’项目，代码质量跟之前那些比，肯定有质的飞跃吧！”

等到在新公司工作了一周后，我才发现自己实在是错得离谱。所谓“大”项目的代码质量同我的预期相去甚远。打开IDE，数百行的函数和神秘的数字字面量比比皆是，开发任何一个小需求都难如登天。

后来，在待过更多公司，接触了更多软件项目后，我总结出一个道理：不论公司多大、项目多牛，在实际工作中遇见好代码，仍然是小概率事件。

好代码有哪些要素？

话说回来，到底怎样的代码才算是好代码？在这方面，Martin Fowler有一句话常被大家引用：

我认为它可以作为评价好代码的原点：好代码一定是可读、易读，且容易理解的。写出好代码的第一原则，就是把人类读者放在第一位。

除了可读性以外，评价代码好坏还有许多其他维度：

• 贴合编程语言：是否使用了当前编程语言的推荐写法？语言特性和语法糖，使用程度是否恰到好处？

• 易于修改：代码设计是否考虑了未来的需求变更，当变化发生时，代码是否容易随之修改？

• API设计合理：API设计是否合理，易于使用？好的API在简单场景下使用方便，在高级场景下又可以随需求扩展。

• 性能够用：代码性能是否满足当前业务需求，同时为未来保留了一定提升空间？

• 避免过度设计：代码是否存在过度设计、过早优化的毛病？

• ……

总而言之，对于任何层级的程序员来说，好代码都不是什么唾手可得的东西。要写出好代码，需要在许多维度上反复权衡、精心设计，最后再加以持续打磨。

既然如此，假如想尽快掌握写代码这门手艺，有捷径吗？

写好代码的捷径

在许多层面上，我认为编程和写作非常相似。二者都是使用文本和符号来表达思想，只是方式略有不同。

谈到写作，我想问一个关于作家的问题：“你听说过不读书的作家吗？你有没有听到过某位作家说，他从来不读其他人的作品，只读自己的东西？”。我猜答案应该是否定的吧。

如果你去查阅相关资料，你会发现许多职业作家的日常生活，就是阅读和写作两件事在不断循环。他们每天会花大量时间阅读各类文字，然后再写作。

同样是“文字工作者”，程序员们就很少重视阅读。但要想快速提升编程能力，阅读正是不可或缺的重要一环。除了日常工作接触到的项目以外，我们应该更多地阅读那些经典软件项目，从中学习API设计、模块架构和代码编写的技巧。

不光代码和技术文档，最好再定期读一些计算机方面的专业书，保持阅读书籍的习惯。在这方面，我认为Jeff Atwood在15年前写的文章"Programmers Don't Read Books --But You Should（都说程序员不读书——但你应该读）"，如今读来仍不过时。

提升编程能力的捷径，就藏在“阅读＜-＞编程”这个无尽循环里。

“一个好的程序员应该做什么？”

2. 编程的精髓是“创造”

在程序员的日常工作中，有很多事情会让人充满成就感，甚至情不自禁地感叹“编程真美好”。比方说，修复了一个极难定位的Bug，用新算法将代码性能提升了一倍，等等。但在所有的这类事情当中，没有任何一件，能和“亲手创造出一件东西”相比。

当你在编程时，创造新事物的机会实际上随处可见。因为并非只有发布一个新软件，才称得上是“创造”。写一个可复用的工具函数、设计一套清晰的数据模型，全都可以归入“创造”的范畴。

身为程序员，保持对“创造”的热情至关重要。因为它可以帮我们：

• 更高效地学习：学习一门新技术，最高效的方式就是用它开发一个真实项目，在创造的过程中学习，效果最好。

• 有机会邂逅了不起的东西：许多改变世界的开源软件，最初都是作者纯粹出于兴趣所创造，比如Linus Torvalds和Linux，Guido van Rossum和Python。

1989年的圣诞假期，荷兰人Guido van Rossum敲下了Python语言的最初几行代码，Python最初仅被期望作为ABC语言的继承者，但后来“吞噬”了全世界

虽然“创造”好处多多，程序员们也有大把机会去做，但许多人常常缺少一种身为“创造者”的觉悟。就像那个广为流传的小故事所说：一位哲学家询问正在砌砖的工人，有人清楚地知道自己是在建造一座大教堂，有人却认为自己只是在砌砖。很多程序员正是“只见砖块，不见教堂”。

将自己定位成创造者后，看待事物的方式就会发生天翻地覆的变化。举个例子，同样是给API增加报错提示文字，创造者们就能跳出“快速完成需求就好”的思维陷阱，向前一步，追问自己一些更重要的问题：“我想为用户创造什么样的产品体验？怎样的报错文字，更能帮助我达成该目标？”

就像任何一个有用的编程模式一样，“创造者思维”也能成为你的职业生涯的一道巨大推进力。因此，现在就试着问自己一个问题吧——“我的下一份创造会是什么？”

3. 打造高效试错的环境至关重要

我曾参与开发过一个互联网产品，它设计精美、功能丰富，每天都有大量用户使用。

但就是这么一个从市场角度看颇为成功的产品，工程质量却非常糟糕。如果你打开它的后端项目，把所有目录翻个底朝天，都找不到任何一行单元测试代码，其他自动化测试流程也是无从谈起。而业务逻辑偏偏又十分复杂，最后，项目代码间的意料耦合多如牛毛，开发一个新特性很容易把旧功能给搞挂。

“在忙啥呢？”“试着修复我之前修一个问题时搞出来的问题，那问题是我之前解决另一个问题搞出来的，而那个问题又是我……”

因此，项目每次发布时，开发和产品同学全都得严阵以待，氛围十分紧张。整个发布过程也很刺激，紧急回滚时有发生。一个人在这样的环境中工作，技术成长抛开不谈，心理素质肯定能得到极大锻炼。

编程原本是一件充满乐趣的工作，但为这样的项目编程，乐趣根本无从谈起。究竟是什么夺走了编程的乐趣？

理想的编程体验≈“刷题”

LeetCode是一个著名的编程学习网站，上面提供了许多覆盖各个难度的编程题，大部分与算法相关。用户可以选择自己感兴趣的题目，直接在浏览器上编写代码（支持十几种编程语言）并执行。如果通过了全部的测试用例，则算作解答成功。

在LeetCode上做题

在LeetCode刷题很像在玩游戏，富有挑战性，同时也很有趣。整个做题过程，实际完美展现了一种理想化的编程体验：

• 关注点分离：每道题目都是一个独立个体，同一时间内，开发者可以完全沉浸在一道题目中；

• 快速获得精准反馈：开发者每次调整代码后，能通过自动化测试快速获得结果反馈；

• 零成本试错：写出的代码语法有错误、逻辑有问题，没有任何不良后果，心理负担小。

不过，屏幕前的你很可能觉得我在说些废话。

“不然呢？解算法题、写小脚本，不就是这样的体验吗？有啥特别值得说的？”你很可能会继续补充道，“你知道我们公司的项目有多复杂吗？规模超大，模块巨多，你懂我意思吗？每天服务×××万人，光数据库就好几套，消息队列都有三种，开发起来当然要麻烦一点咯！”

确实，全世界的软件千差万别，开发起来不可能都像在LeetCode上刷题一样轻松愉快。但这并不意味着，我们不应该努力改善自己身处的编程环境，哪怕只有一点点。

要通过改善环境来提升编程体验，可用的理念和工具包括：

• 模块化思想：妥善设计项目中的每一个模块，降低耦合，提升正交性

• 设计原则：微观层面上，应用那些经典的设计原则和模式，比如“SOLID”原则

• 自动化测试：编写规范的单元测试，必要时使用Mock技术，用自动化测试覆盖业务关键路径

• 缩短反馈回路：切换编译速度更快的工具，优化单测性能，竭尽全力缩短从“改完代码”到“获得反馈”的等待时间

• 微服务架构：必要时，将大单体拆分为多个职责各异的微服务，分散复杂度

• ……

关注编程环境，刻意创造出允许高效试错的“代码乐园”，让工作像刷题一样轻松愉快。是经验丰富的程序员能为自身团队做出的最好贡献之一。

4. 避开代码完美主义陷阱

在代码质量上精益求精是好事，但也要注意别掉进完美主义的陷阱。因为编程不是艺术创作，不鼓励人们无限度地追求极致。作家大可花上数年打磨一本传世之作，但程序员在代码上钻牛角尖就很有问题。

世间没有完美的代码。大多数时候，你的代码只要能满足当前需求，又为未来扩展留了一些空间就够了。有那么几次，我在简历上看到候选人给自己打着“代码强迫症”标签。隔着屏幕，我虽能感受到TA对代码质量的那份重视，但在我心底，其实更期望TA早已将完美主义陷阱远远甩在了后头。

5. 技术很重要，但“人”也许更重要

在软件开发领域，“单一职责原则”（全称为Single responsibility principle，后简称为SRP）是一条非常著名的设计原则。它的定义很简单，一句话就可以概括：“每个软件模块应该只有一个被修改的理由”。

单一职责原则：能做到，并不意味着你就该这么做

要掌握SRP原则，关键在于搞清楚“被修改的理由”为何物。很显然，程序是没有生命的，它自身不能也不需要主动去改变。任何修改程序的理由，都来自与之相关的人，人是导致修改的“罪魁祸首”。

举个简单的例子。看看下面这两个类，其中哪一个违反了SRP原则？

1. 一个字典数据类，支持两类操作：存数据、取数据；

2. 一个员工资料类，支持两类操作：更新个人信息、渲染一张用户资料卡片图。

在大多数人眼里，第一个例子没问题，但第二个例子却明显违反了SRP原则。要得出该结论，好像无需任何严格的分析和证明，运用一丁点直觉即可。但假如做一些正经分析，第二个例子的可疑之处，在于能为其轻松找出两个不同的修改理由：

1. 管理员认为资料中的“个人电话”字段不能有非法号码，需增加简单的校验逻辑；

2. 某员工认为资料卡片图上的“名字”部分太小，希望加大字体。

理解SRP原则的关键，在于先理解人以及人在软件开发中所扮演的角色。

再举一个例子。微服务架构是近些年很火的一个技术话题。但许多人在讨论它时，往往只关注技术本身，却忽视了微服务架构与人之间的关系。

将微服务架构风格与其他东西区分开的关键，在于将大单体拆分为独立的微服务后，不同模块间的边界可以变得更清晰。跟数百人的团队一同维护着一个大单体比起来，许多小组织各自维护着独立的微服务，明显拥有更高的运作效率。

如果缺少了特定的组织规模（也就是“人”）作为前提，空谈微服务的各种技术优势和那些花活，纯属本末倒置。

技术当然很重要。身为技术人员，那一张张瑰丽的架构图和独具匠心的代码细节，天然吸引着我们的注意力。但是，也请千万不要对软件开发里的另一个重要因素“人”视而不见。必要时，转换一下看事情的角度（从“技术”转向“人”），那样对你大有裨益。

6. 求知若渴是好事，但也要注意方法

如今人人都在说“终身学习”，而程序员是一个尤其需要终身学习的职业。因为计算机技术的迭代更新非常快，某个三年前流行的框架或编程语言，很可能一个月前已经过时。

一分钟之内会发生什么事情？Netflix观看时间增长70,000小时；Snapchat上有三百万视频被观看；Google新增两百四十万次搜索；一个JS新框架被发明（这条不是真的）

要在工作中表现得游刃有余，程序员们需要学习的东西非常多，涵盖各个层面。拿我比较熟悉的后端领域举例，一位合格的后端工程师至少需要掌握以下这些：

一种或多种后端编程语言/MySQL等关系数据库/Redis等常见存储组件/设计模式/用户体验/软件工程/编译原理/操作系统/网络基础/分布式系统/…

虽然要学很多，但据我观察，大部分程序员其实都挺爱学习（至少不排斥），因此心态不是问题。不过有的时候，光有“求知若渴”的心态并不够，学习时，我们尤其需要关注“性价比”。

关注学习性价比

下面这张图，展示了学习成效和投入之间的关系。

学习成效与投入关系图，横轴为学习投入，纵轴为学习成效

从图中可以看到，在学习的初级阶段，投入较少时，所获得成效增长飞快。但当成效超过某个阈值后，之后再想继续提升，所需要的学习投入就会呈指数级增长。

正因如此，我建议你在学习任何一项新事物时，先在脑海中想清楚一个问题：“我应该在上图中的哪个位置停下来？”，而不是闷头猛学。

知识的海洋浩瀚无边，有些东西需要我们成年累月的持续学习，不断精进。也有些东西，蜻蜓点水般学到一些皮毛已绰绰有余。准确判断并分配自己有限的学习精力，甚至比努力学习本身更重要。

挑选合适的学习资料

有了学习目标后，下一步就是寻找合适的学习资料。在这方面，我想分享一次自己的失败经历。

有段时间，我突然对产品交互设计产生了浓厚的兴趣，认为自己应该在这方面有所精进。于是，我精心挑选了一本领域内非常经典的专业书：《About Face 4: 交互设计精髓》，将其买回家中，满怀信心地认为自己的交互设计能力可以迅速获得提升。

但事与愿违，当我捧着那本经典著作时，发现自己连第一章都无法顺利读完——那句老话说的没错：“隔行如隔山”。

从这次失败中，我总结出了一点经验。那就是学习某项新东西时，我们最好挑选那些更易读，更适合“门外汉”的学习资料，不要“眼睛大，嘴巴小”，只知道奔着最经典、最权威的资料而去。

回顾之前的经历，我觉得以下几本书非常适合门外汉学习使用，性价比极高：

• 《写给大家看的设计书》：设计相关

• 《点石成金》：Web用户体验相关

• 《鸟哥的Linux私房菜》：Linux系统相关

也许每个人的内心，都想成为一个博学的人，无所不知，无所不晓。但可供分配的时间的精力总是有限，我们不能，也不需要在所有领域都成为专家。

7. 越早开始写单元测试越好

我非常非常喜欢单元测试，我认为写单测这件事，对我的编程生涯影响极大。夸张点说，如果以“开始写单元测试”作为分界线，把我的职业生涯分割成两段，后面那段远比前面那段精彩得多。

写单测的好处很多，比如单测可以驱动你改善代码的设计、可以作为代码的一种文档，等等。此外，完善的单元测试还是构建前面提到的“高效犯错的环境”的关键。

我已经写过几篇关于单测的文章，比如《有关单元测试的5个建议》、《游戏“蔚蓝山”教我的编程道理》。所以在这儿，我不打算再重复一遍。只说一句：如果到目前为止，你从未试过写单元测试，或从没重视过测试，我建议你从明天就开始写起来。

一般情况下我不测试我的代码，但假如测的话，我在生产环境测

8. 程序员最大的敌人是什么？

在大多数程序员段子里，产品经理经常作为反派角色出现。他们口中的项目需求总是变个不停，一天冒出一个新想法，搞得程序员苦不堪言。

客户每天都在不停修改需求，所以，我们决定在下次发布前，把这些需求“冻结”起来

在这些段子的烘托下，不断修改需求的产品经理，仿佛真成了程序员们最大的仇敌。似乎只要产品不乱改需求，大家的工作环境马上就会成为乌托邦。

虽然偶尔吐槽一两句产品经理很有意思，但我还是想一本正经的说一句：产品经理不是敌人。

因为从某种角度来说，软件生来就是准备被修改的（不然你猜，软件为什么叫“软”件？）。这样看来，开发软件和修建房子完全不同。因为没人会在建好一栋大楼后说：“让我们把它推倒重建一遍吧！一样的楼，但是用的钢筋和水泥比之前少30%！”

所以，产品经理以及不稳定的需求不是程序员的敌人。并且，能否写出易于修改、适配变化的代码，是区分普通程序员和优秀程序员的重要标准之一。

那么，程序员们最大的敌人又是什么呢？

复杂度是最大的敌人

就像《代码大全2》中所说：软件开发的核心问题是管理复杂度。失控的复杂度就是程序员最大的敌人。

来看看那些导致项目复杂度不断增长的要素：

• 不断增加的新功能：更多的功能等于更多的代码，更多的代码通常意味着更高的复杂度

• 对高可用的需求：为了实现高可用，消息队列等额外的技术组件和代码被引入

• 对高性能的需求：为了提升性能，缓存和相关模块代码被引入，部分模块被拆分后，换成高性能语言重写

• 一再被推迟的重构：因项目排期过于紧张，迫在眉睫的重构被一再推迟，技术债越积越多

• 忽视自动化测试：没人写单元测试，也没人关心测试

• ……

终有一天，当项目的复杂度增长到一定程度后，空中会传来一声巨响。“咚！”，一个大家不愿改、不敢改的“大坑”凭空出现在了所有人的IDE中。

猜猜看，究竟是谁挖下了这个坑？

那些在降低复杂度上投入时间的团队，所负责的软件项目更容易成功

减缓复杂度增长的过程

虽然复杂度总是会不可避免地持续增长，但有许多实践可以减缓该过程。如果每个人都能做到以下这些事，复杂度就有可能被长期控制在合理范围内：

• 精通当前编程语言与工具，写整洁的代码

• 使用合适的设计模式和编程模式

• 对重复代码零容忍，抽象库和框架

• 适当运用整洁架构、领域驱动设计思想

• 编写详尽的文档和注释

• 编写规范有效的单元测试

• 分离那些变动的与不变的

• ……

要求看上去很多，但总结起来，核心其实就是一句话：写更好的代码。

作者简介

朱雷（@piglei），程序员，爱好编程、阅读以及电子游戏，著有《Python工匠：案例、技巧与工程实践》一书。