如何做 Code Review(读后感)

前言

最近在看一篇文章《如何做 Code Review》原文，文章里面大佬的一些总结很经典很明了，值得我学习和借鉴。通过几个知识部分做一下总结。

什么是Code Review

Code Review是代码评审,代码评审也称代码复查，是指通过阅读代码来检查源代码与编码标准的符合性以及代码质量的活动。

Keep It Simple Stuped!（保持简单,并且一目了然）

减少代码重复使用，但是这个在我看来是高级开发人员才能考虑，对于初级者来说，在有限的时间内，先解决问题，然后在没有问题的情况下，寻找一个最佳的解决办法替换，所以这是一个不断学习的过程，学好本领之后才能做到让代码简洁明了。

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

在一个整体中，无论自己的能力职责多大，都要体现出自己的价值，参与其中。所以组合会更好的让我们每一个人都能去找到合适自己的支撑点，然后共同支撑这个“房子”。

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

奥卡姆剃刀原理（新学到一个原理，觉得精辟）

这个原理称为“如无必要，勿增实体”，即“简单有效原理”。避重趋轻，避繁逐简，以简御繁，避虚就实。
奥卡姆说: 「如无必要,勿增实体。」「勿增实体」被成为奥卡姆提到原则。奥卡姆剃刀是对未知事实由选出概率最大的一种思者方法他是方法 不是直理 他不保证100%正确,但是可以保证在现有已知事实下，不做无谓思考。

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

自己要对自己写的代码负责，无论是看还是有需求给其他程序员看，或者给没有代码基础的人看，如果没有阴暗的角落和隐藏的深度，就要提高质量清晰明了。

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

在通类的代码和结构，不要标新立异独出心裁。如果在开发过程中出现了问题，会让除你之外的人浪费时间去重新理解你的代码，耗时耗力。（所以最好让不同事物有明显区别，而不要看起来几乎一模一样。 – Henry Spencer）

原则 11 缄默原则: 如果一个程序没什么好说的，就沉默

相信自己，在程序没有问题的情况下，不要把时间浪费在这个程序上，要审时多度，在没问题的情况下做些其他有益的事，一旦发生问题则快速定位分析解决问题。

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

我们都知道灭火的最佳时期是初起阶段，所以程序出现问题异常也是同理，及时通知开发和维护人员，快速精准解决才能避免“大事故”发生。

总结

文章写得很好，毕竟我还没有达到那个高度，所以觉得大佬说的都特别有道理，很多地方是值得我在接下来学习和注意的，但是这是需要一个过程的，只有在我有这个基础之上，才能做到质的东西，所以多学多实践，才是硬道理。