6条编程铁律，早懂少踩坑

这张图总结了 6 条最核心的编程法则，是无论你用什么语言、做什么项目，都值得反复对照实践的写码黄金标准。 下面是逐条拆解和场景说明： 1. DRY（Don’t Repeat Yourself）不要重复造轮子 如果一段逻辑在多个地方出现，应该提取成方法或函数。 冗余代码不仅难维护，还容易出错。 实际场景： 写表单校验、接口请求等功能时不要复制粘贴。 2. YAGNI（You Aren’t Gonna Need It）不要写没用的功能 “这个以后可能会用到”是代码臃肿的开始。 只实现你现在需要的功能，不要预支未来。 实际场景： 做 MVP、初期产品迭代时，切忌为未来写“兜底逻辑”。 3. LOD（Law Of Demeter）得墨忒耳法则：模块要解耦 模块之间的通信尽量通过有限接口进行，不要深层调用其他模块的内部细节。 实际场景： 避免出现 a.getB().getC().doSomething() 这样的链式调用，增加耦合风险。 4. SOC（Separation Of Concerns）关注点分离 每一块代码只做一件事。UI 和业务逻辑要拆开，逻辑和数据处理也要分离。 实际场景： React 组件中不要既写请求又写渲染，还操作 DOM。 5. SOLID：面向对象五大原则 这五个原则合在一起，是写出可维护、可扩展代码的关键： • 单一职责（SRP） • 接口隔离（ISP） • 依赖反转（DIP） • 开闭原则（OCP） • 里氏替换（LSP） 实际场景： 拆分类、定义接口、封装业务逻辑时用得上。 6. DYC（Don’t Yell Code）写清晰可读的代码 多加注释、命名规范，不要留“神秘代码”。 实际场景： 一年后你自己看不懂自己写的代码，是很常见的事。 这些原则不是为了看起来“高级”，而是真正能帮你写出更稳、更能交付、更容易维护的代码。 不懂的时候你会觉得它们“太理论”，懂之后你会庆幸：早该照着这套方法写。