把解决方案沉淀成可复用资产

代码也应当保持便于回退和比较。一个改动尽量只解决一个问题，提交记录写明实际目的🎊，重要配置和依赖版本保持可追踪。这样在新功能引入异🎇常时，可以快速定位变化范围，而不是面对一大批混杂修改。

阅读教程时，先做一个最小可运行示例

真正理解一段代码，至少要能回答三个问题：它依赖什么、核心逻辑如何工作、失败时会留下什么现象。如果只能复制粘贴，却无法解释输入输出和异常处理，代码暂时还没有变成自己的开发能力。

排错时最容易出现的问题是反复修改代码，却没有记录每次修改的结果。更稳妥的方式是先稳定复现，再根据错误链路缩小范围。可以按照“现象、位置、输入、变化、验证”的顺序进行。

例如，一个查询速度慢的功能，可能真正的问题是重复查询、缺少必要索引、返回数据过多或网络等待，而不是某个循环语句本身。先获得基准数据，再进行单点改动，才能判断优化是否有效。