进入一个新团队以后，我曾经很快列出过一批系统问题。
接口返回不统一，配置文件分散，公共能力没有封装，代码命名也不一致。有些问题确实影响开发效率，从技术规范看也不难判断。
现在回看，那份清单并非完全错误，只是下结论的速度比理解系统的速度快。
新人为什么更容易看见问题
长期维护一套系统的人已经习惯了它的结构，也知道许多约定背后的默认前提。新人没有这些习惯，第一次遇到不清楚的接口或流程时，更容易感受到额外成本。
这种陌生视角很有价值。很多被团队视为理所当然的问题，只有新人会继续追问为什么。
但看见不便，与理解不便怎样形成，是两件不同的事。
代码里看不到全部历史
一段重复逻辑可能源于当时两个团队独立交付；一个看起来过度复杂的兼容层，可能为了迁移不能升级的旧客户端；某个服务边界不合理，也许对应过往组织结构。
这些理由不一定能证明现状合理，却会影响改进方式。忽略历史直接重写，可能再次遇到前人已经处理过的约束。
旧系统的问题通常不是某个人一次设计出来，而是在持续交付、人员变化和局部妥协中逐渐形成。
区分真实成本与个人偏好
工程师很容易把熟悉的技术风格当成更好的答案。
命名方式、框架选择和代码组织可以有多种合理方案。只是不符合自己的习惯，并不足以证明系统需要修改。
更值得优先处理的问题，通常已经产生具体成本：修改容易引发故障，新人难以上手，同类需求不断重复开发，排查依赖少数人，或者发布相互影响。
能够说明成本，建议才有讨论基础。
提建议也需要选择时机
刚入职时立即给出大量改造建议，容易让维护者觉得过去工作被简单否定。即使建议正确，也未必获得支持。
更有效的方式，是先完成一次真实任务，理解团队怎样开发和上线，再围绕已经遇到的问题提出有限改进。小范围验证比完整重构方案更容易建立共识。
对于稳定性风险，当然不必等到完全熟悉以后才指出。但也应该区分明确风险与基于经验的怀疑。
理解不是替旧系统辩护
强调历史条件，不代表所有技术债务都应该继续保留。
有些临时方案早已失去原来的前提，有些结构确实持续消耗团队。理解它们为何存在，是为了知道从哪里改变，而不是为不改变寻找理由。
现在面对陌生系统，我仍然会记录第一印象。只是不会急着把它们都定义为问题。
先看系统怎样运行，哪些人依赖它，过去为什么作出这些选择，再判断什么值得改变。这个顺序通常比快速证明自己看得更清楚重要。