如何说服管理层重新格式化整个Java代码基础是安全的

https://stackoverflow.com/questions/2420174

19-09-2019
|

题

如何向管理层证明所有.java文件的批量重新格式化（将代码符合公司的编码标准）是安全的，并且不会影响功能。

答案必须安抚非技术和技术。

编辑：2010-03-12您中间的技术澄清；重构=仅白空间变化 - 没有“组织进口”或“重新排序会员变量，方法等”。

编辑：2010-03-12 感谢您的许多回复。令我惊讶的是，如此多的读者已经投票赞成Mrjoltcola的回应，因为这只是关于偏执的声明，绝不会对我的问题提出答案。此外，甚至相同的贡献者都发表了评论，重申了这个问题。 Wizzardofodds借调了此观点（但您可能没有阅读所有评论以查看它）。 -jtsampson

编辑：2010-03-12 我会尽快发布自己的答案，尽管约翰·斯基特（John Skeet）的回答是正确的，这是正确的MD5建议（注：G：无需关闭调试）。尽管它仅涵盖技术方面。 -jtsampson

2010-03-15 我在下面添加了自己的答案。对于“安全”的含义，我的意思是，Java代码的功能不会受到影响。对Java编译器的简单研究表明，情况（有一些警告）。 Thos警告是“仅白空间”，并由几张海报指出。但是，这不是您想向Bizops解释的东西。我的目的是引起“如何证明这样做”的答案，我得到了一些很好的答案。

几个人提到了来源控制和随之而来的“乐趣”。我特别没有提到，因为这种情况已经被很好地理解（在我的上下文中）。提防“加油站”效果。请参阅下面的答案。

解决方案

如果只是重新格式化，那就不应该更改编译器的输出。拿起哈希（MD5 重新格式化之前和之后的构建应该足够好 - 如果每个文件都相同，那显然意味着它不会改变行为。无需运行测试等。-如果字节相同的输出是相同的，则很难看到测试将如何开始失败。（当然，仅仅为了展示它可能会有助于进行测试，但是他们不会证明任何相同的二进制文件不会证明任何东西。）

编辑：正如评论中指出的那样，二进制文件包含行号。确保您编译 -g:none 省略调试信息。然后，线路编号更改应该可以 - 但是如果您要更改名称这是一个更严重的变化，这确实可能是一个打破的变化。

我假设你能够重新格式化和重建没有任何人关心 - 仅检查重新格式化的代码回到源控制中，应提出任何案例。我不思考 java类文件中有任何东西可以给出构建日期，等等。但是，如果您的“格式化”改变了字段等的顺序，则能够具有重大影响。

其他提示

在商业环境中，您面临两个挑战。

技术的
政治的

从技术角度来看，改革者是一项成熟的技术。再加上哈希/校验和校验和，只要语言不敏感，您就可以安全地这样做。您还需要确保在没有大叉子等待合并的停机时间内进行。真正的变化将不可能与重新格式化分开，因此可以分开。对于从事叉子工作的任何人来说，合并可能非常困难。最后，我只有在实施完整的测试案例覆盖范围后才这样做。由于原因2 ...

从政治上讲，如果您不知道如何说服管理层，那么您怎么知道这是安全的？更具体地说，这对您来说是安全的。对于控制商店中流程的高级，受信任的开发人员来说，这是一项更容易的工作，但是对于在一个大型，政治，红色的组织中工作的开发人员，您需要确保涵盖所有基地。

我在2010年提出的论点也许太聪明了，但是解析器，改革者，漂亮的打印机只是软件。它们可能具有您的代码库触发的错误，尤其是在C ++的情况下。如果没有任何单位测试，则使用大型代码库，您可能无法100％验证最终结果是相同的。

作为开发人员，我是偏执的，这个想法使我感到不安，但是只要您使用：

源控制
适当的测试覆盖范围

那你还可以。

但是，考虑到这一点：管理层现在意识到，您正在以“大规模变更”的身份进行一百万线项目。重新格式化后，先前未发现的错误会报告。您现在是造成此错误的主要嫌疑人。是否“安全”具有多种含义。这可能对您和您的工作不安全。

这听起来很陈旧，但是几年前，我记得这样的事情。在夜间维护窗口后的第二天，我们有一个错误报告，我只进行了重新配置并重新启动 II 服务器。几天来，故事是我必须搞砸或部署了新代码。没有人直接说过，但是我从一家副总裁那里得到了看来。我们终于将其跟踪到已经在代码中已经被推出的错误，但直到最近QA人员更改了测试案例，但老实说，有些人甚至不记得那部分。他们只是记得第二天来一个新的错误。

编辑：回应 JTSampson的编辑. 。您的问题不是关于如何做的；这是“如何说服管理是安全的”。也许您应该问，而是“安全吗？我的陈述指出了您的问题的讽刺意味，因为您认为它是安全的，而不知道如何安全。我感谢重新格式化的技术方面，但我指出的是，任何非平凡的风险都涉及风险，除非您将合适的人放在上面，否则它可能会陷入困境。这项任务会损害程序员的其他任务，将它们置于几天之内吗？它会与其他编码员的其他不合作的修订冲突吗？源是在修订中吗？是否有任何对空格敏感的嵌入式脚本，例如 Python？任何东西都会产生意外的副作用；对于我们的环境，很难获得一个没有人在分支上工作的时间窗口，而大规模重新格式化将使他们的合并非常丑陋。因此，我对质量形成，手工或自动化的厌恶。

使用务实的方法：

构建应用程序。
保存应用程序。
重新格式化代码。
构建应用程序。
分散二进制。

我会用四个单词。

源控制。单位测试。

好吧，这根本不是安全的，您不太可能说服他们。作为管理大量发展的人，我永远不会在任何依赖收入的商业代码库中考虑。我并不是说编码格式的优势没有优势，但是您的格式不涉及某些代码更改的机会是零。这意味着很少有收益的风险。如果您必须这样做，请在错误修复代码时零碎，不要大受欢迎。作为程序员，这可能是一个很好的决定，但这对他们来说是一个可怕的决定。

我们在这里谈论什么管理？他们是否足够精通技术，以了解什么是什么代码格式以及Java如何对待Whitespace？因为如果不是这样，我认为他们没有资格做出这样的技术决定（即，这些问题应委派给负责该代码的人）。

但是，如果他们是，或者您试图说服您的“建筑师”或类似的人，那么这就是要信任第三方工具。建议一个享有良好声誉的格式化者，除了您没有做的不多，因为您没有编码格式化。

作为侧轨，让我分享一个轶事。我们的建筑师一次决定重新格式化所有文件。在成千上万的Java文件中，还没有发现一个错误（这已经超过半年）。这使我对Java源代码的Eclipse Formatter信任。这种格式的好处是：

现在，一些格式不佳的课程更容易阅读。
到处都是相同的格式。

但是它也有一些负面的方面：

代码格式不完美。有时手动格式的代码读取更好。格式化尤其是用真正糟糕的代码（太长，嵌套的IF等）而奋斗。
您是否还有其他代码分支，例如偶尔需要修补的旧版本？因为您会忘记与不同的代码样式合并在分支之间（至少在使用SVN时）。
您正在触摸所有文件（有时甚至几乎每行），并一次破坏所有文件的历史记录。它伤害了可追溯性。
实际上，有一个很小的好处，因为每个开发人员都有自己的代码格式，因为您开始学习该格式，并且您可以立即确定一件代码的作者

我个人认为负面的大于积极。这听起来像是一个好主意，但实际上，您的收获并不像您想象的那么多。当您遇到一些格式化的代码时，仅重新格式化该类别或该方法，并将其视为朝着大目标迈出的一小步。

重新格式化后您的单位测试是否通过？如果是这样，那么您将这个想法卖给了管理！

如果您正在使用未经测试的代码进行困难，那么您将有一个难得多的情况。

你想要 “符合公司编码标准的代码” 原文如此]并想说服管理？

微不足道：安装 checkstyle, ，使其成为过程的一部分，将其馈送给您的编码指南，并向他们展示整个代码库的痛苦失败上 checkstyle.

这是技术企业不匹配的一个很好的例子。

技术人员希望这样做，因为它可以使代码难以阅读，但是除非是异常不好，真正的原因是它冒犯了普通程序员的典型微妙的敏感性和美学。

商业人士想管理风险。如果有一些好处，并且没有商业在这里受益，除非您认为使用重新格式的源代码进行未来的开发，这将是更便宜，更快和/或更少的风险，这总的来说，这是一个艰难的卖出。

根据定义，任何更改都存在风险。这里的风险是遥不可及的，但也不是（从管理层的角度来看）几乎没有上涨空间。

还有另一个问题要考虑：这种更改可能会对源控制造成破坏。跟踪谁改变了什么，因为最新的更改对任何行都将是重新格式化，因此您需要去比较修订，这比简单的“责备”或“注释”命令更加乏味。

另外，如果您有几个主动分支，则对您的代码进行重新格式化将造成合并的破坏。

从某种意义上说，纯正格式更改将对所编译没有什么区别，因此对运行时代码的行为没有区别，这是安全的。

值得记住的是，批量重新格式化在以后处理源控制时会导致“乐趣” - 如果多个同事已签出了代码，并且一名团队成员出现并重新格式化了它，那么所有这些副本就已经过时了。更糟糕的是，当他们更新工作副本时，各种冲突将会出现，因为那些格式化更改会影响代码的大部分，并解决这可能是一场噩梦。

重新标准的代码与在Word中重新格式化文件相同。它更改了布局，从而改变了可读性，但没有更改内容。

如果所有文件都格式化相同，则代码变为更多可读, ，这使维护更加容易，因此便宜。同样，代码评论可以更快，更有效。

此外，鉴于格式良好的样式，由于无法隐藏，因此可以更轻松地找到错误。想想是否没有卷发括号的陈述和这些假想括号内的2个语句。

请聪明，检查代码并在重新格式化之前对其进行标记，这样您就有一个状态可以回到（并告诉人们这将是多么容易），重新格式化和入住并再次标记，而无需任何其他更改。

回答这些问题的管理问题，您将大有帮助他们说服它们是一个安全的改变吗？

为什么良好的格式很重要？
将做出什么更改？（如果您无法回答这个问题，您对重建的重新标准还不够了解它将是安全的）
我们的单位测试套件会证明变化没有不良影响吗？（暗示答案需要是肯定的）
现有代码会在源存储库中标记，因此我们有一个快速滚动选项？（提示答案最好是是）

关于它涵盖了它。

实际上，我可能站在他们的身边。重新格式化单位在重新进行生产之前将其打开时进行修复或增强时进行修复或增强。他们应该第一次正确地格式化，但是如果他们在生产中，似乎不必要和鲁ck，仅出于风格的缘故将它们重新格式化。

一致性很好，但是“愚蠢的一致性是小思想的妖精”。

我正在穿我的经理帽子...

作为一个宏伟的项目，我都不会让您这样做。但是，我将对更改的更长估计开放，因为您正在修改现有文件以包括这些格式化更改。不过，我需要您进行格式化更改自己的签到。

感谢您的所有回应。

我说服管理层的最后论点；包括您所有答复的位。感谢您的帮助。

技术的：

重构由空白空间变化组成（没有进口重新排序，没有成员/方法）
重新格式将使用[指定工具和流程
重新格式化将在[在编码周期内指定时间以最大程度地减少合并影响的时间

重新格式化之前和之后：

所有单元测试将通过
所有集成测试都将通过
所有功能测试都将通过
所有SOAP-UI测试都将通过
字节代码是相同的（Javac之后的.class文件的MD5（-g：none））

商业：

目的：遵守公司标准，规定我们的源文件准确地代表代码的逻辑结构。

重构更改与代码更改（Word文档示例如上）
重构将使用[一般过程
重新格式化将发生在[在商业周期内指定时间以最大程度地减少影响的时间

飞行员考试：

确认的“格式批处理”导致合并冲突少于“代码时格式”。。
确认可执行代码（4K+ .class文件）保持不变。（MD5测试）
确认的功能不会受到影响（自动测试/烟雾测试）
确认的格式设置仅包含空白空间。

笔记： 在我的案例中，一部分开发人员使用自动化工具进行“格式化”（按照上述某些答案规定）进行了6个月以上的试点测试。尽管有些人认为重新格式化造成了更多的合并冲突，但实际上并非如此。

这种看法是基于重构的时间巧合。例如，考虑对汽车一无所知的人。有一天，他们的刹车失败了。他们将原因归因于什么？当然是气体。这是他们放入汽车的最后一件事（“加油站”效果？）。但是，显然，制动器和燃油系统是不同的系统，格式和代码更改也是如此。我们发现，在我们的构建过程的背景下，签入不当。

最后，我希望有人会提供与一项研究的良好链接，以显示与常见代码相关的生产力提高，因为很难向业务展示ROI。尽管就我而言，因为这是公司标准，所以我身边有“合规性”。我只需要证明，当您代码时，“格式”与“批处理格式”更加耗时

如果您正在使用蚀作为开发平台，您可以在本地加载所有代码。向管理层展示，通过向他们展示问题选项卡没有问题。

然后，右键单击并格式化每个项目一一 - 再次证明没有引入任何问题。

您可以在本地工作站上执行此操作，而不会对您的存储库有任何伤害。

老实说，如果您的管理层是如此非技术性以至于害怕格式化源代码，则证明格式后的“问题”选项卡上没有出现问题，应该足以证明该代码仍然可以。

更不用说您可能会在源控件中标记旧版本吗？

一个思想流派可能是在不问的情况下做到这一点，然后才能“看看！”

当然，如果您全力以赴，那么您将被解雇。您做出选择...

或者，源控制（或简单备份），然后您始终可以向后滚动。

如果您的代码接近100％的代码覆盖范围，那么我认为可以降低风险。

但是，即使管理层同意代码基础是安全的，我认为他们仍在关注付款是合理的。生命周期。

我们在目前的工作中使用Jalopy。它是一种非常稳定的产品，它会产生真正整洁的输出。当他将其从CVS迁移到SVN时，这里最高级的开发人员将所有代码基础重新格式化，他必须进行一些测试以确保从头到尾一直工作，现在我们有挂钩以确保检查已检查 - 在代码中的格式正确。

话虽这么说，我认为您不能说服任何人，任何工具都是愚蠢（或错），因为没有这种工具。如果您认为收益值得花时间和（非常小的）风险，请尝试说服您的管理层在这样做时看到的最大优势。对我来说，如果以下方式，最大的优势将会出现：

所有开发人员都具有相同的格式设置；
源代码的格式通过您的SCM中的钩子在签到时检查。

因为如果您执行以上操作，则如果您的代码已经格式化，则在比较SCM中的修订时，您会看到程序逻辑上的实际更改，而不仅仅是格式化更改。

如果您对单元测试的覆盖范围很好，则在之前和之后的测试结果就足够了。

只有一个特定的头脑：如果您的公司策略包括字母会员分类，请注意静态字段的顺序确实很重要。因此，如果您包括这样做的保存或清理规则，则可能会破坏代码。

从技术上讲，在编译的第一阶段，Lexer剥离了所有评论和来自源的空格。这是在编译器认可任何代码语义的时间之前。因此，任何空格或评论都无法更改程序逻辑中的任何内容。相反，如果添加几个空间或新线会改变语义，该语言将是什么用法以及谁想使用它？

在业务方面，您可能会使用一些专业工具为此。我相信他们在网站上做广告，他们的工作效果很好。

最终注意：如果您必须说服您的管理层，也许您应该寻找一种与更智能的人合作的方法？

我会问管理层他们当前相信代码有效的基础是什么 - 然后证明相同的工具（测试，文档，很少的声音...）对重新格式的代码完全效果。我希望他们的答案成为“测试” ...

我知道以前的答案都很好，但是这是另一个可能的答案：做一个 CRC 在重新格式化之前和之后的编译版本上。由于编译会忽略空间，选项卡，线摘要等，因此编译的版本应与原始版本相同，并且向那些半技术经理证明一切都很好。

许可以下： CC-BY-SA 和归因

不隶属于 StackOverflow