如何做Code Review——读后感

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

最近阅读到这篇文章，觉得不错，就仔细阅读理解并做了笔记

为什么要做Code Review!

• riview过程中做到落地沟通，在实际问题中产生思考的碰撞，改进自己当前的实践方式和实践中的代码细节。
• 普通工程师的进化之路，就是不断打磨最佳实践方法论、落地细节

代码变坏的根源

• 重复的代码
  在前端开发中，常遇到代码重复开发的问题，遇到可复用的代码，要有效地抽离出来，做成一个小插件、工具。否则就苦逼了，就是修改一个小小的属性，都需要一一进行修改，想想都累。
• 早期有效的决策不再有效
  在写第一版代码出来的时候，是没有太大的问题的，但是在后续的需求更新和迭代中或者代码有问题时，再加新代码的同学怎么加，是修改原来的，还是重新写；所以在写代码的初期就应该考虑代码的可用性和延展性。
• 过早的优化
  过早指的不是在开发过程的早期，而是在还没弄清楚需求未来的变化的走向的时候。你的优化不仅可能导致你无法很好地实现新的需求，而且你对优化的预期的猜测有可能还是错的，导致实际上你除了把代码变复杂以外什么都没得到。
  没有全面的规划，就容易拘泥于细节。对于需求分析不够清晰，则往往会制造许多南辕北辙的废代码。
  不要盲目的进行优化，当你清楚需求未来的变化的走向时再去优化，正所谓“不见兔子不撒鹰”。
• 对合理性没有苛求
  命名规范合理，语义表达清晰易懂，逻辑层次清晰，用最直白的方式表达最简单原始的意图。
• 总是面向对象/总喜欢封装
  bug 和性能问题，常常就出现在，你用了错误的用法去使用一个封装好的函数。想要确认任何细节，都要把多个层次的代码都通读了，没有什么封装性可言。
• 根本没有设计
  设计是很重要的，没有设计毁的不仅是这个系统，也毁灭了接手自己代码的人。

必须形而上的思考

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

model 设计

model 设计，是形而上思考中的一个方面，一个特别重要的方面。在自己的 coding/code review 中，站在巨人的肩膀上去思考。不重复地发现经典力学，而是往相对论挺进。

UNIX 设计哲学

工程和设计的每个分支都有自己的技术文化。在大多数工程领域中，就一个专业人员的素养组成来说，有些不成文的行业素养具有与标准手册及教科书同等重要的地位(并且随着专业人员经验的日积月累，这些经验常常会比书本更重要)。资深工程师们在工作中会积累大量的隐性知识，他们用类似禅宗’教外别传’的方式，通过言传身教传授给后辈。软件工程算是此规则的一个例外：技术变革如此之快，软件环境日新月异，软件技术文化暂如朝露。然而，例外之中也有例外。确有极少数软件技术被证明经久耐用，足以演进为强势的技术文化、有鲜明特色的艺术和世代相传的设计哲学。 ----《UNIX 编程艺术》

常见原则：

Keep It Simple Stuped!（KISS原则）

• ”把一个事情做出来容易，把事情用最简单有效的方法做出来，是一个很难的事情。”
• 简单不是容易做到的，需要大家在不断的时间和 code review 过程中去积累思考，pk 中触发思考，交流中总结思考，才能做得愈发地好，接近’大道至简’。

作为初级开发人员来说，能做到在规定的时间内完成需求、解决问题，然后在后续代码迭代中找到更加简洁并且行之有效的代码去替换原来的，这需要漫长的积累知识的过程，不可一蹴而就。

原则 3 组合原则: 设计时考虑拼接组合

• Unix提倡采用简单、文本化、面向流、设备无关的格式。传统Unix是将一个简单的文本流输入处理为一个简单的文本流输出。如果不使用简单的文本流就极其难以衔接。Unix中文本流之于工具，就如同面向对象环境中的消息之于对象。

各种不同的组合，简单，却又满足了各种需求，灵活多变，要实现一个插件，不需要事先掌握一个庞大的体系。将代码插件化、工具化，减少重复代码。

原则 6 吝啬原则: 除非确无它法, 不要编写庞大的程序

• 代码越多，越难维护，难调整。我们对于代码，要吝啬。能把系统做小，就不要做大。
• 能小做的事情就小做，寻求通用化，通过 duck interface(甚至多进程，用于隔离能力的多线程)把模块、能力隔离开，时刻想着删减代码量，才能保持代码的可维护性和面对未来的需求、架构，调整自身的活力。客户端代码，UI 渲染模块可以复杂吊炸天，非 UI 部分应该追求最简单，能力接口化，可替换、重组合能力强。
• 优点：利于理解和学习、利于维护、更易于和其他工具结合、消耗更少的资源

原则 7 透明性原则: 设计要可见，以便审查和调试

我们要写好程序，减少 bug，就要增强自己对代码的控制力。写的函数，必须具备很高的透明性，使用通俗易懂的函数分组分层方式，使自己的代码让人一看就懂；如果问题比较复杂，要准备好对应的文档资料。

原则 10 通俗原则: 接口设计避免标新立异

在通类的代码和结构，不要标新立异独出心裁。设计过程中应该按照用户最可能熟悉的同样功能的接口和相似的程序来进行建模。

原则 11 缄默原则: 如果一个程序没什么好说的，就沉默
若程序没有什么特别之处可讲，就选择保持沉默。一切从简是Unix的优良传统。
不要胡乱打印log，如果你的程序’发声’了，那么它抛出的信息就一定要有效 !

原则 12 补救原则: 出现异常时，马上退出并给出足够错误信息

• 不懂得区分程序错误和逻辑错误,对代码的可维护性是毁灭性的破坏.
• 在火苗出现时扑灭火灾是最好的扑灭火灾的方式。当然，更有效的方式是全面自动化测试的预防。

Rob Pike, 最伟大的C 语言大师之一, 在《Notes on C Programming》中从另一个稍微不同的角度表述了Unix 的哲学：

• 原则1: 你无法断定程序会在什么地方耗费运行时间。瓶颈经常出现在想不到的地方，所以别急于胡乱找个地方改代码，除非你已经证实那儿就是瓶颈所在。
• 原则2：估量。在你没对代码进行估量，特别是没找到最耗时的那部分之前，别去优化速度。
• 原则3: 花哨的算法在n 很小时通常很慢，而n 通常很小。花哨算法的常数复杂度很大。除非你确定n 总是很大，否则不要用花哨算法（即使n 很大，也优先考虑原则2）。
• 原则4：花哨的算法比简单算法更容易出bug、更难实现。尽量使用简单的算法配合简单的数据结构。
• 原则5：数据压倒一切。如果已经选择了正确的数据结构并且把一切都组织得井井有条，正确的算法也就不言自明。编程的核心是数据结构，而不是算法6。
• 原则6：没有原则6。

总结：

---

Code Review确实是一项很有意义的事情，Code Review对于代码作者，审查人以及团队都是有益的，经常阅读自己代码并修改重构自己代码的习惯，因为编写者都会觉得自己代码写的很完美，这是正常的现象。不过如果你过段时间再次看自己当初以为写的很牛的代码可以发现好多吐槽点，好多可以优化重构的地方，保持这种经常阅读自己代码并重构的习惯可以提高自己的代码能力。也可以经常阅读别人的代码看别人的代码风格有何借鉴之处，正所谓三人行必有吾师。