梳理业务代码的重要性

#背景#

线上业务出现问题，排查代码和业务流程发现了代码问题，当然开发代码的人已经离职。你接手负责这个业务模块后也并未动过历史代码。当然最终是你的责任，毕竟现在这个模块功能是你负责。

是不是感觉很委屈？

这样的场景还有很多，相信很多人都遇到过类似的经历。

做为一线敲代码的你，那如何避免？

1、首先你得清楚，你的责任边界是什么？

2、对负责的功能和业务是否了解？

3、是否清楚负责的功能和业务是否有什么风险？

4、如何避免这些风险？

冷静2分钟想想上面的4个问题，下面分析拆分下

1、首先你得清楚，你的责任边界是什么？

这个问题一定要明确，记得，那怕不你是的编码，但功能和业务模块已经分配确认后，那你需要对其负责。想想如果你是市长，负责本市的民生，本市发生暴乱你不能说是上任负责，那上任搞出来的烂摊子也是同理。

所以先不要有抱怨或者抵触心理，首先需要明确范围。那些功能模块属于你负责的？那些边界不清晰的？做好任务划分避免出问题的时候说不清。

2、对负责的功能和业务是否了解？

分好地盘后，做为负责任的市长是不是需要了解本市的人口情况，男女比例，小孩、中年、老人比例，了解本市的经营情况，多少个项目，有没有烂尾项目等等。

那做好模块边界划分后你也需要去了解模块对应的场景，实现逻辑，设计方案，代码实现。这些是需要优先去做去了解的。

你或许觉得做需求任务的时候在去了解，梳理和设计。那如果你不前置了解的话，那这个地方有没有坑你是不清楚的，业务和产品提出的功能是否能实现？这些都是不清楚的，等开发一半的时候才发现原来不能实现，需要改产品方案甚至缩减业务需求，这样的场景可自行体会。

如果线上用户发现账单存在问题，而你并未提前了解业务，对于问题的定位和分析都需要现场翻代码，线上有大量的用户投诉，领导在你身后盯着你解决，这样的场景再自行体会下。

所以对于自己负责的业务需要清楚，业务流程需要了解，代码实现更是明白。做不到全部记到脑子里那也需要清楚流程和代码，这些都是建立在你平时的积累和总结的基础上。

尝试把梳理的业务和代码逻辑整理成文档，并时不时把总结的部分提炼分享出来。可以是导图，或者现场在白板上边画边分享。强化自己的理解和分享能力，同时让提升自己的技术影响力。

3、是否清楚负责的功能和业务是否有什么风险？

市长在了解本市情况后，需要知道知道那个地方需要重点关注，是否有莽村，那里容易发生暴乱等。在对自己负责的业务场景清楚的情况下，需要更进一步了解业务可承载的业务量级是多少，超出后会不会把系统打挂，有那些直连数据库的会不会把库打挂，如何避免业务不可用，加限流还是容器扩容。涉及用户券、账单、放款等敏感信息是否有风控，是否有旁路验证，是否有降级，业务优化级等。这些都是需要对业务系统有足够认知后才能识别出来的。

识别出来后需要优化技改，按优先级去处理，很多公司不会留专门时间进行维护，那需要需求和技改并行来实现。或者并技改合到需求中去做。这个前期会比较痛苦，但处理完一定量级后会越来越轻松。

你想那怕你背一本英文字典，那也是有数量的，你负责的模块也是有量的，这是积累沉淀的过程。

4、如何避免这些风险？

这个一方面说的是识另出来的风险，做优化和技改，另一方面说的是如何不会边出现边填坑边挖坑的情况。你优化完一个，别人给你在挖一个，这谁也受不了。所以要有大局观，

记住负责的业务和模块自己有决对的决策权，别人在涉及改动的时候你要清楚，而且要按自己的想法来实现，不是专横，而是有理有据。除非有更好的方案，并且是你认同的，否则不能妥协，像别人有需求，需要改造你负责的模块，但为了省事，很多模块都没有设计直接写死，一大堆判断，对于后面维护的人来说非常痛苦，而你就是后面维护的人，所以有些变更非常大的改造涉及你负责的模块一定要有你的同意或者你参与决策。你才是负责人。

后面会针对如何梳理，梳理技巧做下总结