gitbook/代码之丑/docs/341595.md

80 lines
9.1 KiB
Markdown
Raw Permalink Normal View History

2022-09-03 22:05:03 +08:00
# 结束语 | 写代码是一件可以一生精进的事
你好,我是郑晔。
春节将至,祝你新春快乐!我们的专栏到这里也正好要更新完结了,在结束语这一讲,我想和你聊聊程序员精进的话题。
创作《[10x 程序员工作法](https://time.geekbang.org/column/intro/100022301)》之初,我曾经定下了“写下 100 篇”的宏伟目标。在第三个专栏结束的时候,这个当年许下的宏伟目标终于实现了。
如果为这 100 篇的内容找一个共同的主题,那就是程序员精进之路。
## 程序员精进之路
在很多人心目中,程序员是一个辛苦的职业,一方面,各种新东西层出不穷,程序员们要努力追随,另一方面,业务飞速发展,我们唯有积极应对。那么,是什么支撑你在这个富有挑战的行业里坚持前行呢?
于我而言,这个问题的答案是,热爱。
在我的心目中,编程是一项有趣的智力活动,从最初解决一个特定的小问题,到现在创造一个方案去解决一个系统的问题,无不需要费尽心力去探寻一个好的解决方案。时至今日,即便我写程序已经二十多年了,但每次程序运行通过时,我心里依然还是有一些小激动,因为支撑程序运行的每行代码里都有自己的思考在里面。
正是每次一点点积累起来的成就感,激励着我不断去探索更好的做法。一开始,为了解决特定的问题,我四处搜集着各种编程技巧。当我理解了基本功的重要性后,就去拼命地补齐各种基础知识,构建起一个知识体系。随着开源软件运动的兴起,我知道了,原来有各种工具和程序库可以简化自己的工作。因为见识过别人的运指如飞,我曾专门练习了各种快捷键和命令行。
当我已经能够很好地解决自己面对的各种功能问题时,我开始抬起头,有了更大的视野。
我学习了各种软件设计的知识,让自己的代码不仅仅是为了今天,也能够面对未来。我学习了各种程序设计语言,看到了隐藏在语言背后的编程范式和思考习惯。我学习了各种软件开发的最佳实践,懂得了怎样让一群人更好地协同。
我做的所有努力,都是为了更好地写代码。
有了对于软件开发更多的思考,回过头再来写代码时,我就能看到更多的维度,能意识到自己在写的代码对他人和未来的影响,这时自然会尽力把自己的代码写得更整洁。
时至今日,如果你问我,对自己写的代码满意吗?我的答案还是不满意。**写代码是一门手艺,需要不断地打磨。**一方面,坚持写代码,保持自己对于代码的体感;另一方面,保持对于代码的敏感度,不断思考对于代码的改进,寻找更好的写法。
经过一段时间,我总会发现代码中让我不满意的地方,这会成为新的驱动力,让我进一步扩充自己的知识,把新的理解注入到代码之中。每次拓展知识边界,与之相伴的都是极大的智力愉悦。也正是这种智力上的快感,让我得到了进一步前进的动力。一个正向反馈的循环就是这样逐步推进,让我在写了二十多年代码之后,依然乐此不疲。
我在《[软件设计之美](https://time.geekbang.org/column/intro/100052601)》中讲过,一个好的设计是在一个“小内核”上构建起来,然后,逐步添加更多模型。我们的知识拓展过程也是如此。我的“小内核”就是编写代码这件事,所有一切知识的拓展都是围绕这个内核展开的。
**写代码是一件可以持续一生的事情,但前提条件是,找到自己的热爱,建立起自己的正向反馈。**坚持写代码,发掘代码中值得改进的地方,不断拓展自己的知识边界,寻找更好的代码写法,这就是最朴素的程序员精进之路。
## 代码的敏感度
对于一个不断精进的程序员而言,发掘代码中值得改进的地方,需要对代码有细致入微的敏感度,这样才能体察代码间细微的差别。
我给你举个例子:注释。
代码该不该写注释呢?在一些人看来,没有注释的代码不值得写,这甚至成了一些程序员的宗教信仰。如果你问他们为什么要写注释,他们的回答多半是“让程序更加容易理解”。
但有另外一群人则将注释视为坏味道,他们会说,为什么不把代码写得更清楚,让代码不需要注释呢?被逼到角落的“注释程序员”依然不会束手就擒,他们不会承认自己不能把代码写清楚,而会说,有些代码必须要有注释才能解释清楚,比如一些算法。
好了,双方的主要观点陈述完毕。你怎么看待注释呢?
早在 1984 年,《计算机程序设计艺术》的作者 Donald Knuth 就给出了一个回答,他提出了“[文学编程Literate Programming](https://en.wikipedia.org/wiki/Literate_programming)”的概念,其核心要义就是要将程序写得像用自然语言进行表达一样顺畅。虽然作为一种编程范式,它并没有流行起来,但它背后蕴含的思想却影响了很多人,也给我们提出了更高的技术追求。
一个好的程序应该像一篇优美的文章,读起来自然流畅,二者背后有诸多相通之处,**你会看到,许多优秀程序员都有着优秀的表达能力。**所以,回到写代码本身,把程序本身写得更清楚直白才应该是我们的追求。关于如何把代码写好,我在这个专栏已经讲了很多了。
具体“注释”这件事上,我的观点是,“注释”有其价值,但不应该是主力。我们没见过哪篇文章是要求把注脚作为主旨的,同样,过于强调注释,无异于本末倒置。写代码首先应该是把代码本身写好,至于那些确实无法用代码陈述清楚的部分,我们再考虑用注释。
所以,我赞同把“注释”当做坏味道的提示**,先竭力把代码写到不需要用注释,而把注释当作最后的选择**。确实有一些特定的处理需要注释,无论是一个精巧的算法,还是一个特殊的技巧。用这个标准要求自己,你会发现,大多数代码其实不需要注释,因为它们太普通了。
你看到了,即便像注释这么简单的东西,写与不写,背后都有着可以探究的各种细节。诚如我在前面所说,写代码是一门手艺,需要不断地打磨。唯有不限界地拓展自我,才可能对代码有细致入微地把握。
你发现了,打磨手艺,锤炼自己对于代码的敏感度,坏味道是一个不错的出发点。这也是我写这个专栏的初衷,帮你从识别出那些你曾视而不见的“坏味道”,提升你对代码的敏感度。
在这个专栏中,我给出的就是全部的坏味道吗?显然不是。只要拿出《[重构](https://book.douban.com/subject/30468597/)》对照一下,你就会发现,坏味道还有许多,比如,霰弹式修改和发散式变化。我没有拿出来讲,不是它们不重要,而是它们不像我在这个专栏中罗列的这些坏味道那样,有非常直观的表现。
比如,霰弹式修改说的是一次变化要在很多类的内部做修改,但能否察觉出自己改了很多类,这就依赖于每个人的敏感度了。
同样,发散式变化说的是,不同的变化都会改到同样的模块上。发现这种坏味道,需要你意识到,对同一个模块的修改是由于不同的原因造成的,这对于敏感度的要求就更高了。
无论如何,“知道”有哪些坏味道是第一步的。我建议你在学习了本专栏之后,花上一点时间,通读一下《重构》的第三章“代码的坏味道”,在开篇词中我就提到过这件事,但与那时不同的是,现在你已经通关了我们这个专栏。
我在专栏里讲的所有这一切,一方面,让你对一些代码的坏味道有直观的认识;另一方面,也是更重要的,对于这些坏味道的分析,是为了帮你看到代码里的细微之处,帮助你提升对于代码的敏感度。有了不同的敏感度,再去通读“代码的坏味道”,你会有不一样的收获。
这些道理都是知易行难,今天我们的课程就告一段落了,但是你的精进之路并未停止。
有了“坏味道”的基础之后,接下来最重要的是,你要在实际的工作中反复地锤炼自己的编程手艺,用这些坏味道作为尺子,衡量自己的代码,不断地找到代码更好的写法。这个专栏以及它的两个“兄弟”,帮你开启了程序员的精进之路,但这条路,总归还是要自己去走!
这次的《代码之丑》的旅程就暂告一段落吧,如果以后有机会,我会再来与你分享我对软件开发的理解。
专栏结束了,你也可以在留言区提问,我看到还是会回复的。也欢迎你点击下面图片,为我的《代码之丑》评分、提建议。期待你的反馈,再见!
[![](https://static001.geekbang.org/resource/image/e1/d2/e13cd07d9d785556352514ac73a950d2.jpg)](https://jinshuju.net/f/fQqoLu)