设计原则：让你的代码更抗折腾

写代码这事儿，特别像做饭。

刚学会炒菜的时候，你的目标只有一个：能吃。 后来你发现：能吃不够，还得好吃、好做、好收拾、下次还能复刻。 再后来你开始给别人做、跟别人一起做，你才知道最难的是：别把厨房炸了。

软件设计原则也是同一回事： 它不是为了“显得专业”，也不是为了背书装懂，而是为了让你写的代码：

• 不容易烂
• 烂了也好修
• 人多一起写也不互相坑
• 需求改来改去也不至于崩

这篇文章就用大白话，讲清楚三件事：

尽量讲人话，不灌鸡汤，不堆术语。你会看到很多“生活类比”和“翻车现场”。

1. 先说人话：设计原则到底是什么？

设计原则，你可以把它理解成写软件的“生活常识 + 交通规则 + 建筑规范”。

• 生活常识：刀别拿来当筷子用，锅别放床上
• 交通规则：红灯停、别逆行，不然迟早撞
• 建筑规范：承重墙别乱拆，电线别乱接，不然住着住着塌了

对应到软件里就是：

设计原则是一套“经验总结出来的规矩”， 用来指导你如何组织代码，让系统更稳定、更好改、更好扩展、更少出锅。

注意关键词：指导。 它不是法律，更不是万能公式。原则的地位很像“老司机提醒你要注意路况”，而不是“你必须把方向盘打到多少度”。

2. 为啥要有设计原则？因为代码会“变”，而且一定会变

很多人对设计原则的误解是：“我现在写得挺快啊，跑得也行啊，要啥原则？”

你现在觉得不需要，是因为你还没被现实毒打到。软件之所以需要原则，根本原因就一个：

软件不是写完就完事，它会不停变化。 变化才是常态。

变化从哪来？

• 产品说：这个按钮挪一下、这个规则改一下、加个活动
• 运营说：上渠道包、上新支付方式、加埋点
• 技术说：换服务器、换 SDK、换渲染管线、改性能
• 团队说：人换了，你要接手别人代码
• 用户说：崩了、卡了、登不上、付不了款

变化不可怕，可怕的是变化很贵。 设计原则就是在帮你“把变化变便宜”。

3. 没有设计原则会怎样？给你三种常见“翻车现场”

3.1 现场一：改一个小需求，牵一发而动全身

你想改“登录校验规则”，结果发现：

• UI 里写了一份
• 服务层又写了一份
• 还有个工具类里复制了一份
• 还有个临时脚本写了一份

你改了三处，漏了一处，线上就出 bug。

这就是没有遵守 DRY（别重复） 的典型后果：漏改。

3.2 现场二：一个类像“杂物间”，啥都往里塞

很多项目里都会出现这种“神类”：

• GameManager / AppManager
• Utils / Helper
• Common / Global

里面什么都有：登录、网络、音频、UI、存档、活动…… 最后谁都不敢动，因为动一下就可能炸十个地方。

这就是没有遵守 单一职责（SRP） 的后果：耦合爆炸。

3.3 现场三：为了“优雅”，搞得像密码本

反过来也有一种翻车：过度设计。

为了一个简单功能，写了一堆抽象接口、工厂、容器、反射、配置…… 新人打开代码像进迷宫。

这就是违背 KISS（保持简单） 或忽略 YAGNI（你现在用不到就别做） 的后果：复杂度压死人。

4. 设计原则的“具体好处”到底有哪些？别虚，给你算账

设计原则能带来的好处，基本都能折算成四笔账：

用大白话讲就是：

设计原则不是让你代码“看起来高级”， 是让你少熬夜、少背锅、少骂人。

5. 常见设计原则大白话解释 + 它能带来啥好处

下面这些原则你不需要背英文全称，但最好理解“它在防什么坑”。

5.1 KISS：保持简单，别整花活

意思：能用简单方法解决的，就别上复杂方案。 它在防：过度抽象、过度架构、为了优雅而优雅。

好处：

• 新人更容易看懂（学习成本低）
• 出 bug 更好排查（路径少）
• 迭代更快（改动点少）

典型场景：

• 一个 if 就能写清楚的，不要为了“扩展性”先搞一套策略+配置系统
• 小项目别一上来微服务、DDD 全家桶

一句话：

简单不是low，简单是最强的稳定性。

5.2 DRY：别重复，重复就是未来的坑

意思：同一种知识、同一种规则，不要散落在多个地方。 它在防：漏改、版本不一致、逻辑漂移。

好处：

• 改需求只改一处（改得快）
• bug 修一次就真的修好了（不反复）
• 规则统一，产品口径不乱（少扯皮）

典型场景：

• 金币扣除规则不要在 UI、服务、存档各写一份
• 参数校验不要复制粘贴

一句话：

重复代码不是“多写几行”，是“埋了几颗雷”。

5.3 YAGNI：你现在用不到，就别提前做

意思：别为“可能的未来”付出“立刻的复杂度”。 它在防：提前过度设计、做了一堆用不上的功能。

好处：

• 开发更快（不做无用功）
• 系统更简单（复杂度更低）
• 需求变化时更灵活（没被自己绑死）

典型场景：

• 还没跨服需求，就别先做分布式架构
• 还没几十种支付方式，就别先做超级支付插件系统

一句话：

未来不一定来，但复杂度一定留下。

5.4 单一职责（SRP）：一个东西只干一类事

意思：一个类/模块/方法，最好只对“一种变化原因”负责。 它在防：牵一发而动全身、改 A 把 B 弄炸。

好处：

• 改动影响面小（更安全）
• 代码更好测试（更容易写单测）
• 复用更容易（可组合）

典型场景：

• LoginManager 只管登录流程
• 存档、网络、UI 不要全部塞进一个“总管”

一句话：

房间别兼厕所，修起来你会哭。

5.5 开闭原则（OCP）：对扩展开放，对修改关闭

意思：新增功能尽量“加代码”，少“改旧代码”。 它在防：改老代码引入新 bug（老功能被你改坏）。

好处：

• 更稳定（老功能少动）
• 更好迭代（新功能加插件/加实现）
• 更好回滚（新功能是“新增模块”，撤掉就行）

典型场景：

• 新增一种支付方式，不要在一堆 if-else 里硬插
• 用策略/表驱动/配置把扩展点留好（但别过度）

一句话：

别老拆承重墙，扩建要有接口。

5.6 依赖倒置（DIP）：高层别依赖细节，细节依赖抽象

听起来绕，翻译成人话：

意思：业务逻辑不要被某个具体实现“焊死”，要能替换。 它在防：换数据库、换 SDK、换平台时大出血。

好处：

• 可替换性强（换实现成本低）
• 可测试性强（可以 mock）
• 代码结构更干净（依赖方向清晰）

典型场景：

• 业务层不要直接 new 一个具体 HttpClient 写死
• 抽一个接口 INetwork，底层实现可以换 UnityWebRequest / 原生 / gRPC

一句话：

插座比焊死的电线更自由。

5.7 最少知识原则（Law of Demeter）：少打听，少认识

意思：一个对象不要了解太多内部细节，不要“隔着好几层去调用别人家里东西”。 它在防：链式调用导致强耦合，改内部结构就全崩。

好处：

• 降低耦合（结构更稳）
• 重构更容易（内部改动不影响外部）
• 可读性更好（调用路径短）

典型反例：

• a.b.c.d.do() 这种“套娃式调用” 改一个中间层结构，外面全要改。

一句话：

少串门，少八卦，关系简单就不容易翻脸。

6. 设计原则在团队里的真实价值：它是“默认共识”

当团队多人协作时，最可怕的不是某个人写得烂，而是：

• 每个人都按自己的习惯写
• 没有共同标准
• 代码风格、分层方式、依赖方向全不一致

结果项目像一个大杂烩，谁看谁头大。

设计原则的一个隐藏好处是：

它能成为团队的“共同语言”。

比如你 code review 时说一句：

• “这里有点违反 DRY”
• “这个类职责太杂了，SRP 不太行”
• “这个抽象有点早，YAGNI 吧”

大家立刻知道你在说什么，而不是陷入“我觉得/你觉得”的吵架模式。

7. 怎么把设计原则用起来？别背，按这三步走

7.1 第一步：先抓最常用的三条

对大多数项目最立竿见影的就是：

• KISS（别复杂）
• DRY（别重复）
• SRP（别混杂）

先把这三条用好，代码质量立刻上一个台阶。

7.2 第二步：每次写代码前问自己两个问题

设计原则其实就是这两个问题的答案集合。

7.3 第三步：从“最痛的地方”开始改

别一上来就想把全项目重构成“教科书”。 找最痛的：

• 经常改、经常出 bug 的模块
• 一改就牵连一堆的模块
• 新人最难上手的模块

从那里按原则一点点拆分、降耦合、去重复。 你会很快看到收益。

8. 一个小故事收尾：原则不是为了写得漂亮，是为了活得久

你写的第一版代码，像是搭了个棚子，能挡雨就行。 但软件如果要长期运营，就得像房子一样：

• 有规矩（原则）
• 有施工方法（流程）
• 有成熟套路（模式）
• 有整体规划（架构）

设计原则的价值，归根结底是：

让你的系统“更抗折腾”。 需求怎么改，人员怎么换，版本怎么迭代，都不至于一碰就碎。