Blog

Blog

PHODAL

代码评论家

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

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

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

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

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

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

评论者分类

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

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

简单来说,就是能不能设计 + 会不会写:

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

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

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

评论家的自我修养

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

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

并且,他/她应该持续不断地:

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

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

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

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

如何成为代码评论家?

……

结论

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


或许您还需要下面的文章:

关于我

Github: @phodal     微博:@phodal     知乎:@phodal    

微信公众号(Phodal)

围观我的Github Idea墙, 也许,你会遇到心仪的项目

QQ技术交流群: 321689806

新书《全栈应用开发:精益实践》

这不是一本深入前端、后台、运维、设计、分析等各个领域的书籍。本书以实践的方式,将这一系列的领域及理论知识结合到一起,来帮助读者构建全栈Web 开发的知识体系,并辅以精益及敏捷的思想,来一步步开发Web 应用:从创建一个UI 原型到编写出静态的前端页面;从静态的前端页面到带后台的应用,并部署应用;从Web 后台开发API 到开发移动Web 应用。在这个过程中,我们还将介绍一些相辅相成的步骤:使用构建系统来加速Web 应用的开发;为应用添加数据分析工具来改进产品;使用分析工具来改善应用的性能;通过自动化部署来加快上线流程;从而帮助读者开发出一个真正可用的全栈 Web 应用。同时,我们也将帮助读者把这些步骤应用到现有的系统上,改进现有系统的开发流程。

comment

Feeds

RSS / Atom

最近文章

关于作者

Phodal Huang

Developer, Consultant, Writer, Designer

ThoughtWorks 高级咨询师

工程师 / 咨询师 / 作家 / 设计学徒

开源深度爱好者

出版有《前端架构:从入门到微前端》、《自己动手设计物联网》、《全栈应用开发:精益实践》

联系我: h@phodal.com

微信公众号: 与我沟通

标签