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

Question

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

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

编辑：2010-03-12 对您的技术进行澄清; reformat =仅限空格的变化 - 没有“组织导入”或“成员变量，方法等的重新排序”。

编辑：2010-03-12 感谢您的回复。令我感到惊讶的是，很多读者都对mrjoltcola的回应进行了投票，因为它只是一个关于偏执狂的陈述，并没有提出我的问题的答案。此外，同一个撰稿人甚至有一条评论重申了这个问题。 WizzardOfOdds支持这一观点（但你可能没有阅读所有评论看到它）。 -jtsampson

编辑：2010-03-12 我会尽快发布自己的答案，虽然John Skeet的回答是正确的MD5建议（注意-g：无关闭调试）。虽然它只涉及技术方面。 -jtsampson

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

有些人提到了源代码控制和随之而来的“乐趣”。我特别没有提到，因为这种情况已经很好理解（在我的背景下）。谨防“加油站”的影响。请参阅下面的答案。

Answer 1

如果它只是重​​新格式化，那么这不应该改变编译器输出。在重新格式化之前和之后获取构建的哈希（MD5应该足够好） - 如果对于每个文件都是相同的，这显然意味着它不能改变行为。没有必要运行测试等 - 如果输出是字节的字节相同，很难看到测试将如何开始失败。 （当然，只是为了展示它而运行测试可能会有所帮助，但它们不会证明相同的二进制文件不会发生任何事情。）

编辑：正如评论中所指出的，二进制文件包含行号。确保使用-g:none进行编译以省略调试信息。那应该可以改变行号 - 但是如果你正在改变名称这是一个更严重的改变，而且确实可能​​是一个突破性改变。

我假设您可以重新格式化并重建而无需任何人关心 - 只需将重新格式化的代码重新检入源控件即可给予任何关注。我不认为 Java类文件中有任何内容可以提供构建日期等。但是，如果你的“格式化”改变了字段的顺序等，可以有显着效果。

Answer 2

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

1. 技术
2. 政治

从技术角度来看，重新格式化是一项成熟的技术。结合散列/校验和，只要语言不是空白敏感，您在技术上可以安全地执行此操作。您还希望确保在没有主要叉子等待合并的停机期间执行此操作。实际更改将无法与重新格式化分开，因此请单独进行更改。对于在叉子上工作的人来说，合并可能非常困难。最后，我只会在实施完整的测试用例覆盖后才会这样做。因为原因2 ...

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

我在2010年提出的论点可能有点过于聪明，但解析器，重新格式化器，漂亮的打印机只是软件;他们可能有你的代码库触发的错误，特别是如果这是C ++的话。如果没有单独的单元测试，使用大型代码库，您可能无法100％验证最终结果是否相同。

作为一名开发人员，我很偏执，这个想法让我感到不安，但只要你使用：

1. 来源控制
2. 适当的测试覆盖率

然后你没事。

然而，思考一下：管理层现在意识到你正在百万线项目中进行“大规模改变”。重新格式化后会报告以前未发现的错误。您现在是导致此错误的主要嫌疑人。它是否“安全”具有多重含义。对你和你的工作来说可能不安全。

这听起来很陈旧，但几年前我记得这样的事情发生了。我们在夜间维护窗口后的一天内发布了一个错误报告，我只进行了重新配置并重新启动了IIS服务器。有好几天，故事是我必须搞砸了，或者部署了新的代码。没有人直接说出来，但我从副总裁那里得到了这样的表情。我们最终将它追溯到代码中已经存在的错误，之前被推过，但是直到QA人员最近更改了一个测试用例时才出现，但老实说，有些人甚至不记得那部分;他们只记得第二天来到一个新的bug。

编辑：回应jtsampson's edits。你的问题不是关于如何做到的;它是“如何说服管理层确保其安全”。也许你应该问过，“它是否安全？如果是这样，怎么做，安全。”我的发言指出了你的问题具有讽刺意味，因为你认为它是安全的，不知道如何。我很欣赏重新格式化的技术方面，但我指出，任何非平凡的事情都有风险，除非你把合适的人放在上面，否则它可能会被搞砸。这项任务是否会减损程序员的其他任务，将他们拖延几天？它会与其他编码器的未提交修订版冲突吗？源头是否正在修改？是否有任何对空格敏感的嵌入式脚本，例如Python？任何事都会产生意想不到的副作用;对于我们的环境来说，很难得到一个没有人在分支机构上工作的时间窗口，大规模重新格式化会使他们的合并变得非常丑陋。因此，我厌恶大规模重新格式化，手动或自动化。

Answer 3

使用实用的方法：

1. 构建应用程序。
2. 保存应用程序。
3. 重新格式化代码。
4. 构建应用程序。
5. 区分二进制文件。

Answer 4

我会用四个字。

来源控制。 单元测试。

Answer 5

嗯，这根本不安全，你不可能说服他们。作为管理了大量开发的人，我不会在任何收入所依赖的商业代码库中考虑它。我并不是说代码格式化没有优势你喜欢，但你的格式化不会涉及一些代码更改的机会是零。这意味着收益微不足道的风险很大。如果你必须这样做，那么在你修复代码时就要零碎地做，不要大打折扣。对于作为程序员的人来说，这可能是一个很好的决定，但对于他们来说，这将是一个糟糕的决策。

Answer 6

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

但如果他们是或者你试图说服你的“建筑师”或类似的人，那么它就是信任第三方工具。建议一个声誉良好的格式化程序，除了你不能做的事情，因为你没有对格式化程序进行编码。

作为一个侧面轨道，让我分享一个轶事。我们的架构师一次决定重新格式化所有文件。在成千上万的Java文件中，还没有找到任何一个错误（这是半年前的事情）。这让我相信Eclipse的Java源代码格式化程序。这种格式化的好处是：

• 现在，一些格式错误的类更容易阅读。
• 到处都是相同的格式。

但它也有一些消极方面：

• 代码格式化程序并不完美。有时手动格式化的代码更好。格式化程序尤其会遇到非常糟糕的代码（行太长，嵌套ifs太多等）。
• 您是否有其他代码分支，例如偶尔需要修补的旧版本？因为您可以忘记在具有不同代码样式的分支之间进行合并（至少在使用SVN时）。
• 您正在触摸所有文件（有时几乎每行）并同时破坏所有文件的历史记录。这会伤害可追溯性。
• 实际上有一个小好处，即每个开发人员都有自己的代码格式，因为您开始学习格式化，并且您可以立即识别一段代码的作者

我个人认为负面影响大于正面。这听起来是个好主意，但实际上你并没有像你想象的那样获得多少收益。当你遇到一些格式很复杂的代码时，只需重新格式化那个类或只是那个方法，并将其看作是迈向大目标的一小步。

Answer 7

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

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

商界人士希望管理风险。如果有一些好处并且此处没有业务好处，则可以承担风险，除非您认为使用重新格式化的源代码进行未来开发会更便宜，更快和/或风险更低诚实是一个艰难的卖点。

几乎按照定义，任何变化都附带风险。这里的风险很小，但也不存在（从管理层的角度来看）几乎没有上涨。

还有另一个问题需要考虑：这种变化会对源代码控制造成严重破坏。跟踪更改内容的人变得更加困难，因为对任何行的最新更改都将是重新格式化，因此您需要比较修订版本，这比简单的“责备”或“注释”命令更乏味​​。

此外，如果您有多个活动分支，则重新格式化代码将对合并造成严重破坏。

Answer 8

您希望“代码符合公司的编码标准” [原文如此]，并希望说服管理层？

琐碎：安装 CheckStyle ，让它成为您流程的一部分，提供您的编码指南，并在 CheckStyle <上显示整个代码库 FAILS / em>的

Answer 9

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

如果您正在使用未经测试的代码，那么您将面临更难的案例。

Answer 10

实际上，我可能会站在他们一边。重新格式化单元，当它们在重新投入生产之前进行全面测试时打开它们以进行修复或增强。它们应该在第一次被正确格式化，但是如果它们正在制作中，那么仅仅为了风格而重新格式化它们似乎是不必要的和鲁莽的。

一致性很好，但“愚蠢的一致性是小思想的大人物”。

Answer 11

感谢您的所有回复。

我说服管理层的最后一个论点;包含所有回复的比特。谢谢你的帮助。

<强>技术：

• 重新格式化包含空格更改（无导入重新排序，无成员/方法）
• 重新格式化将使用[指定工具和流程]
• 将重新格式化[在编码周期内指定时间以最小化合并影响]

重新格式化之前和之后：

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

商家：

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

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

试点测试：

• 确认“格式批处理”导致较少的合并冲突，然后是“格式化为代码”。
• 确认可执行代码（4k + .class文件）保持不变。 （MD5测试）
• 确认的功能不会受到影响（自动测试/冒烟测试）
• 确认的格式化程序设置仅包含空格更改。

注意：在我的情况下，一部分开发人员使用自动化工具“按代码格式化”（由上面的一些答案规定）进行了6个月的试验测试。虽然有些人认为重新格式化引起了更多的合并冲突，但事实并非如此。

这种看法是基于重新格式的时间重合。例如，考虑一下对汽车一无所知的人。有一天他们的刹车失灵了。他们归因于什么？气体当然。这是他们放入汽车的最后一件事（“加油站”效应？）。然而，显然，制动器和燃料系统是不同的系统，格式和代码变化也是如此。我们发现在我们的构建过程中不正确的签入是错误的。

最后，我希望有人能够提供一个很好的链接，以显示与公共代码相关的生产力提升，因为很难向业务显示投资回报率。虽然在我的情况下，由于这是一个公司标准，我有“合规”在我身边。我只需要证明“按代码格式化”与“批量格式化”相比更耗时。

Answer 12

我戴着我的经理帽......

要做一个宏伟的项目，不管争论如何，我都不会让你这样做。但是，我会对更改进行更长时间的估计，因为您正在修改现有文件以包含这些格式更改。我会要求你让格式化更改自己办理登机手续。

Answer 13

回答这些问题给管理层，你会说服他们这是一个安全的改变吗？

1. 为什么好的格式很重要？
2. 会有什么变化？ （如果你不能回答这个问题，你对重新格式化的了解不足以确定它是安全的）
3. 我们的单元测试套件是否会证明这些变化没有任何不良影响？ （提示答案必须是肯定的）
4. 是否会在源存储库中标记现有代码，以便我们快速回滚选项？ （提示答案最好是）

关于它的内容。

Answer 14

重新格式化代码与在Word中重新格式化文档相同;它改变了布局，从而改变了可读性，但不改变内容。

如果所有文件格式相同，则代码变得更加可读，这使维护更容易，因此更便宜。代码审查也可以更快，更有效。

此外，鉴于良好的格式化风格，可以更容易地找到错误，因为它们无法隐藏;想想if if语句中没有花括号和2个语句。

在重新格式化之前，请确保智能并检查代码并对其进行标记，这样您就可以返回状态（告诉人们有多容易），重新格式化并签入并重新标记，无需任何其他更改。

Answer 15

纯粹的格式更改对编译的内容没有任何影响，这是安全的，因此在运行时对代码的行为没有区别。

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

Answer 16

如果您使用Eclipse作为开发平台，则可以在本地将所有代码加载到工作区中。通过向他们展示“问题”选项卡，向管理人员证明没有问题。

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

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

老实说，如果您的管理层非常缺乏技术，以至于害怕格式化源代码，那么证明在格式应足以显示代码仍然正常之后，问题选项卡上不会出现任何问题。

更不用说你可能会在源代码管理中标记旧版本吗？

Answer 17

从技术上讲，在编译的第一阶段，词法分析器会从源中删除所有注释和空格。在编译器识别代码的任何语义之前很久。因此，任何空格或注释都不能改变程序逻辑中的任何内容。相反，如果添加一些空格或换行符会改变它的语义，语言会有什么用处，谁愿意使用它呢？

在业务方面，您可能会使用一些专门的工具。我相信他们会在他们的网站上宣传他们的工作很棒。

最后说明：如果你必须说服你的管理层，也许你应该找到一种与聪明人合作的方法？

Answer 18

如果你的代码有足够的100％代码覆盖率，那么我认为风险可以降低一点。

然而，即使管理层同意代码库是安全的，我认为他们仍然有必要证明付钱给员工花费数小时重新格式化代码只是为了遵守一个（我推测）引入的标准进入开发生命周期。

Answer 19

我知道以前的答案都很好，但这是另一个可能的答案：在重新格式化之前和之后对编译版本执行CRC。由于编译会忽略空格，制表符，换行符等，因此编译后的版本应与原始版本相同，这将向那些半技术经理证明一切都很好。

Answer 20

我们在目前的工作中使用Jalopy。它是一个非常坚固的产品，它产生非常整洁的输出。这里最资深的开发人员在将其从CVS迁移到SVN时重新格式化了所有代码库，并且他必须执行一些测试以确保它从头到尾一直工作，现在我们有钩子来确保检查 - 在代码中格式正确。

话虽如此，我认为你不能说服任何人任何工具都是傻瓜（或错误）证据，因为没有这样的工具。如果您认为利益值得花时间和（非常小的）风险，请尝试说服您的管理层在此过程中看到的最大优势。对我来说，最大的优势将来是：

• 所有开发人员都具有相同的格式设置;
• 通过SCM中的挂钩在办理登机手续时检查源代码的格式。

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

Answer 21

如果你对单元测试的覆盖率很好，那么之前和之后的测试结果就足够了。

Answer 22

只有一个特定的提示：如果您的公司政策包括字母成员排序，请注意静态字段的顺序很重要。因此，如果您包含执行此操作的on-save或cleanup规则，则可能会破坏您的代码。

Answer 23

一个思想学派可以在没有要求的情况下这样做，然后能够“看！”

当然，如果你把它全部搞砸了，你就会被解雇。你做出了选择......

或者，源代码控制（或简单备份）然后您可以随时回滚它。

Answer 24

我会问管理层他们认为代码工作的当前基础是什么 - 然后证明相同的工具（测试，文档，小声音......）对于重新格式化的代码完全一样。我希望他们的回答是“测试”......