和团队盘点一个项目。起先是由实习生发起的，用 Spring Boot 打底。发展着发展着，需要将功能拆开，然后就砸到了老夫手上。

项目组织是一个 pom.xml 的文件，一是对 Java 世界的东西不太熟悉，二是对各种开发环境/构建系统也了解不全，已经不清楚 pom.xml 是谁的工程文件了（查了一下，貌似是 Maven 的）。好在 Visual Studio Code 现在够用，能导入。

项目依赖的下载，嗯，在公司的小破网上跑了将近一整天。在此期间，不编译，死写代码。后来到了一个需要阶段性验证的地步，只好先提交到仓库，让其他同学 pull 后编译执行。第一阶段实现一个接口，很顺利，老夫写的代码仅改了一处需要 import 和一个构造函数前少了 public 的问题。

在 Lombok 的加持下（vscode 里也有插件的），跟数据库的交互也很顺畅，简直以为前方就是一马平川了。结果还是 too young too simple 了，而且 this time 就“拿衣物”了。在某个接口的代码完毕之后，程序出现了执行起来很快就退出的情况。没有任何可供探查的信息输出。就是干巴巴的一个通知：

HikariPool-1 – Shutdown initiated…
HikariPool-1 – Shutdown completed.
Stopping service [Tomcat]

怀疑机器内存不够、本机 Java 环境或者其他支撑环境受损、网络不通畅、数据库表处理失当，等等等，无果。最后，老老实实、仔仔细细、逐行代码进行排查，最终发现一个 dao 接口类的方法是元凶。具体到细节，则是 find 动词检索的字段名，其实在该表中是不存在的。在网上能够搜索到的一个事例（https://blog.csdn.net/a704397849/article/details/90648899）表明，注解（或者我进一步理解为代码生成技术）在编程中带来便利的同时，也把隐患埋藏得更深。

整体排查的时间开销，大概是 6 人时。直接导致老夫于凌晨在东直门大街上瑟瑟发抖地等待出租车的到来，上车后哆嗦了至少五分钟，连话都说不完整，也算是一个奇妙的体验。