人物说明：
- 大师：从事开发工作 20 年有余，精通各类编程语言，有着常人难以匹敌的软件工程经验，说话时惜字如金，有时会让人觉得有些神神叨叨（但人不坏）。
- 学徒：学习编程的时间不长，热衷于提升自己的软件开发技能，勤学好问。
1. 1 行代码与 20 行注释
一天，学徒问大师：“我每天都写很多代码，实现很多需求，为何编码水平却停滞不前？”
大师回答道：“让我看看你在写些什么。”
学徒打开电脑。大师指着屏幕上一行普通的赋值语句，说：“当你有一天意识到，需要在这前面补充 20 行注释时，你就成长了。”说完，大师转身离开了。
piglei 说
在编程时，人们理想中的代码应该是“自说明”的——无需任何注释也很容易理解。
但也有些时候，程序要处理的场景过于复杂，导致我们实际上没法只用代码就将重要信息全部表达出来。此时，如何找到那几行重要的代码，并用大段注释将隐藏的知识有效表达出来，就变得很重要。
作为一名程序员，有能力编写可读性高的代码固然很好，但若是还能信手写出言简意赅的注释与文档，更是锦上添花。
2. 删掉注释
一天，学徒问大师：“我每天都写很多代码，实现很多需求，为何编码水平却停滞不前？”
大师回答道：“让我看看你的代码。”
学徒打开电脑，大师指着屏幕上的一段注释，说：“删掉它。”
学徒照做。沉吟片刻后，学徒大声说道：“我明白了，你是说要关注代码本身的描述性，而不是过度依赖注释来解释代码！”
大师摇摇头，说：“不，我只是想看看你的指法，而据我观察，你甚至不能盲打。”然后，大师转身离开了。
piglei 说
学徒口中的“关注代码的描述性，不要过度依赖注释”诚然很对，但这次，顽皮的大师的关注点实际上在别处：基础技能（盲打）。
在工作中，一名程序员要用到的工具多种多样。我见过一些程序员，他们就像段子中不会盲打的学徒一样，对每日使用的编辑器、IDE 和命令行工具只是略通皮毛，从未花时间系统性地学习过。
但是，深入掌握那些日常工具，以及有意识地增进那些底层技能（比如说打字速度），实际上会对工作效率带来意想不到的丰厚回报。
3. 微服务架构能力
一天，学徒问大师：“我该如何提升自己的微服务架构能力？”
大师回复道：“让我看看你的代码。”
学徒打开电脑，大师看到项目的 utils 目录，其代码规模数倍于其他功能模块的总和。大师说道：“如果你不懂如何组织模块，那么你实际上也无法‘架构’任何其他东西。”
然后，大师转身离开了。
piglei 说
设计一个大的单体项目，与设计由一堆微服务构成的分布式系统之间有许多相通之处，二者遵循一些类似的指导原则。
比方说“单一职责原则”，该原则所回答的问题是：”应该如何设计项目的模块（或微服务），才能让我们在开发功能时，不牵扯太多无关的模块（或微服务）？“它对于两种架构风格同样有效。
“模块化”是软件开发中最重要的指导思想之一，无关架构模式。
4. 聪明的代码
一天，学徒问大师：“我将 10 行 Python 代码用推导式优化成了 1 行，新代码非常漂亮，为何提的 PR（代码合并请求）却被拒绝了？”
大师说：“你的 PR 是我拒绝的。”
见学徒有些吃惊，大师又补充道：“我一个月前写了那 10 行代码。”
学徒的脸有些红，不过仍不想放弃自己的 PR，于是他争辩道：“但是，就在我改动的函数旁边有个类似的函数，那里面有许多更复杂的单行推导式代码，为什么把它们合并进来？”
“哦，那是我 10 年前写的代码。”大师答道。
piglei 说
“什么样的代码是好代码？”
对于这个问题，随着“编码工龄”的增长，我们的答案会发生天翻地覆的变化。
段子里的大师，十年前醉心于用最少的代码表现最复杂的逻辑。十年后，却更倾向于写那些平平无奇的简单代码。
对于代码来说，“可读性”永远是第一位。将诸多逻辑压缩在一行代码中，是一种有趣的思维训练（容易让作者自我感觉良好），但常常以损害可读性为代价。
在编程时，我们需要在“华丽的代码”和“朴实的代码”间找到一个平衡点，而据我观察，随着经验的增长，那个平衡点会持续向着“朴实”那一端移动。
此外，我还有一句话想对学徒说：“既然没 bug，咱不如就别动那些代码了呗？”