自我保护机制
我曾经参加过有关“前端开发”主题的演示。 该演讲由一位高级开发人员举行，他在某个时候开始吹嘘他和他的团队在他们的项目中使用的很酷的约定，特别是CSS文件的命名和结构。 然后，他还提到了有关其JavaScript约定的内容。
在谈话的最后，我问那个家伙他们的CI / CD管道是什么，构建命令的样子以及他们是否实际上自动执行了这些规则。 整个房间都在笑，包括他在内。 之后，他说了类似的话：“我们依靠我们的工程师和审查代码的能力”。 我很惊讶-我期待一个la脚的答案，但我不明白为什么每个人都笑。
真正令人难过的是，直到今天，当我建议使用Quality Gates自动化时，我收到了类似的React 。 在这篇文章中，让我阐述一下这个主意，也许它似乎不再有趣了。
自动化质量门意味着要对您的团队在项目中使用的规则和约定进行某种形式的自动化检查。 当涉及到CI / CD管道时，天空是无限的，但是我了解到，实现这种自动化的最有效方法是通过您的构建工具。
构建项目通常意味着获取依赖关系，编译，运行测试和打包。 但是，我们可以在开始时再增加一个步骤：代码分析。 在Java中，有一些流行的代码分析器： Checkstyle ， PMD或qulice （如果您真的想受苦）。 我在所有项目中都使用Checkstyle。
关键是配置您的代码分析器以检查所有约定，甚至体系结构规则。 违反规则时，构建应失败。 您将没有积压的旧任务来修复“那些红色的Jenkins作业” –不会有积压的原因仅仅是因为您甚至不得不将更改合并到master分支之前就不得不纠正错误。
例如，在我的项目中，我有一些规则，从诸如命名或缩进之类的修饰问题到诸如“类是抽象的或最终的”或“所有类型的所有变量都应是最终的”之类的建筑规则。
我听到的关于这种情况的最常见的抱怨是沮丧。 会令人沮丧吗？ 当然可以，但是只有在您学习了一些纪律之后才可以。 相信我，我说的话，您会比您想像的更快地习惯它，并且您会学会欣赏它。 在某些时候，不得不学习除习惯之外的其他约定甚至变得很烦。
请记住，这些检查必须被阻止！ 您还可以通过诸如SonarQube之类的外部工具来分析代码，但是此类管道通常不会阻塞，因此团队只会积压从未完成的任务。 您最后一次去Sonar修复一些投诉是什么时候？ 我的猜测是：永远不会。
现在，由于我们正在谈论自我保护项目，因此我还想做另一件事：我让项目打开自己的错误报告。 通常，当您捕获到异常时，只需将其记录下来，并希望公司中的某人拥有一个日志分析器，该分析器足够聪明以处理每个记录的错误。 然后，希望有人真正打扰验证日志。
为什么不立即打开车票？ 一旦发现异常，就可以使用问题跟踪程序的RESTful API打开故障单。 Github，GitLab或Jira都提供了此类API。 当然，这是一个体系结构问题，您不能仅在整个应用程序中的任何地方进行HTTP调用。 但是，如果您的代码是面向对象的，则应该能够轻松实现此目标。
就我而言，该项目是一个聊天机器人，其中最高的抽象是“动作”。 无论聊天机器人做什么，我们都将其称为“动作”。 现在， Action是一个Java接口，具有一个主要实现和一个称为VigilantAction的装饰器。 “警惕”动作只是简单地在try/catch块中调用原始动作，并打开一个带有捕获到的异常的Github凭单。 为了与Github进行交互，我使用了这个库。
现在写这个，我有个主意：我们应该有一个Log4J或slf4J插件：当调用.error(...)方法时，该插件会自动在Github或其他跟踪器上打开票证。 或者，更优雅的是，可以在我们的应用程序服务器或运行时中实现这种功能：如果任何异常中断了应用程序并到达了服务器日志，我们应该自动打开一个问题。
最后，我希望我的观点足够清楚，希望您不再再依赖约定了。 最好让项目保护自己。 顺便说一句，这并不是说代码审查是没有用的！ 代码审查仍然非常重要，它变得更加容易。
翻译自: //02/self-protecting-projects.html
自我保护机制
如果觉得《自我保护机制_自我保护项目》对你有帮助，请点赞、收藏，并留下你的观点哦！
