2020年，我在公司一个小组里做了一个演讲，PPT的题目是《编程十年后的十种感受》。在内网分享了资料后，一位同事看到后评论说光看PPT还不够，希望我能把它拓展成一篇文章。我回复说没问题。如今，三年过去了，我终于兑现了自己的承诺。在当时PPT的最后一页，我用纯白的背景写了一行粗体字：“十年很短，编程很难”。如今，第二个十年已经快过去一半了，这句话的后半部分似乎仍然适用于我。

很多年前，当我还是学生的时候，我偶尔会点开一些“高级工程师”的招聘帖子。这些帖子充斥着令人眼花缭乱的专业术语，但让我印象最深刻的，还是第一行经常出现的任职要求：“任职要求：5年以上工作经验”。作为一个从未在办公室工作过一天的菜鸟，这些年限的要求在我看来长得可笑。然而，在无奈叹息的同时，我有时也会在心里暗暗向往：“拥有五年工作经验的程序员该有多了不起？对他们来说，写代码就像吃饭一样容易？”

时光荏苒，一转眼十几年过去了。现在回头看，我已经成为一名拥有 14 年工作经验的光荣工作者。在软件开发行业工作了这么多年，我发现很多事情都和自己大四时想象的有很大的不同，例如：

如果你仔细想想，关于编程的这些感受还有很多。我整理了其中的 8 点并写下了这篇文章。如果其中的某些观点能引起你的共鸣，我会非常高兴。

1. 写代码很容易，但写出好的代码很难

编程曾经是一门门槛很高的专业技能，过去普通人如果想学习编程，最常见的方式就是通过教材和书籍来学习，但大部分专业的编程书籍难度很大，晦涩难懂，对初学者并不友好，因此很多人还没尝到编程的乐趣就半途而废了。

但如今学习编程变得越来越容易。学习不再只是看书，而是有很多新的方式。观看教学视频、参加互动课程，甚至直接通过玩游戏来学习编程，每个人都可以找到适合自己的学习方法。

“妈妈，我真的不是在玩游戏，我是在学编程！看屏幕右边！”

此外，编程语言也变得越来越容易使用。经典的 C 和 Java 不再是大多数初学者的首选。许多更简单易用的动态类型语言现在非常流行，相关的 IDE 等工具也越来越完善。这些因素进一步降低了编程的学习门槛。

总之，编程早已失去了它的神秘性，从一门只有少数人才能掌握的神秘技能，变成了人人都能学会的普通手艺。

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

我不知道你会如何回答，所以让我先告诉你我的答案。

好的代码仍然很少

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

在加入这家公司之前，我只在十几个人的小公司工作过，所以对新公司各方面都抱有很高的期望，尤其是软件质量。当时我在想：“这是一个‘大’项目，支撑着一个千万级用户的产品，代码质量肯定比之前有质的飞跃！”

在新公司工作一周后，我意识到自己真的错了，这个所谓“大”项目的代码质量远远没有达到我的预期，打开IDE，到处都是几百行的函数和神秘的数字字面量，开发任何一个小需求都异常困难。

后来，在更多的公司任职，从事更多的软件项目之后，我得出一个结论：不管公司有多大，项目有多棒，在实际工作中遇到好的代码依然是一个低概率事件。

好的代码包含哪些要素？

那么什么样的代码才算是好的代码呢？在这方面，有一句话经常被人们引用：

“傻瓜都能写出这样的代码。这样写出来的代码才是好的。”

“即使是傻瓜也能写出计算机能理解的代码。优秀的程序员编写的代码才是人类能理解的。”

我认为可以作为评价好代码的出发点：好代码必须可读、易读、易懂。编写好代码的第一原则是把人类读者放在第一位。

除了可读性之外，还有很多其他的维度来评估代码质量：

总之，好的代码对于任何层次的程序员来说都不是轻而易举就能写出来的，要想写出好的代码，需要从多个维度反复权衡、精心设计，然后不断打磨。

那么如果想要尽快掌握编写代码的技能，有没有捷径呢？

编写优秀代码的捷径

我觉得编程在很多方面与写作非常相似。两者都使用文字和符号来表达想法，但方式略有不同。

说到写作，我想问一个关于作家的问题：“你听说过不读书的作家吗？你听说过作家说他从不读别人的作品，只读自己的作品吗？”我想答案应该是没有。

如果你查阅相关资料就会发现，很多职业作家的日常生活就是阅读和写作的不断循环，他们每天花大量时间阅读各种文本，然后进行写作。

程序员，同样是“文字工作者”，很少会注重阅读。但想要快速提升编程能力，阅读是必不可少的一部分。除了日常工作中接触到的项目，我们应该多阅读经典的软件项目，学习 API 设计、模块架构和代码编写技巧。

除了代码和技术文档之外，最好定期阅读一些计算机方面的专业书籍，保持看书的习惯。在这方面，我觉得 Jeff 15 年前写的《不要读书——但你》这篇文章依然没有过时。

提高编程技能的捷径在于不断循环“阅读编程”。

“一名优秀的程序员应该做什么？”

2.编程的本质是“创造”

在程序员的日常工作中，有很多事情让人感到充满成就感，甚至忍不住感叹“编程真美”。比如修复一个很难定位的bug，使用一个新算法让代码性能翻倍等等。但这一切之中，没有一件事情能比得上“亲手创造一些东西”。

当你在编程的时候，创造新事物的机会其实无处不在。因为不只是发布一个新的软件才可以称为“创造”。编写一个可重复使用的工具函数、设计一个清晰的数据模型都可以归类为“创造”。

作为一名程序员，保持对“创造力”的热情非常重要。因为它可以帮助我们：

1989 年圣诞假期，荷兰人范敲下了这门语言最初的几行代码，最初人们只期望它能成为 ABC 语言的继任者，但后来它却“吞噬”了全世界。

虽然“创造”有很多好处，程序员也有很多机会去创造，但很多人往往缺乏“创造者”的意识。就像那篇广为流传的故事：一位哲学家问砌砖的工人，有的人明知道他们在砌一座大教堂，有的人却以为自己只是在砌砖。很多程序员“只看到砖头，却看不到大教堂”。

一旦你将自己定位为创作者，你看待事物的方式就会发生巨大变化。例如，在为 API 添加错误消息文本时，创作者可以摆脱“只需快速完成需求”的思维定势，向前迈一步，问自己更重要的问题：“我想为用户创造什么样的产品体验？什么样的错误消息文本可以更好地帮助我实现这个目标？”

和任何有用的编程模式一样，创客思维可以极大地促进你的职业生涯。所以，现在问自己这个问题——“我的下一个创作是什么？”

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

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

然而，虽然从市场角度来看该产品相当成功，但其工程质量却非常糟糕。如果你打开它的后端项目，把所有目录翻过来，你根本找不到任何单元测试代码，更不用说其他自动化测试流程了。业务逻辑也非常复杂。最后，项目代码之间存在许多意想不到的耦合，在开发新功能时很容易破坏旧的功能。

“你在做什么？”“尝试修复我在修复时创建的一个问题......

所以每次项目发布，开发人员和产品开发人员都要高度警惕，气氛非常紧张。整个发布过程也非常刺激，经常出现紧急回滚的情况。一个人如果在这样的环境中工作，无论技术成长如何，心理素质肯定会有很大的提高。

编程本应是一份有趣的工作，但当为这样的项目编程时，乐趣就消失了。是什么夺走了编程的乐趣？

理想的编程经验≈“练习题”

它是一个知名的编程学习网站，提供了很多不同难度的编程题目，大部分都是算法相关的。用户可以选择自己感兴趣的题目，直接在浏览器上编写代码（支持十几种编程语言）并执行，如果所有测试用例都通过，则视为答题成功。

做以下问题

做题就像玩游戏一样，既有挑战性又充满乐趣。整个做题过程其实完美地展现了理想的编程体验：

不过，屏幕前的你们也许会觉得我在胡说八道。

“还有什么？解决算法问题和写小脚本，不是一样的体验吗？有什么特别的？”你可能会继续补充道：“你知道我们公司的项目有多复杂吗？规模非常大，模块非常多。你明白我的意思吗？我们每天服务XXX万人，有好几个数据库，三个消息队列，开发起来当然麻烦一点！”

确实，世界各地的软件都千差万别，不可能像在教室里做练习题那样轻松愉快地开发。但这并不意味着我们不应该努力去改善我们所处的编程环境，哪怕只是一点点。

为了通过改善环境来提高编程体验，可用的概念和工具包括：

关注编程环境，刻意营造一个允许高效试错的“代码天堂”，让工作变得像解决问题一样轻松、愉快，是一名经验丰富的程序员能为其​​团队做出的最佳贡献之一。

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

追求代码质量的卓越是件好事，但要小心不要陷入完美主义的陷阱。因为编程不是艺术创作，所以不鼓励人们无休止地追求完美。作家可以花费数年时间打磨出一部杰作，但程序员在代码上陷入死胡同就麻烦了。

世界上没有完美的代码，很多时候你的代码只需要满足当前的需求，为未来的扩展留一些余地就行。有几次我看到应聘者在简历上写着自己是“代码强迫症患者”，虽然隔着屏幕都能感受到他对代码质量的重视，但内心其实希望他/她已经远离完美主义陷阱了。

5. 技术很重要，但人更重要

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

单一职责原则：你能做某件事并不意味着你应该做这件事

掌握SRP原则的关键是理解“修改的理由”。显然，程序是没有生命的，不能也不需要自己去改变。任何修改程序的理由都来自于涉及的人。人是修改的“罪魁祸首”。

我们举一个简单的例子，看看下面两个类，哪一个违反了SRP原则？

支持两种操作的字典数据类：存储数据和检索数据；

员工数据类，支持两种操作：更新个人信息和渲染用户数据卡图像。

在大多数人眼里，第一个例子没什么问题，但第二个例子明显违反了 SRP 原则。要得出这个结论，似乎不需要严谨的分析或证明，一点直觉就足够了。但如果认真分析一下，第二个例子就很可疑了，因为它很容易找到两种不同的修改理由：

管理员认为数据中的“个人电话”字段不能有非法数字，需要增加简单的验证逻辑；

一名员工认为信息卡上的“姓名”部分太小，想增加字体大小。

“是谁。而你不想，或者，按照许多人关心的代码。”——“”

“人们是要求对软件进行更改的人。你永远不想把不同的人出于不同原因关心的代码混在一起，这只会让他们和你自己感到困惑。”——单一责任原则

理解 SRP 原则的关键是首先了解人们及其在软件开发中扮演的角色。

再举一个例子，微服务架构是近年来非常热门的技术话题，但很多人在讨论它的时候往往只关注技术本身，却忽略了微服务架构与人的关系。

微服务架构风格区别于其他的关键在于将单体拆分成独立的微服务之后，不同模块之间的界限能够更加清晰。相比几百人共同维护一个单体的团队，多个小型组织各自维护独立的微服务，运营效率明显更高。

如果缺乏一定的组织规模（也就是“人”）这个前提，去谈论微服务的各种技术优势、花哨的东西，就本末倒置了。

技术当然重要，作为技术人员，那些华丽的架构图、精妙的代码细节自然吸引我们的目光。但是，请不要忽视软件开发中另一个重要的因素：“人”。必要时，换个角度（从“技术”到“人”），会对你大有裨益。

6、好学是好的，但也要讲究方法。

现在大家都在讲“终身学习”，程序员是一个尤其需要终身学习的职业。因为计算机技术更新非常快，三年前流行的一个框架或者编程语言可能一个月前就已经过时了。

一分钟发生了什么？7 万小时的观看时间；300 万个视频被观看；240 万次新搜索；发明了一个新的 JS 框架（不是真的）

为了能够在工作中表现出色，程序员需要学习的东西非常多，涵盖各个层面。以我比较熟悉的后端领域为例，一名合格的后端工程师至少需要掌握以下几点：

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

虽然要学的东西很多，但就我的观察，大部分程序员其实还是很爱学的（至少不排斥），所以心态不是问题。不过有时候光有“渴求”的心态是不够的，学习的时候尤其要注重“性价比”。