jts*_*son 15 java reformat reformatting
如何向管理层证明批量重新格式化大型代码库中的所有.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解释的内容.我的目的是引出"如何证明这样做"的答案,我得到了几个很好的回答.
有几个人提到了源代码控制和随之而来的"乐趣".我特别没有提到,因为这种情况已经很好理解(在我的背景下).谨防"加油站"的影响.请参阅下面的答案.
Jon*_*eet 37
如果它只是重新格式化,那么这不应该改变编译器输出.在重新格式化之前和之后获取构建的哈希(MD5应该足够好) - 如果对于每个文件都相同,这显然意味着它不能改变行为.没有必要运行测试等 - 如果输出是字节的字节相同,很难看到测试将如何开始失败.(当然,仅仅为了展示它而运行测试可能会有所帮助,但它们不会证明相同的二进制文件不会做任何事情.)
编辑:正如评论中所指出的,二进制文件包含行号.确保编译时-g:none省略调试信息.那应该可以改变行号 - 但是如果你改变名称这是一个更严重的改变,那么这可能确实是一个突破性的改变.
我假设您可以在没有任何人关心的情况下重新格式化和重建 - 只需将重新格式化的代码检查回源代码控制就应该给予任何关注.我认为 Java类文件中没有任何内容可以提供构建日期等.但是,如果您的"格式化"更改字段的顺序等,则会产生重大影响.
cod*_*eim 34
在商业环境中,您有两个挑战.
从技术角度来看,重新格式化是一项成熟的技术.结合散列/校验和,只要语言不是空白敏感,您在技术上可以安全地执行此操作.您还希望确保在没有主要叉子等待合并的停机期间执行此操作.实际更改将无法与重新格式化分开,因此请单独进行更改.对于在叉子上工作的人来说,合并可能非常困难.最后,我只会在实施完整的测试用例覆盖后才会这样做.因为原因2 ......
在政治上,如果你不知道如何说服管理层,你怎么知道它是安全的？更具体地说,它对您来说是安全的.对于一个掌控商店流程的高级,值得信赖的开发人员来说,这是一项更容易的工作,但对于在大型政治红色组织中工作的开发人员,您需要确保覆盖所有基地.
我在2010年提出的论点可能有点过于聪明,但解析器,重新格式化器,漂亮的打印机只是软件; 他们可能有你的代码库触发的错误,特别是如果这是C++的话.如果没有单元测试,使用大型代码库,您可能无法100%验证最终结果是否相同.
作为开发人员,我是偏执狂,这个想法让我感到不安,但只要你使用:
那你没事.
然而,思考这一点:管理层现在意识到你正在百万线项目中进行"大规模改变".重新格式化后会报告以前未发现的错误.您现在是导致此错误的主要嫌疑人.它是否"安全"具有多重含义.这对你和你的工作可能不安全.
这听起来很陈旧,但几年前我记得发生过这样的事情.我们在夜间维护窗口后的一天内收到了一个错误报告,我只进行了重新配置并重新启动了IIS服务器.有好几天,故事是我必须搞砸了,或者部署了新的代码.没有人直接说出来,但我从副总裁那里得到了这样的表情.我们最终将它追溯到已经在代码中的错误,之前已被推送过,但是直到QA人员最近更改了测试用例后才出现,但老实说,有些人甚至不记得那部分; 他们只记得第二天来到一个新的bug.
编辑:回应jtsampson的编辑.你的问题不是关于如何做到的; 它是"如何说服管理层确保其安全".也许你应该问过,"它是安全的吗？如果是的话,怎么做,安全." 我的发言指出了你的问题具有讽刺意味,因为你认为它是安全的,不知道如何.我很欣赏重新格式化的技术方面,但我指出,任何非平凡的事情都有风险,除非你把合适的人放在上面,否则它可能会被搞砸.这项任务是否会减损程序员的其他任务,将他们拖延几天？它会与其他编码器的未提交修订版冲突吗？源头是否正在修改？是否存在任何对空白敏感的嵌入式脚本,例如Python？任何事都会产生意想不到的副作用; 对于我们的环境来说,很难得到一个没有人在分支机构上工作的时间窗口,大规模重新格式化会使他们的合并变得非常丑陋.因此,我厌恶大规模重新格式化,手动或自动化.
嗯,这根本不安全,你不可能说服他们.作为管理了大量开发的人,我不会在任何收入所依赖的商业代码库中考虑它.我并不是说代码格式化没有优势你喜欢,但你的格式化不会涉及一些代码更改的机会是零.这意味着收益微不足道的风险很大.如果你必须这样做,那么在你修复代码时就要零碎地做,不要大打折扣.对于作为程序员的人来说,这可能是一个很好的决定,但对于他们来说,这对管理层来说是一个糟糕的决定.