如何使管理层相信重新格式化整个Java代码库是安全的
我们如何向管理层证明，一批产品都需要重新格式化。大型代码库中的java文件（使代码符合公司的编码标准）是安全的，不会影响功能
答案必须安抚非技术性和技术性的人
编辑：2010-03-12澄清你们之间的技术问题；reformat=仅更改空白-无“组织导入”或“重新排列成员变量、方法等”
编辑：2010-03-12感谢您的众多回复。我感到惊讶的是，这么多的读者投票支持乔尔特科拉先生的回答，因为这只是一个关于偏执狂的声明，根本没有提出我问题的答案。此外，甚至还有同一位撰稿人的评论重申了这个问题。Wizzardofods支持这一观点（但你可能没有阅读所有评论来了解它）-杰特桑普森
编辑：2010-03-12我将很快发布我自己的答案，尽管John Skeet的答案与MD5的建议完全一致（注-g：无需关闭调试）。虽然它只涉及技术方面-杰特桑普森
2010-03-15我在下面添加了我自己的答案。作为对“安全”含义的回应，我的意思是Java代码的功能不会受到影响。对Java编译器的简单研究表明了这一点（有几个注意事项）。这些警告“仅限于空白”，并由几张海报指出。然而，这并不是你想尝试向BizOps解释的事情。我的目的是引出“如何证明这样做是合理的”类型的答案，我得到了一些很好的回答
有几个人提到了源代码管理以及随之而来的“乐趣”。我没有特别提到这一点，因为这种情况（在我的背景下）已经得到了很好的理解。当心“加油站”效应。见下面我的答案
# 1 楼答案
这根本不安全，你不可能说服他们。作为一个管理了很多发展的人，我永远不会把它看作是任何收入依赖的商业代码基础。我并不是说按照你喜欢的方式编写代码没有什么好处，但是你的格式不涉及一些代码更改的可能性是零。这意味着收益微乎其微会带来巨大的风险。如果你必须这样做，在你修复代码的时候就要一点一点地去做，不要在一次大的打击中去做。对于程序员来说，这可能是一个好决定，但对于管理层来说，这将是一个糟糕的决定
# 2 楼答案
在商业环境中，你有两个挑战
从技术角度来看，重新格式化是一项成熟的技术。与哈希/校验和相结合，只要该语言对空格不敏感，从技术上讲，这样做是安全的。您还需要确保在停机期间执行此操作，因为没有主要的分支等待合并。真正的改变不可能与重新格式化分开，所以要分开进行。对于任何使用叉子的人来说，合并可能非常困难。最后，只有在实现了完整的测试用例覆盖之后，我才会这么做。因为原因2
在政治上，如果你不知道如何说服管理层，你怎么知道它是安全的？更具体地说，它对你来说是安全的。对于一个高级的、值得信赖的开发人员来说，这是一项更容易的工作，但是对于一个在一个大型的、政治性的、有红磁带记录的组织中工作的开发人员来说，你需要确保你覆盖了所有的基础
我在2010年提出的论点可能有点太聪明了，但解析器、重新格式化、漂亮的打印机都只是软件；它们可能有由代码库触发的错误，尤其是如果是C++的话。如果到处都没有单元测试，并且代码库很大，您可能无法100%验证最终结果是否相同
作为一名开发人员，我很偏执，这个想法让我感到不安，但只要你使用：
那你就没事了
然而，想想看：管理层现在意识到，你在一个百万线项目中进行“大规模变革”。重新格式化后会报告以前未发现的错误。您现在是导致此错误的主要嫌疑人。是否“安全”有多种含义。这可能对你和你的工作都不安全
这听起来很老套，但几年前我记得发生过这样的事情。在一个夜间维护窗口后的一天，我们收到了一份错误报告，我只对一台IIS服务器进行了重新配置和重启。几天来，我一直在说我一定是搞砸了，或者是部署了新代码。没人直截了当地说，但我从一位副总裁那里得到了这样的表情。我们最终找到了一个bug，它已经存在于代码中，以前被推过，但直到QA人员最近更改了一个测试用例后才出现，但老实说，有些人甚至不记得那部分；他们只记得第二天又来了一只新虫子
编辑：回应jtsampson's edits。你的问题不是怎么做；这是“如何让管理层相信它是安全的”。也许你应该问，“它安全吗？如果安全，怎么做，安全。”我的发言是在指出你问题的讽刺之处，因为你认为它是安全的，却不知道如何。我理解重新格式化的技术方面，但我要指出的是，任何非琐碎的事情都有风险，除非你找对人，否则可能会搞砸。这项任务会不会影响程序员的其他任务，让他们在几天的时间里避开它们？它会与其他程序员未承诺的修订相冲突吗？资料来源是否正在修改中？是否有任何对空格敏感的嵌入式脚本，例如Python？任何事情都可能产生意想不到的副作用；对于我们的环境来说，很难找到一个没有人在分支上工作的时间窗口，大规模的重新格式化将使它们的合并变得非常丑陋。因此，我不喜欢手工或自动化的大规模重新格式化
# 3 楼答案
我们在这里谈论的是什么管理？他们是否足够精通技术，能够理解什么是代码格式，以及Java如何处理空白？因为如果他们没有，我认为他们没有资格做出这样的技术决定（即，这些问题应该委托给负责代码的人）
但如果他们是，或者你试图说服你的“架构师”或类似的人，那么这就是信任第三方工具。建议一个有良好声誉的格式化程序，除此之外你做不了什么，因为你没有编写格式化程序
作为补充，让我分享一个轶事。我们的架构师当时决定重新格式化所有文件。在数千个Java文件中，还没有发现一个错误（这是半年前的事）。这让我相信Eclipse的Java源代码格式化程序。这种格式的好处是：
但它也有一些负面影响：
我个人认为消极面大于积极面。这听起来是个好主意，但实际上你并没有得到你想象的那么多。当你遇到一些格式糟糕的代码时，只需重新格式化那个类或那个方法，并将其视为朝着大目标迈出的一小步
# 4 楼答案
使用务实的方法：
# 5 楼答案
我会用四个词
源头控制。 单元测试
# 6 楼答案
如果只是重新格式化，那么这不应该改变编译器的输出。在重新格式化之前和之后对构建进行一次散列（MD5应该足够好了）——如果每个文件都是相同的，这显然意味着它不能改变行为。不需要运行测试等——如果输出是逐字节的，很难看出测试是如何开始失败的。（当然，运行测试只是为了展示它可能会有所帮助，但它们不会证明任何相同的二进制文件无法证明的东西。）
编辑：正如注释中指出的，二进制文件包含行号。确保使用
-g:none编译以省略调试信息。那就可以更改行号了——但是如果你要更改名称，那将是一个更严重的更改，而且可能确实是一个突破性的更改我假设你可以重新格式化和重建，而不需要任何人关心——只有将重新格式化的代码检查回源代码控制中，才有理由担心。我不认为Java类文件中有任何给出构建日期等的内容。但是，如果您的“格式化”更改了字段等的顺序，可能会产生重大影响