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

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

什么!?你要我去修改别人的垃圾代码?!

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

上一次接触 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 的人还会写出这种垃圾代码。