这不是收藏清单，而是我在处理遗留系统、抽象边界、代码质量和团队协作时反复回到的判断框架。
Reading Path
先解决代码是否清楚、是否安全可改、是否能被团队长期维护。
代码质量与重构
坏味道不是审美问题，而是未来变更成本和风险的早期信号。
它让我把“改代码”从凭感觉的动作，变成可拆解、可保护、可回退的工程过程。
面对遗留系统时，我会优先寻找可测试的小切口，而不是一次性重写。
代码质量与重构
代码首先是给人读的，然后才是给机器执行的。
它持续提醒我，真正影响协作效率的，往往是命名、函数职责和边界表达这些小决策。
我会把可读性当作交付质量的一部分，而不是上线后的额外优化。
工程方法与交付
成熟不是知道更多技巧，而是持续建立更短、更可靠的反馈闭环。
它把工程师的成长从技术点清单，拉回到反馈、自动化、工具意识和长期责任感。
我倾向于把问题做成流程、工具或约定，让团队下次更容易做对。
Reading Path
再把局部代码能力扩展到抽象、模块、领域语言和系统边界。
架构与领域建模
模式的价值不是套名字，而是把变化封装在合适的位置。
它不是最严肃的模式书，却很适合建立“变化点在哪里”的设计直觉。
我在设计组件、策略和扩展点时，会先问哪些变化应该被隔离。
架构与领域建模
架构的核心目标，是降低系统长期演进成本。
它把架构讨论从框架选择拉回到依赖方向、边界纪律和业务规则的独立性。
我会优先保护业务规则和核心模型，避免它们被 UI、数据库或框架牵着走。
架构与领域建模
复杂业务需要被讨论、命名和建模，不能只靠 CRUD 承载。
它让我更重视领域语言、限界上下文和聚合边界，而不是只用表结构解释业务。
当系统复杂到团队开始“各说各话”时，我会先回到领域语言和边界划分。
Reading Path
最后回到软件交付的现实：复杂度、沟通成本和团队节奏。
工程方法与交付
增加人手不一定加速，复杂系统首先需要降低协调成本。
它让我更早接受：很多软件问题不是努力不够，而是复杂度、沟通和认知负担没有被正视。
我在评估计划时会同时看技术方案、沟通路径和交付节奏。