21 | 你的代码为谁而写？

郑晔



该思维导图由 AI 生成，仅供参考

你好，我是郑晔。
关于“沟通反馈”的话题，我准备从代码开始讲起，毕竟我们程序员是靠代码与机器进行沟通的。
写代码是每个程序员的职责，程序员们都知道要把代码写好。但究竟什么叫写好呢？每个人的理解却是各有差异。
编写可维护的代码初涉编程的程序员可能觉得能把功能实现出来的代码，就是好代码，这个阶段主要是基本功的学习，需要掌握的是各种算法、数据结构、典型的处理手法、常用的框架等等。
经过一段时间工作，日常工作所需的大多数代码，在你看来都是不在话下的。尤其像搜索和问答网站蓬勃发展之后，你甚至不需要像我初入职场时那样，记住很多常见的代码模式，现在往往是随手一搜，答案就有了。
再往后，更有追求的程序员会知道，仅仅实现功能是不够的，还需要写出可维护的代码。于是，这样的程序员就会找一些经典的书来看。
我在这方面的学习是从一本叫做《程序设计实践》（The Practice of Programming）的书开始的，这本书的作者是 Brian Kernighan 和 Rob Pike，这两个人都出身于大名鼎鼎的贝尔实验室，参与过 Unix 的开发。
写出可维护的代码并不难，它同样有方法可循。今天，我们用写代码中最简单的一件事，深入剖析怎样才能写出可维护的代码，这件事就是命名。

公开

同步至部落

取消

完成

0/2000

荧光笔

直线

曲线

笔记

复制

AI

深入了解
翻译
英语
中文简体
中文繁体
法语
德语
日语
韩语
俄语
西班牙语
阿拉伯语
解释
总结

程序员写好代码的关键在于良好的命名规范和对业务知识的理解。本文强调了代码不仅是与机器沟通，更是与人沟通，因此应该用符合业务语言的方式编写代码。作者通过深入浅出的方式向读者传达了编写可维护、易读的代码的重要性，以及如何从业务角度出发进行命名，从而提高代码质量和团队协作效率。文章建议程序员学会用业务语言写代码，尽可能多地学习业务知识，将业务领域的名字用在代码中。总之，良好的命名规范和对业务知识的理解是写好代码的关键，而写好代码不仅是实现功能，更要追求代码可维护。

仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《10x 程序员工作法》，新⼈⾸单¥68

立即购买

登录后留言

全部留言(29)

最新
精选

Jxin
可读性，可扩展性，性能，可维护性。我写代码围绕这三点。老师讲的我认为可以划分在可读性。除了了老师讲的业务命名，可读性还有：适当的注释，方法内适当的拆分以保证方法内主流程简洁，减少多层嵌套判断，规避复杂判断条件，采用公司统一编码风格等等。扩展性：采用合适的设计模式，遵循各种规范协议，比如java的草案，采用主流框架，比如java的spring全家桶。性能：有意识的去减少网络io，规避长事务，敏感的时间复杂度和空间复杂度的变别能力，jvm的运行原理，快速精准的测试能力。可维护性：规范的日志记录（其他监控什么的跟编码无关了）。代码规范的书：阿里的<码出高效>和<阿里开发手册>很不错，推荐。
作者回复: 很好的补充。但我不是只在写可读性的角度，我讨论的是大家思维中的盲区。我知道，很多书和文章也会告诉你那些基本知识，我想给大家补充的是，一条主线，一条把这些知识贯穿起来的主线，这是你在别的书和文章中不容易找到的东西。缺少了这条线，你虽然很努力，出了问题依然不知道是哪出的问题。
2019-02-21
3
39
西西弗与卡夫卡
在一些特定情况下，我还用中文甚至中文短句命过名。虽然看起来有些古怪，但考虑到如果不用中文就要用复杂的英文名还要辅助注释才能看明白，就两害取其轻了。毕竟代码是让以后的人看懂，不管是自己，还是交接给别人。另外，代码最好能在几十行以内。还有，可以通过写容易懂的测试代码来展示复杂代码所要表达的逻辑，有些时候比注释管用
作者回复: 对程序员来说，加强英文学习是一项必修课。我们以为中文好用，一个原因是没找到好的英文说法。在我的实践中，我会先去找到这个领域模型的英文表达做成词汇表，然后再开始写代码。用测试当注释倒也是我经常使用的手段。
2019-02-20
4
22
黒ウサギ
英语是很重要，有时候定义一个属性名称，还得去理解一下类似的词的意思，比如说state和status，class和category之类的，还要考虑下哪个词短一些、哪个是领域内或者老外常用的、哪个更好让英语不好的人看懂(包括自己)……感觉对我这种英语不算好的人来说，挑个词挺花时间的(算强迫症吗？)
作者回复: 多练习
2019-02-20
3
13
陈斯佳
代码也是一门语言，语言的本质就是降低交流成本。
作者回复: 能认识到前半段的程序员很多，认识到后半段的程序员就不多了。
2019-08-09

12
梦倚栏杆
order 这个例子举得特别形象，深有体会。我们这边就是写代码的时候一个地方把task名字占用了，然后其他地方的task懵逼了
作者回复: 起名字难，难在起一个具体的名字，很多人太容易随手起一个通用的名字。
2019-02-22

11
TH
领域驱动设计确实是写出合适的代码结构的一项训练，程序员会不由自主地按照自己的习惯，也就是按照计算机运行逻辑去设计代码，这样的代码很容易陷入难以维护的坑。在开始动手写代码之前跟用户交流清楚，理解设计的概念、流程、使用场景、特殊情况，这些都很重要。另外我特别关注的一点是可变项和不变项的分离，因为我们的业务场景对可扩展性要求很高
作者回复: 分清可变和不变，这是很赞的做法！
2019-02-21

9
行与修
在了解业务的基础上，我觉得写好代码之前要做两个铺垫：设计和分解。设计可以是整体的，也可以是局部的，厘清思路为适度。分解即任务分解，保证代码铺开有章可循。新人入行，有了一闪而过的灵感往往就动手了，随着深入再往返折回很是忙碌，经验不足是客观存在的，但习惯还是早培养早受益，经验不足者那就做些简单的设计，等丰富了再做细致的设计就好，个人倾向于前面多花点时间。写代码要通俗易懂，条理清晰，阶段性项目内部review，让不同模块编写者来执行。另外我是不建议用中文命名的，此时用中文注释补充也未尝不可。
作者回复: 有益的思考
2019-02-20

9
马斯费油
代码主要是为了写给人看的，而不是写给机器看的，只是顺便也能用机器执行而已
作者回复: 这个说法很到位！
2019-03-13

6
布衣骇客
补课追上来了，写test，有注释，命名经常和接口作用相近类似，尽管有的时候命名会比较长，但是通俗易懂，加上简易几句中文解释，跑完junit，完成一个小小业务实现。刚好最近看了下代码整洁之道，老师也推荐了，确实很不错
作者回复: 继续加油！
2019-02-21

4
Jerry Wu
注释也同等重要，应该要多加一句：用业务的语言写代码，用业务的语言写注释。
作者回复: 对于写注释，我持保留意见。
2020-04-24

2

收起评论