匿名用户
这个问题不用翻日历找答案，代码自己会用疼痛告诉你。设计模式和架构的书什么时候翻都有价值，但真正学得进去、用得上的时机，多半是你被自己写的代码坑过之后。
代码给你的信号
不用看时间，看代码的状态就行。几个很具体的信号：
- 复制粘贴同一段逻辑超过三次，改一个 bug 要在好几处各改一遍，还总漏掉一处；
- 函数长到几百行，自己一周前写的代码，现在读不太懂；
- 想加个小功能却牵一发动全身，不敢下手，怕改崩别的地方；
- 别人问"这段为什么这么写"，你（或者三个月后的你）答不上来。
这些信号出现一两个，就该补课了。反过来，信号还没出现就硬啃设计模式的书，基本等于背菜谱但没做过菜——记住了二十几种模式的名字，真写代码时一个都想不起来。
先学分层和模块化
很多人一提"架构"就去啃《设计模式》，顺序其实反了。先该补的是更朴素的三样：
- 分层：界面归界面，业务逻辑归业务逻辑，数据访问归数据访问。哪怕只是把一个几千行的控制器拆成 Controller、Service、Repository 三层，代码立刻清爽一截；
- 模块化：把大问题切成小块，每块只管一件事，块与块之间通过明确的接口打交道，而不是互相伸手改对方的内部状态；
- 基本重构手法：提取函数、提取类、用多态替掉一大串 if-else。这几招的日常使用频率，比设计模式高得多。
这些练熟了再回头看设计模式，会发现很多模式就是朴素招式遇到瓶颈后的进阶版——工厂是把创建对象的代码收拢，策略模式是把一坨 if-else 拆成可替换的算法。带着痛点学招式，一学就会；没痛点背招式，背完就忘。
别过早设计
另一头也要防：别在项目第一周就画五层架构图、到处套模式。过早设计的代价很实在——抽象层太多，读代码的人要层层穿透；需求还不清楚时做的抽象，大概率猜错方向，后面还得拆掉重来。
比较健康的节奏是：先写能跑的代码，允许它乱一阵；乱到拖慢交付了，停下来重构；重构时发现缺招了，再有针对性地去学对应的模式和架构思想。代码乱过不是罪，那是学费；一直乱着不收拾，才是真的浪费。