代码review的"色香味"

上个月下旬有个review的事情，持续了很久吧，当时就想到了这个主题。今天有时间来写写！

 

味------功能实现或者异常情况的处理。

（框架）流程是否合理。

是否充分考虑各种异常分支，即容错性。

关键参数是否有充分的依据。

 

香------性能优化和可维护性。

性能优化会更侧重一些细节的设计。

可维护性我觉得更侧重日志的设计。

 

色------可读性。

规范和注释等等。

风格是否错路有致。

 

 

代码的review应该从这三方面着手！

 

从上到下，从最基本最重要开始。

但是给人的第一印象往往是从“色”开始。

 

如果看上去，没有“食欲”，写的再好，可能也需要思考半天去理解作者的本意；

而且人的临时记忆是很短暂的，如果没有注释，不出三个月自己都会忘记。

所以我认为注释和文档，其实很多时候是写给自己的；

当然关键时候，拿来交接的。

为了后续工作的交接顺利，未尝不好！

交接也不一定是换工作，也有可能换项目、带徒弟等等。

 

我也碰到有人跟我说，如果代码写的好，就不需要（看）文档和注释！

这里可以分成两方面。

一方面，确实有这样的高手，但是这些高手一般只是在写开源库的时候；

如果是企业的员工，除了初创阶段，后期应该也是有需要的。

否则，你看哪个著名的软件公司没有出各种语言编码规范？

而且这些高手，代码确实写的好，好在错落有致！

看着不累，层次分明。

另一方面，我认为这是一种借口或者托词或者狂妄，不愿意去改变自己思维而已。

 

还有，喜欢咬文嚼字的，我觉得讨论起来蛮累的！

i++ 和 ++i的性能区别？

定义不当，多了一次io。

想想就累，现在一块小芯片性能都很强大了，这些让我不知道如何说好。

 

当然最让人累的就是代码逻辑非常不清晰的，

while多个（大于2）嵌套，结构体多层嵌套；再混合！

讨论会更累，这是人的性格使然，如果碰到这样的（人），只能通过测试来约束了！

 

最后，回到的“色香”。

除了最重要的流程和设计之外，这里的细节和严谨必须重视！

常见的是前后文，或者说上下文。

每一处关键的地方、每一次改动，都要留意其上下文！

切记！

切莫可大意，或者自以为是！