关于Code Review的文章读后感

前言

文章链接：万字详文告诉你如何做 Code Review！

最近看了这篇关于Code Review的文章，进行一些总结，记录一下体会。

为什么要做Code Review

代码可以呈现出一个程序员的思维，是设计理念、原则真正落地的地方，在review中，大家可以真正意义上进行思想的碰撞，互相学习，可以营造出浓厚的工程师交流氛围，使大家都掌握团队中最好的实践方式。像我们这种普通工程师，就是要不断打磨最佳实践方法论、落地细节。

什么样的代码是坏的代码

在review的过程中，总会有一些遇到坏的代码的时候，在文章中列举了一下几种：

• 重复的代码
  就前端而言，项目的组件化确实是很关键的一部分，如果有一些可以复用的地方不抽离成为组件，你有的时候甚至需要在这些重复的代码中一一进行修改，这着实很令人绝望。

• 早期有效的决策不再有效
  一个好的、优秀的代码应该是可扩展的，在写出一个函数时，应该考虑他后续的扩展性。

• 过早的优化
  不要盲目的进行优化，当你清楚需求未来的变化的走向时再去优化，正所谓“不见兔子不撒鹰”。

• 对合理性没有苛求
  对合理性进行严格的要求，如同打地基一样，毕竟你的代码后续是有可能会被修改的。

• 总是面向对象/总喜欢封装
  不要胡乱的进行没有设计的封装，这会对团队协作有很大的破坏，在一个坏的设计下进行迭代，如同地基没有打好，楼只会越建造越趋近崩塌。

• 根本没有设计
  设计是很重要的，你肯定不可以知道个需求就没有计划的埋头瞎干，这对后续的迭代是毁灭性的。

以形而上的方式思考问题

把工程实践中遇到的问题，从问题类型和解法类型，两个角度去归类，总结出一些有限适用的原则，就从点到了面。把诸多总结出的原则，组合应用到自己的项目代码中，就是把多个面结合起来构建了一套立体的最佳实践的方案。

model 设计

model 设计，是我们形而上思考问题的一个方面，我们想要获得这种能力，首先要去看前人的思考，站在前人的肩膀上，再用上自己的通识能力，去进一步思考，这样，我们才可以更好的具备model 拆解/抽象/构建的能力。当我们可以明确的具备思考模型边界、构建模型细节能力时，再对产品的迭代开发就是不停往模型里填内容，而不是推翻重来了。

一些前人总结的原则

• Keep It Simple Stuped
  “大道至简”，一个简单又完美的设计是需要在人与人的交流、碰撞中去慢慢完善改变的，这正是review的好处。
• 组合原则: 设计时考虑拼接组合
  正如前端的工程化、组件化，这种拼接组合的设计理念可以使我们更好的进行复用，更好的进行扩充。
• 吝啬原则: 除非确无它法, 不要编写庞大的程序
  正如前面所言，“大道至简”，能简单就简单，庞大的程序只会带给我们不便的维护体验，一个好的程序应该是可替换、重组合能力强的。
• 透明性原则: 设计要可见，以便审查和调试
  对用户而言，良好的文档有助于提高可显性；对程序员而言，良好的变量和函数名有助于提高可显性。我们要追求合理的函数分组，合理的函数上下级层次，同一层次的代码才会出现在同一个函数中。完备的文档还应该出现在离其代码最近的地方，注释也是一样。
• 通俗原则: 接口设计避免标新立异
  函数名、变量名通俗易懂，不要让人产生错误的认知，因为这往往会导致很严重的后果。
• 缄默原则: 如果一个程序没什么好说的，就沉默
  不要乱打印log，乱七八糟一大排的日志只会影响排查问题，真的需要打印log时，把必要信息给全，让其容易理解，否则一个不知道代表着什么的log还不如不打了呢。我们将用户的注意力视为有限的宝贵资源，程序员自己的注意力也是一样的。
• 补救原则: 出现异常时，马上退出并给出足够错误信息
  对于程序错误 ，我们就必须要严格做到在问题最早出现的位置就把必要的信息搜集起来，高调地告知开发和维护者“我出现异常了，请立即修复我！”

总结

Code Review确实是一项很有意义的事情，可以使我们的团队成员互相进行思想层面的碰撞，帮助新手工程师们养成良好的编码习惯、了解大佬的设计模型、思想，让我们对某些仅仅是了解的道理可以真正意义上的“知其然，知其所以然”，并以这些学习到的思想、模式进行实践，从而达到“知行合一”。