重构是不可能重构的，这辈子都不可能重构的……

好吧，我自己写的垃圾代码我自己重构……

什么！？你要我去修改别人的垃圾代码？！

不得不说，改别人写得非常非常烂的代码真的是一种极大的折磨，更残酷的是要用一种自己没怎么接触过的语言来写，更更残酷的是这种语言的包管理也非常混乱。

上一次接触 Java 还是在我大学的时候，不过也只写过一些零碎的代码，没有做过像模像样的工程。这么久过去了，突然接手一个 N 年前的 Java 项目，代码一团糟，完全就是外行写的，真的很头疼。项目里面各种冗余文件，Jar 包也有一堆，只能看出来用的 Eclipse 这种古老的工具，具体编译方式不详。

鉴于 gRPC 的 demo 是用 Gradle 来管理的，顺便就学了一下。老实说，仅仅 gRPC 部分还好，虽然文档不怎么样，很多细节完全不谈，多数地方靠自己猜测……难就难在怎么玩转 Java 项目，解决各种编译的依赖问题。

这个时候就只能靠搜索引擎来解决了。Java 的出错栈看的我精神恍惚，定位问题很困难，多数时候只能依靠自己以往的工程经验来分析。一个 build.gradle 文件折磨了好久，Gradle 也有各种版本的配置方式，搞在一起就更混乱了，时间上也很紧迫，只能暴力测试了。

后面修改代码的时候，才发现不知道他们怎么运行这个项目的，问了一下原来是编译成 Jar 包然后放到指定目录跑……好吧，我又去查了下 Gradle 怎么把一堆依赖编译进一个 Jar 包里面。修改完代码后，才发现还得把项目原有的依赖也搞进来，这下不得不好好了解下 Gradle 了，没法太偷懒。

最后花了一周的时间来做，确实很慢，不过要不断试错确实也就这样了。

总结一下，面对这种陌生的语言和包管理方式，在严重依赖试错的情况下，一定要保持清醒，从上至下进行分析。就算反馈很模糊，也能从整体逻辑上定位问题。

另外，这种毫无规范、设计可言的代码，真的非常恶心。原来真的有人能写一个几百行的函数出来，即使里面有很大一部分是重复代码也不拿出来写个函数；原来真的有人能从下标 0 写到下标 31；原来真的有人分不清 HashSet 和 HashTable；原来真的有人能不依赖循环一行一行添加数据……

为了防止这种情况再次发生，设置一定的代码规范并且依靠 CI 来自动检查是很有必要的。可以设置一个过渡期，这之后都要严格执行，否则代码维护起来成本太高了。

另外，要我说就是面试卡的太松了。再逼我，以后直接全上 Rust，你们改吧，没有坚实的 CS 基础我看你怎么写 Rust。我就不信能写 Rust 的人还会写出这种垃圾代码。