watchdog代码_保持代码干净：WatchDog和SpotTheBug方法

watchdog代码

在讨论“ WatchDog和SpotTheBug方法 ”之前，让我简要介绍一下这方面的需求。

三个月前，我被要求为使用所有最新和最先进技术的新应用程序编写核心基础结构代码。
我已经编写了基础结构代码并实现了2个用例，以演示哪个逻辑应该进入哪一层并且代码看起来不错（对我而言是:-)）。 然后我进入我的主要项目，听说我设计的项目（从现在开始，我将其称为ProjectA）进展顺利。

上周3个月后，ProjectA的一名开发人员来找我，帮助他解决了一些JAXB编组问题。 然后，我将最新的代码导入eclipse中，并开始研究该问题，而我对混乱的代码感到震惊。 首先，我解决了这个问题，开始研究整个代码，我无语了。 在短短的三个月内，代码如何变得如此混乱。

• 几乎每个服务类都有日期格式化方法（使用不同名称复制和粘贴）
• 有具有58个String属性和setters / getters的Domain类。 客户类包含homeAddressLine1，homeAddressLine2，homeCity ..，officeAddrLine1，officeAddrLine2，officeCity…没有地址类。
• 在某些类中，使用JAXB完成了XML到Java的封送处理，在其他一些类中，则使用XStream进行了封送，在其他一些地方，即使存在具有许多XML封送处理方法的核心实用程序模块，也手动构造了XML字符串。
• 在某些类中，使用SLF4J Logger，而在某些地方，使用Log4J Logger。

而这样的例子不胜枚举…

那么到底发生了什么？ 问题出在哪里？

我们以保证代码干净和高度可维护/可增强的方式开始了这个项目。 但是现在它处于最坏的状态。

如果代码是遗留代码并且很混乱，那是可以理解的，因为今天的最新处理方式已成为明天的遗留方法，而将应用程序配置外部化为XML的糟糕方法又回到了过去，现在变成了带有新注释的XML地狱。 我非常确定，几年后，我们将看到“使用SomeNew Gr8 Way摆脱注释地狱”。

但就我而言，这只是3个月的项目。

当我考虑为什么代码变得如此混乱的原因时，我最终会遇到无休止的原因列表：

• 时间紧迫
• 不称职的开发人员
• 不使用代码质量检查工具
• 没有代码评论
• 没有时间清理凌乱的代码

等

因此，无论您的代码为何会在一段时间后变得混乱，尤其是当有更多的人正在处理该项目时。

最糟糕的是你不能责怪任何人。 开发人员会说，由于我分配了高优先级任务，因此我没有时间清理代码。 技术负责人忙于分析新任务并将其分配给开发人员。
经理忙于汇总团队的任务状态报告，以使老板满意。 架构师忙于为新的第三方集成服务设计新的模块。 质量检查人员正忙于为即将发布的版本准备/执行其测试用例。

那么清理代码是谁的责任呢？ 或以其他方式，即使在上述所有“忙碌”情况下，如何保持代码干净？

在解释“ WatchDog和SpotTheBug方法”的工作原理之前，让我告诉您另一个故事。

3年前，我从事了一个银行项目，该项目到目前为止我还从未见过设计精良，组织合理且编写良好的代码。 该项目开始于将近10年，但代码质量仍然很好。 这怎么可能？

唯一的原因是，如果任何开发人员使用诸如添加重复的实用程序方法之类的错误代码来检入代码，则开发人员将在4小时内收到来自GUY的电子邮件，询问其解释，当该实用程序方法添加该方法时，需要添加该方法在核心实用程序模块中已经可用。 如果没有正当理由，开发人员必须打开缺陷标题中带有“ Cleaning Bad Code”的新缺陷，将缺陷分配给他自己并更改代码，并应尽快检入文件。

通过此过程，我们团队中的每个团队成员都习惯于在进入存储库之前对代码进行三重检查。

我认为这是保持代码清洁的最佳方法。 到目前为止，您可能已经对“ WatchDog”的含义有所了解。 是的，我称GUY为WatchDog。 首先，很抱歉称呼“狗”这样重要的角色，但它更好地描述了那个家伙会做什么。 看到一些错误的代码，它将立即吠叫。

需要看门狗：

如前所述，团队中的每个人都可能忙于他们的高优先级任务。 他们可能无法花时间清理代码。 同样从业务的角度来看，添加新的客户要求的功能可能比清除代码更重要。 即使有时Business知道从长远来看，如果他们不清理混乱情况，整个应用程序就有可能变得无法维护，他们将不得不首先使用一些快速的新功能来满足客户的需求，并且会选择短期利益。

我们有许多质量检查工具，例如PMD，FindBugs，Sonar。 但是这些工具是否建议创建一个Address类，而不是像我上面提到的那样针对不同类型的地址重复所有地址属性。 这些工具是否建议您在整个项目中使用相同的xml编组库。 据我所知，他们不会。

因此，如果您真的希望您的软件/产品能够随着时间的流逝而持续下去，我建议您租用专门的WatchDog（人类）。

WatchDog的主要职责是：

• 不断检查代码气味，重复方法，违反代码标准，并将报告发送给整个团队。
• 如果可能，请指出要使用的现有实用程序，而不要创建重复的方法。
• 检查设计违规情况，例如在错误的地方（例如Web层）建立数据库连接或事务管理代码。
• 检查模块之间的循环依赖关系。
• 探索并建议建立良好且经过测试的通用库，例如​​apache commons-*。jars，Google Guava，而不是编写自行开发的解决方案（我觉得使用Guava Cache而不是编写自行编写的Cache Management更好，但是使用YMMV）

到目前为止，如果WatchDog表现出色，那就很好。 如果WatchDog本身效率低下怎么办？ 如果WatchDog技能不足以执行其工作怎么办？ 谁来检查WatchDog是否做得好？ 这是“ SpotTheBug”程序的图片。

'SpotTheBug'

我坚信拥有一种友好的文化，以鼓励开发人员提出改善软件的想法。

每个团队成员每个礼拜都要提出3分以改善/清除代码。 它们可以是：错误代码识别，更好的设计，新功能等。

他不仅要说代码是不好的代码，还必须说明为什么自己觉得代码不好，如何以更好的方式重写代码，以及会产生什么影响。

基于这些点的有效性，应该给开发人员一些价值点，并且在绩效评估中应该绝对考虑这些点（应该有一些动机权：-）。

有了WatchDog和SpotTheBug程序，如果团队可以在WatchDog捕获到错误代码之前就识别出错误代码，那么它将成为WatchDog的一个诱人之处。 如果WatchDog持续出现负值，那么该是评估WatchDog本身有效性的时候了。

通过使用此WatchDog和SpotTheBug方法，并结合正确使用代码质量检查工具（FindBugs，PMD，Sonar），我们可以确保代码在最大程度上干净。

参考： 保持代码干净：我们的JCG合作伙伴 Siva Reddy在“ 我的实验”技术博客上的 WatchDog和SpotTheBug方法 。

翻译自: https://www.javacodegeeks.com/2012/08/keep-code-clean-watchdog-spotthebug.html

watchdog代码