最近在维护那个跑了十五年的 Struts 1.x 老系统，突然有种奇妙的感觉——写代码和修老房子差不多。

你推开门，看到的是 2009 年的设计决策。Hibernate 2.x 的 Session 管理写得像意大利面，但每条"面条"都有它的历史原因。当年那个加班到凌晨两点的程序员，绝不会想到十五年后还有人读他的代码。这么一想，我现在写的每一行代码，也许也在某个角落等着被后人考古。

这几天在重构一个 BaseHibDAO 的子类，发现里面有一段用 ROWNUM 分页的 Oracle SQL，写得很巧妙。查了 svn blame（对，这个项目还在用 svn），是一个离职八年的同事写的。没有注释，但逻辑一眼就能看懂。好的代码自己会说话，这句话是真的。反过来说，那些需要写三行注释才能解释清楚的方法，大概率是设计本身就有问题。

从注释又想到写文档这件事。以前总觉得没有文档的项目是烂项目，现在想法变了——文档容易过时，代码不会撒谎。一个项目如果结构清晰、命名用心、分层合理，新人拉下来看一天代码就能上手，比看三天过时的 wiki 强得多。当然前提是代码本身经得起读。那个老系统虽然框架古老，但分层很明确：Action → Helper → Factory → DAO，每一层只做自己该做的事，所以虽然 Hibernate 2.x 的写法看着别扭，但改起来并不费劲。

说到分层，现在微服务那套东西，一层套一层，服务间的调用链长得像腊肠。看起来架构图画得漂亮，实际出了问题追链路能追到怀疑人生。那个 Struts 老系统，一个 Tomcat 一个 war 包丢上去就跑，日志从头看到尾三分钟定位问题。不是说微服务不好，只是大部分项目根本不需要那么复杂的架构。简单的东西不一定简陋，好的设计是在能满足需求的前提下尽量简单。

写碎碎念有个好处：不用考虑结构，不用画架构图，想到哪写到哪。今天就到这儿吧。