什么是好的代码-代码Review要点

自描述

命名恰当规范，看名字就知道意思。包括包、类、方法、变量等等，而不是靠注释去理解。当你须要注释才能描述清楚你想干吗，请思考一下，可否从命名就说清楚？除非是在不行，不然不要依赖注释。

注释的一个坏处是，你不能保证注释和代码是同步的。当你因为某些缘由改了代码，而没有修改注释，这时候注释是误导人的，还不如没有。

注释会带来代码的噪音。遍及代码里的注释，让你没法抓住代码要点，而是要费劲去阅读注释。

简单

简单容易理解的代码就是短的代码。有有限的行数（方法低于10行是个不错的标准，低于7行是个更好的标准，再低可能不容易作到），较少的缩进层次（两层之内，最多不高于3层）。

过长的方法多是由于你违反了单一职责原则。试着对方法进行重构，对方法里的代码进行分层。每一个方法只干一件事儿，减小代码的行数。

过大的类也是一种复杂。试着重构，将类的职责分离出来，保持类的单一职责。对于复杂逻辑，尝试用经常使用设计模式，如类工厂等方法将一些逻辑分布到其余类中。

容易修改

当你把相同缘由相同时间变化的放到一块儿，不一样缘由不一样时间变化的分开，代码就容易修改。从纵向上，把UI、业务逻辑、数据库访问等分开，高层的业务逻辑和底层的UI数据库解耦；从横向上，不一样的UseCase分开为不一样的模块。这样代码会更容易修改。

面向对象赋予咱们的利器：多态。进而实现依赖反转。从而让各个层次能够很方便用抽象解耦，一个层内部的修改，不会影响到其余层。

Open-Close原则，面向扩展开放，面向修改关闭。在增长新功能的时候，不须要或者极少须要修改原来代码。这样才能避免引入新的Bug。

容易测试

依赖简单的、职责单一的代码就容易测试。轻易Mock少数接口（甚至不须要），就能够完成对业务逻辑的单元测试。当你发现你的代码很难测试，极有多是你代码作了太多的事儿，或者没有好好隐藏内部实现，致使调用者很是复杂。

若是你的对外依赖不容易经过Mock替代进行测试，说明你的代码违反了里氏替换原则。从新设计其余依赖，用接口进行隔离。

高效的

采用恰当的方法，是系统可以高效运行。好比没必要要的打包解包、无谓的循环、频繁的锁竞争。固然对效率的优化首先要考虑代码前面几个原则，除非很是必要，不要以牺牲可读性、可测试等特性为代价。