帮助阿里巴巴遵守阿里巴巴规范（第三季）

在前两季播出后，收到了观众朋友们的许多留言，在这里整理回复如下：

闲的蛋疼 /你这也叫开源？

谁能帮我向他解释一下这是不是开源？我不知道该怎么解释。如果修 code style 不算开源的话，我刚刚发现并顺手修复了一个 p3c 插件的 bug，这算开源么？ https://github.com/alibaba/p3c/pull/472

你发烧了吧 /你这是杠，不是开源 /你是杠精 /你发一次贴就行了，再发就是蹭热度了 /吃饱了撑的

“发现问题，提交代码解决问题”对你们就这么难以理解么？到今天为止我在 GitHub 上已经提交了 370 个 PR，我就是爱给开源项目提交代码，在你眼里都是杠是不是？你以为谁都跟你一样只会动嘴当喷子？昨天我跟阿里巴巴开源负责人聊过了，人家都没意见，轮到你来唧唧歪歪？称你们一声键盘侠不过分吧？

工作量不饱和

这些 PR 都是早晚非工作时间写的。我公司不加班，仍招人，有兴趣可以投递。如果对我的工作量有意见可以向我的主管投诉。

利益相关：前阿里巴巴员工，现 Gradle core team developer

blindpirate

2019-03-16 17:42:45 +08:00

@smeraldo 我是这么理解的：

首先，对于不能 /不想修复的问题，@SuppressWarnings 是常规操作。在 Sentinel 项目中，说句实话，我没有把握把这几个问题修复好（类似的注解还有 @SuppressFBWarnings，是 FindBugs 引入的，它需要额外的注解是因为 FB 扫描的是字节码，字节码中已经没有 @SuppressWarnings 信息了）。

其次，仅仅 @SuppressWarnings 不会使代码变得更坏——它是编译期注解，对编译后的结果没有任何影响。好处是从此之后新的违背代码规范的问题能在第一时间被发现。

最后，假如哪一天团队想要修复相关问题，全局搜索相应的 @SuppressWarnings 注解即可，无需运行构建。

这让我想起来，gradle 在迁移 Java9 的过程中，发现有很多测试在 Java9 上不能通过。我们当时的解决方案是，引入了一个 FIX_TO_WORK_ON_JAVA9 注解，在 Java9 上直接忽略这些测试： https://github.com/gradle/gradle/blob/69e400f5f00d60684c75827ecf61d3521d333467/subprojects/internal-testing/src/main/groovy/org/gradle/util/TestPrecondition.groovy#L106。忽略这些测试并不意味着从此不管了，而只是代表这些问题我们知道了，当前限于实际无法处理。绝大多数被忽略的 Java9 上的测试已经在去年夏天被修复掉了。