今天跟无线的两位同事一起过我们的需求，变更和故障，体会到站在不同的层级能获取到的信息，以及关注点都不太一样，需要更多的从用户使用的角度，从历史演变有大局观的去看待这些新引入的变化。
包括我们一开始的架构设计，比如，咱们统计功能架构的设计，从这几年的功能演变来说埋下不少坑，曾经的很多历史遗留问题，换做今天来做决策时，如果不通盘考虑，也一样会有这样那样的问题。
说到底，对于现有这样庞大的维护性项目来讲，每写一行代码，都需要想清楚他的波及影响，以及在各种场景下能否达到你的要求，这样的评估越是准确，细致，对于未知问题的引入就越可控，而越是能做到可控，就越是能消除更多的不稳定和不确定性。
想起之前和小伙伴们聊天提到的，宁愿花两周时间沟通清楚一个需求，到最后哪怕一行代码也没有写，不愿意用一周时间写2000行代码来解决问题，那些个看似简单的解决方案，往往只能解决眼前的问题，却给自己埋下诸多隐患。代码并不是解决问题的最好方式。

今天跟大家沟通的途中，再一次感叹知识库的妙用，如果没有这样的一个知识沉淀和管理系统，很难想象，这么多的需求变更要从哪里查实，一些平时看起来不经意的小事情却总能在最关键的时候起到很好的作用，为大家一如既往的支持点赞。

今天补丁顺利发出去，节奏感慢慢找回来，事情又能慢慢理顺，这样的感觉棒棒哒！

图片发自简书App