阿里参观是怎么定制的
我的建议是，对你所负责的系统，它关键的上下游、核心业务的链路一定要熟悉，包括数据、接口（调用、功能、逻辑）、各种异常的处理和特殊的设计。能帮你达
成这一目的的简单的办法就是画图、画图、画图！重要的结论说三遍，一定要自己能把系统的大图画出来，然后做到可以根据大图随意放大和缩小。放大到将链路画
到业务场景里，突出业务逻辑和上下游交互，缩小到某一次调用的处理逻辑大致是怎样，数据是怎么变化。
经常画图，不用纠结形式和标准，重要的是形成自己理解系统的一个框架，一个自己的思维方式，需要的时候可以随时拿出来用。
日常不管是聊需求还是做系统设计，习惯性的把图画出来，就达成了一半。剩下的一半就要看图去想、去找问题。
3.技术债务
永远不要骗自己说，现在为了这个需求先挖一个坑，过一段时间再来填（重构or重做）。
技术债务和金融债务一样，它必然存在，并且会像无赖一样一直赖着，隔三差五会爆发一下。随着时间的推移和业务的发展，你会发现架构越来越混乱，不同系统的
领域边界越来越模糊，系统和需求与组织关系的映射越来越复杂，服务内编码风控越来越不一致，重复的轮子一个接一个隐蔽的出现。
“太忙了没时间梳理哪些问题”、“改那些问题需要上下游一起改，费时费力，推不动”、“现在还没出问题，而且正在整理了，别催”。这是我们经常会听到的声
音。其实，技术同学多0少都有点代码洁癖，有很多问题不处理不是主观的原因，而是客观上因为精力、时间、ROI等因素，往往要等问题真的爆发后，大家才能狠下
心去处理那些问题。?