摘要：为什么你写的代码三个月后连自己都看不懂？为什么改一个 Bug 会引出三个新 Bug？在 2026 年，当 AI 能帮我们快速生成代码时，**“如何设计代码结构”**反而成了区分初级和高级工程师的分水岭。本文介绍三个被严重低估的编程原则，助你构建真正长寿的系统。
01. 你的代码为什么会腐烂？
软件工程里有一个残酷的定律：代码的熵（混乱度）总是随时间增加的。 除非你施加外力去对抗它。
大多数项目死掉，不是因为在技术上跑不通，而是因为维护成本极速上升，导致开发团队不敢改、改不动，最终不得不重写（然后重复这个悲剧）。
传统的"设计模式"（比如工厂模式、策略模式）有时候反而会增加复杂度。 今天，我想聊聊三个更"底层"、甚至有点"反直觉"的现代编程原则。
02. 原则一：行为局部性 (Locality of Behavior)
传统教条：“关注点分离”（Separation of Concerns）。把 HTML 写在 .html，CSS 写在 .css，JS 写在 .js。
现实痛点：当你看到一个 <button class="btn-primary" id="submit-btn"> 时，你完全不知道点击它会发生什么。 你必须去搜 submit-btn 在哪个 JS 文件被绑定了，去搜 btn-primary 被定义在哪里。 为了改一个按钮，你打开了三个文件，跳转了五次。
LoB 原则：代码的行为应该尽可能靠近它被定义的地方。
这就是为什么 Tailwind CSS 和 htmx 会在近几年爆火。
不好的代码 (分离太远)：
<!– index.html –>
<button id="btn">Click me</button>
<!– style.css –>
#btn { color: red; }
<!– script.js –>
$('#btn').on('click', () => { /* 20 lines of logic */ });
好的代码 (LoB 风格)：
<!– 行为和样式，就在这里，一目了然 –>
<button
class="text-red-500 hover:bg-red-100"
hx-post="/clicked"
hx-swap="outerHTML"
>
Click me
</button>
心法：不要为了所谓的"整洁"把逻辑拆得支离破碎。"好读"比"好看"更重要。
03. 原则二：解析而非校验 (Parse, Don’t Validate)
传统教条：在函数开头写一堆 if 检查参数。
现实痛点：这种检查很容易被遗漏，或者在系统各处重复编写。而且，通过了校验并不能改变数据的类型，后续代码依然要担心"万一它是空的怎么办"。
PDV 原则：将非结构化的数据（如 JSON），尽可能早地转化为结构化的类型（如 Class 或 Interface）。 让非法状态在类型系统中无法表示。
不好的代码 (Validate)：
function sendEmail(email: string) {
if (!email.includes('@')) {
throw new Error("Invalid email");
}
// 发送逻辑…
// 隐患：如果其他函数调用了这个函数，不知道是否已经校验过
}
好的代码 (Parse)：
// 定义一个"不可能出错"的类型
type EmailAddress = string & { __brand: "Email" };
// 解析函数：这是唯一能生成 EmailAddress 的地方
function parseEmail(input: string): EmailAddress | null {
if (input.includes('@')) {
return input as EmailAddress;
}
return null;
}
// 业务函数：完全不需要校验，因为类型系统保证了它是对的
function sendEmail(email: EmailAddress) {
// 直接发送
}
心法：利用类型系统（TypeScript/Rust/Go）做守门员。把运行时错误，转化为编译时错误。
04. 原则三：模块化单体 (Modular Monolith)
传统教条：“微服务是架构的终点”。所有东西都要拆成独立服务。
现实痛点：为了调一个用户接口，要走一次 RPC；为了一个事务，要上分布式锁；为了排查一个 Bug，要翻 5 个服务的日志。 对于 99% 的公司，微服务是"过早优化"的毒药。
Modular Monolith 原则：代码在逻辑上高度解耦（模块化），但在部署上是一个整体（单体）。
所有的模块在同一个进程内运行，调用是内存级的（纳秒级），而不是网络级的（毫秒级）。 当某个模块（比如"图片处理"）真的成为瓶颈时，再把它剥离出去。
心法：不要为了拆分而拆分。 只有当团队大到坐不进两张披萨的会议室，或者业务特性差异极大（如 CPU 密集 vs IO 密集）时，才考虑微服务。
05. 结语
这三条原则，不能帮你写出"炫酷"的代码，但能帮你写出**“无聊且有用”**的代码。 而这，才是职业程序员的顶级素养。
你还知道哪些"反直觉"但好用的编程原则？欢迎评论区补充！
