我记得我的一位同事在上一份工作中反复念叨着“面向接口编程，而不是面向实现”。

这听起来像是一个好建议，但对我来说有点抽象，因为在PHP中变量没有类型。变量的值有类型，但是内存中对象的类型从来不是接口——它总是一个类。

我认为，虽然我可以在编码时尽量记住一个接口，但唯一真正的测试是在运行代码时代码是否工作，这时PHP将允许我调用该类上可用的任何函数。它不知道我在编程时脑子里想的是什么界面。

当我从没有使用任何插件的Vim切换到PHPStorm时，我才明白了这一点。一旦你使用PHPStorm，变量确实有类型，不是在PHP引擎中，而是在PHPStorm对文件的理解中。现在变量可以有接口类型，如果我试图调用接口上不存在的函数，PHPStorm会大声抱怨。换句话说，我第一次在PHP中使用静态分析，并接触到静态类型，除了PHP的动态类型。

但即使使用PhpStorm，仍然有几次我在变量中犯了拼写错误，没有注意到来自PhpStorm的抱怨并找到消息。致命错误:调用非对象的成员函数’，或者犯了其他一些本可以被静态检查出来的错误，而这些错误后来才被发现。

因此，虽然我认为一个进行静态分析的IDE非常有价值，但我认为它还不够。有几个可用于PHP的独立静态分析工具，我们一直在使用MyBuilder诗篇，来自我们的IAC姐妹公司Vimeo我们今年开始的一个新项目的代码，以及我们的内部资金库这是新项目所依赖的。

诗篇是由马修·布朗以及Vimeo的同事帮助他们处理现有的大型代码库．每当您向现有的代码库引入新的质量检查工具时，很可能会发现许多值得抱怨的地方。因为空的代码库没有bug¹，一个新项目是介绍《诗篇》的好机会。

作为一个团队，我们希望每个拉请求在我们合并之前都有一个通过的Jenkins构建，而诗篇会确保我们在发现任何错误时不会得到一个通过的构建。就我个人而言，我发现这让我更舒服知道有问题有很多种我不会不小心添加到我们的代码库中。

当然，静态分析不能代替代码审查或测试，但我认为它很好地补充了这两者。检查甚至没有通过单元测试的代码没有什么意义，我建议检查或运行静态分析器已经发现问题的代码也没有什么意义。一旦您知道测试通过了，您就不必在审查时质疑这一点，相反，您可以将精力花在更有趣的问题上，比如对代码的更改是否有用，以及是否便于理解和将来更改。

类似地，一旦您知道静态分析已经通过，并且了解它可以检查什么类型的东西，您就不必质疑类型是否准确，相反，您应该能够找到更有用的问题来询问。

Psalm将从文档块和普通PHP类型声明中读取类型，并在文档块中进行理解几种类型的类型PHP本身(还)不理解的，包括联合、泛型、类对象数组等。当我们开始在前端使用Typescript时，在PHP中拥有一个更复杂的类型系统也是非常受欢迎的。

当我习惯了Psalm的类型系统后，我发现自己越来越愿意依赖它，让它代替运行时的一些检查——为什么要检查静态分析认为不会发生的事情呢?这里有一个锁定的风险，因为一旦代码库开始依赖于静态分析，改变它而不运行分析就会变得危险，但我认为有时在诗篇中接受这种风险是值得的。

例如，我们有一个依赖于Symfony的UserProviderInterface的类，还有一个实现它的类。自dockblock UserProviderInterface # loadUserByUsername它返回一个用户界面对象，我很高兴在我们的代码中删除一个null返回值的检查，相信Psalm不会允许我们从我们的实现返回null。

Psalm发展迅速，我认为它很快就会在PHP社区中广为人知，这在很大程度上要归功于Marco Pivetta的工作Ocramius最近一直在做推广。教义集合是最近带注释的对于诗篇的泛型类型信息，Ocramius已经发布了一个工具，供库作者在项目的安装中自动运行诗篇阻止人们错误地使用它们，塞巴斯蒂安·伯格曼发布了一份版本的PHPUnit)加上注释，使《诗篇》更有用。我也向jms/serializer添加泛型类型注释,贡献一些改进诗篇。

因此，我强烈建议在构建管道中添加静态分析工具，虽然我还没有尝试其他选择，但诗篇似乎是一个不错的选择。你可以在浏览器中测试它，并将其添加到您的构建可能像这样简单:

＄作曲家要求——开发vimeo /诗篇＄/供应商/ bin /诗篇——初始化＄回声”。/供应商/ bin /诗篇”>>test.sh