The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:
有许多工具可用于控制Java代码的质量，包括Checkstyle、PMD、FindBugs、Cobertura等。它们通常用于分析代码质量并生成一些漂亮的报告。这些报告经常由持续集成服务器（如Jenkins）发布。
Qulice进一步提升了这些工具的功能。它将一些质量检查器集合起来，并将它们配置为最严格的模式，如果其中任何一个失败，将中断构建过程。
说真的。Checkstyle中有130多个检查项，PMD中有400多个规则，FindBugs中有400多个缺陷。它们都应该说：“是的，我们喜欢你的代码。”否则，你的构建过程将无法通过。
你觉得怎么样？对你来说，如果你的代码仅违反了900个检查中的一个就被拒绝，这会方便吗？对团队来说，强制开发人员如此关注代码质量会提高生产效率吗？
如果您加入我们的团队作为Java开发人员，您将在分支中开发您的代码，然后Rultor将合并您的更改到master分支。但在实际合并之前，Rultor将运行一个自动化构建脚本，以确保您的分支不会破坏它。
作为静态分析工具，Qulice只是自动构建脚本中的一部分。它实际上是一个Maven插件，我们使用Maven 3x自动化Java构建。因此，如果您的更改违反了Qulice的规则，您的整个分支将被拒绝。
您的第一反应—我已经见过很多次—可能会是负面的。您可能会因此感到沮丧而立即离开项目。您可能会说出这样的话（我引用了真实的故事）：
与其浪费时间在这些错误放置的逗号和大括号上，我们最好是开发新功能！
我一生中已经完成了许多成功的项目，从未听说过这种荒谬的质量检查…
这种第一反应是很合乎逻辑的。我见过很多人在开源和商业项目中都说过类似的话。不仅在Java中，还有在PHP中（使用phpcs和phpmd）以及Ruby中（使用rubocop和simplecov）。我该如何回答呢？请继续阅读。
根据我的经验，我认为一个人越早适应Qulice的严格质量控制，他/她就能越快地学习和成长；他/她也会成为更好的程序员；他/她就能与我们和我们的项目一同向前迈进。
基于这个经验，我建议所有新成员要有耐心，并且试着适应这种质量的新方法。几周后，那些坚持下来的人会开始理解为什么这种方法对于项目和作为Java工程师的他们是有益的。
为什么有益呢？请继续阅读。
让我们以一条简单的规则作为例子。这里有一段Java代码，Qulice会对其进行抱怨（由于Checkstyle中的DesignForExtension规则）。
这段代码有什么问题？name() 方法不是最终方法，可以被扩展 Employee 类的子类重写。从设计角度来说，这是错误的，因为子类被允许破坏父类，重写其方法。
正确的设计是什么？就是这个：
现在，该方法已经最终确定，子类无法覆盖它。这是一种更安全的设计（根据Checkstyle，我也同意）。
那么，假设我们将此规则应用于项目中的所有类。这样做对项目有什么好处？与没有此限制的其他项目相比，它能够向其成员（程序员）承诺更高质量的工作，主要原因是：
更少的隐藏技巧—设计的可预测性增加，可以更好地暴露出错误和技巧。源代码的标准化使其统一。这意味着更容易阅读和发现问题。
行业标准—决定采用这种设计是由Checkstyle决定的，而不是由项目架构师决定的。对于我作为一个项目开发者来说，这意味着我正在遵循行业标准。这使得项目（及其领导者）更加受尊重。
学习—我敢打赌，阅读这篇文章的大多数人都不知道上面解释的设计规则。仅仅通过阅读这篇文章，你学到了新知识。想象一下，当你的代码符合Qulice的所有900条规则（Checkstyle + PMD + FindBugs）后，你可以学到多少东西。
关于学习的观点引领我们到了最后，也是最重要的一个要讨论的思想。
作为一名程序员，我希望你已经意识到在一个要求质量如Qulice那样高的项目中工作可以得到什么。是的，你将学习很多关于编写优质Java代码的新知识。
除此之外，我实际上要说的是，每写一行新代码，你都在得到免费的课程。而且这位老师是由数百名Java开发人员在过去十年中编写的软件。Qulice只是将这些软件工具整合在一起。说实话，真正的质量检查和规则的作者是开发人员们。
那么，我对那些抱怨质量规则太严格的人说什么呢？我说：“你是想学习和提高，还是只想拿钱就走？”
附注：你可以使用我的IntelliJ设置文件，它们相当严格，可以在Qulice开始抱怨之前帮助你清理代码。
Translated by ChatGPT gpt-3.5-turbo/42 on 2023-12-16 at 15:41
