代码审查关注什么：SOLID 原则
在今天的文章中，我们将更仔细的讨论代码本身的设计，特别检查是否遵循了良好的面向对象设计实践。和我们已经讨论过的其他方面一样，不是所有的团队都会将 SOLID 原则列为最重要的检查项，但是如果你在尝试遵循 SOLID 原则，或者在尝试将你的代码往这方面发展，这里有一些提示可能对你有帮助。
SOLID 是什么？
SOLID 原则是面向对象设计和编程的5个核心原则。本文的目的不是详细讲解 SOLID 原则是什么或者深入讨论为什么你要遵循这些原则，而是指出在代码审查中怎么发现没有遵循这些原则的味道。
SOLID 代表：
单一功能原则（SRP）
在修改一个类时永远都应该只有一个理由
这一点在单次代码审查时可能比较难发现。根据这个规则的定义，作者在修改代码是有（或者应该有）一个理由--解决 bug，添加一个新功能，代码重构。
你需要关注一个类里面哪些方法可能会同时修改，以及哪些方法不会因为其他方法的修改而修改。例如：
通过 Upsource 的两栏差异比较会发现 TweetMonitor 中添加了一个新功能，在一些用户界面的发帖排行榜绘制前面10个发帖者的能力。这看起来是合理的，因为它使用了 onMessage 方法搜集好的数据，但是有迹象表明它破坏了 SRP 原则。OnMessage 和 getTweetMessageFromFullTweet 方法都是关于接收并解析一条 Twitter 消息，然而 draw 方法为了UI展示重新获取相关数据。
代码审查者应该标记出这两个职责，并且之后和作者一起讨论一个更好的方式来分割这两个功能：也许可以将 Twitter 字符串的解析移到一个不同的类中；或者创建一个不同的类来负责提供发帖排行榜。
开闭原则（OCP）
软件实体（类，模块，函数等等）应该对扩展开放，但是对修改封闭。
作为审查者，如果发现通过一系列的 if 语句来检查类型，你应该意识到破坏了开闭原则。
这段代码依赖于许多具体的实现细节：数据库连接 JDBC，数据库特定的 SQL，数据库的结构等等。这些代码应该出现在系统的某一个地方，但是不应该出现在这里，也不应该出现在不需要了解数据库细节的方法中。更好的方法是提取出一个 DAO 或者使用 Repository 模式，然后将 DAO 或者 repository 注入到这个 services。
总结
这些代码“味道”可能表示一个或者多个 SOLID 原则被破坏：
- 很长的
if/else语句 - 强制转换到子类型
- 很多公共方法
- 实现了抛出
UnsupportedOperationException的方法
与所有设计问题一样，在遵循这些原则之间找到平衡，并根据你的团队的喜好做出调整。 但是，如果在代码审查中看到复杂的代码，你可能会发现应用这些原则之一会找到一个更简单，更易于理解的解决方案。
