日常的搬砖过程中，我们总会因为代码上的一些设计问题，进行争论。而最后结果呢，可能就是『show me you code』，又或者是『你行你来』。

在这里，我们要抛开一个因素来讨论问题：规范。团队在成长的过程中，必然要养成自己的规范。本身缺少规范而讨论规范，这就不是个问题了。如果规范不对，这又是另外一个问题了

所以，我们的重点还在于：设计，本身就存在一些主观因素，没有绝对的好与坏。人们还可能：

• 针对于未来而设计，假想一系列的设计 —— 虽然这是错的，但是要证明这是错的很难
• 因为自己的喜好，试图去说服别人你也应该这样做
• 因为不平行的双方地位、角色，需要花费额外的功夫

而抛开设计的角度，也总有一些人喜欢去对别人的代码『品头论足』。

评论别人的代码，并没有任何问题 —— 代码是写给人看的。就好像是人的衣着打扮一样，有人擅长打扮，就会有人喜欢看。当然了，口味也并非是一成不变的事物。以前，你喜欢成熟风格，以后你可能就喜欢少女风。

评论者分类

从我们的习惯来看，我们会对这些评论者进行一些分类：

• 符号党。“我代码写得不多，你也不要骗我，你这里少了一个分号；Go、JavaScript、Kotlin 就应该写分号”。
• 键盘侠。“怎么做出好的设计，我不知道，但是你是错的。”
• 评论家。“你这写错了，你应该这么写，blabla”，结果：评论家也写不出来。
• 王者型。“你这写错了，我给你看我写的一个示例。”

简单来说，就是能不能设计 + 会不会写：

• 什么也不会：符号党
• 不会设计，不会写：键盘侠
• 会设计，不会写：评论家
• 会设计，也会写：王者型

我并没有想抨击哪一类人的意思，因为从不会到会，就是一个成长的过程，是大部分人要经历的一个过程。

我们非常讨厌键盘侠，因为他/她什么也不会，就会瞎 BB。那么，剩下一个问题是，评论家到底是好还是坏？

评论家的自我修养

我们可以将评论家这个角色的能力，将其他/她评论家角色作为一个对比。就会发现，作为一个合格的代码评论家，她/她应该懂得：

• 什么是好的设计
• 阅读过大量的好代码
• 阅读过大量的糟糕设计
• 知道如何在合适的时候，使用适合的模式
• ……

并且，他/她应该持续不断地：

• 阅读大量的代码，提升自己的眼光和眼力
• 学习不同的语言，了解他们不同的使用模式
• 对设计、发展趋势，持续不断地深入
• 偶尔能写写 demo

但是，你要知道要成为一个合格的评论家很难，因为大多数人：

1. 知道各种设计模式，但是难以在正确的地方用它们。
2. 知道什么是好的设计，但是都用在错误的地方。 往往会做过度的设计
3. 很少花时间阅读别人的代码，因为别人写的代码都是 “屎”。
4. 没有阅读过好的代码。
5. ……

好在，只要多多努力就能成为代码评论家。

如何成为代码评论家？

……

结论

没有代码能力，成为不了评论家。