加餐十 | 如何接手一坨烂业务代码？如何在烂业务代码中成长？

不知道作者有没有在小公司工作的经历，我感觉所有的问题，归根结底都是人的问题。人的素质高了，再难也能一步步解决，因为大家都是奔着解决问题去的。 人的素质不行，再简单的问题，也能搞成无解，中间各种推诿，甩锅，真的是不厌其烦

加餐的文章还是挺有收货的,都是争哥工作这么多年的感触

业务建模，该从哪些方面去考虑考虑？争哥有没有推荐资料？

争哥，能说说梳理业务的一些技巧吗，包括产出一些技术文档

1.只要你编码意识在提高，接手烂代码应该是常态。 2.这次有幸和业务架构师合作搞中台。（这算不上我理解的中台，只是这么叫而已） 3.首先说一个问题，业务架构师在领域的理解和建模上都很不错，但是在实际开发落地却显得有点刚。我们知道，老单体拆解往往是从圈表开始，这就先动了数据结构。然而既然是烂代码，它的隔离性必然不好(业务层直接调dao层，dao层做数据分发等待)。那么改了数据结构，连带的一切都受牵连，置底向上的重构代码，往往很难发挥新的数据模型的价值，而且这个工作量还很大，把数据迁移算在内，可能2-3个月就这么一层都不见得能重构成功。而对外这一层重构的价值是很不明显的。干2个月，没有看得到的成效，可能就要被砍掉。 4.也感谢团队和架构师的认可，整个中台改造的规划以我的方案为基础。我们做中台是为了增效，主要两个方面。首先，已有业务功能要可以复用（业务流程的可控制，功能的可编排）；其次，新功能的加入要尽量少受原有代码的影响（提供扩展性，隔离复杂性或者说分离关注点）。所以我也就这两点自上而下做重构。首先，搭建最外层编排功能的调度层；接着，对已有功能和策略做标准化的适配（适配器:统一多个类的接口设计）,这里既有适配和参数转换的工作，也有部分"大方法"拆解重构成小的标准方法的工作。那么一期的重构就在上层编排层的实现和已有功能的适配，加上部分"大方法"的拆解。整个工作差不多在2-3礼拜就能完成。后续的工作就是对每个适配的标准化接口做实现上的重构。（这里数据库的表结构不做变化，但新的功能会基于抽象的领域模型来实现<领域模型到do会兼容老数据结构的转换>。当所有功能基于领域模型实现完后，再对领域模型到do这一层做重构，圈表拆表合并表。） 5.以上，2-3周我们的重构就可以跟着版本迭代发出去。上游编排支持新流程的诉求也能满足。后续工作就落在每个标准功能的重构上，关注点比较收敛。（同一时间，重构过程里也把技术相关的代码抽离业务代码，重定义本项目的dto<老项目没有dto的概率，对外的api包啥都有，有do也有其他组api包的do，非常恶心>） 6.实时上，我认为做重构重来都不只是开发的事。像栏主这样捏着鼻子啃烂代码梳理业务逻辑，我也干过。不同的是，我一直都拉着产品对业务逻辑。重构过程会换业务逻辑实现，甚至会删除整块已经没什么价值的功能。一个项目烂，开发是主要原因，产品也难逃其责。

回忆目前为止我主要经历了三个项目，仔细归类的话，这三个竟然还都有所不同。 第一个项目，是我刚毕业时候进到项目组的，是一个Android App项目。之前App项目的主要业务逻辑是通过JavaScript编写的，Android端调用webview展现即可，所以很多流程都是依赖于其他小组。 刚好领导们觉得有必要全部原生化，就让我赶上了重构的时代，说是重构，其实就是对之前在JavaScript 上的业务迁移到Android原生上。 也很庆幸那个项目一开始做的就比较好，文档之类的相对来说也齐全，做主流业务的同事一直在项目组里，哪怕文档里没有的业务，自己总结起来抽时间麻烦他，也能得到自己想要的答案。 也许是注定需要给我一次锻炼的机会，在重构初始，我的师傅当时的Android端负责人因为身体原因休息了一个多月，就让我这个徒弟去接手了当时复杂的，核心的业务，得到了一次快速成长的机会。 就这样坑次坑次完成了我人生中第一次商业化项目的重构，因为项目很庞大，经历了几个月的加班加点，上架的时候狂松了一口气。几个月的努力终于看到了回报，因为前期准备的材料都很充分，这次重构对初入职场的我是很大的能力提升。 第二个项目，是我去新公司之后的项目，做一个即时通信的项目。 我来公司之前，有一个即时通信的在用，是基于Flash编写的，从响应速度和稳定性来说都没有让领导和用户满意，当时项目组里的后端都是PHP，领导想内部发掘Java的员工来，所以，我的第二次能力提升就在这个时候出来了。 我到公司的时候是Android开发，因为当时项目组有3个Android，没有Java，领导在征求大家的建议，问有没有想转的，我分析了自己的情况之后，主动要求转Java，和老大一起去做这个即时通信框架。 我们两个选择Netty框架来进行，又一次加班加点的拼命时刻到来，这次没有文档，只有代码，也还是有幸运的部分，之前框架的负责人还在岗。 难点就是，我需要看懂Flash的代码，然后一步步迁移过去。不过也有一点遗憾，整个框架是老大搭建好的，我的核心任务是在计划的时间之内，完全迁移即时通信的功能，然后把项目跑通，调试上线完成。 所以还是有那么点遗憾，搭建框架的时候我没参与，但不妨碍我对Netty的理解，为此我还在付费购买了Netty学习的一个专栏，加深我对Netty的理解。 从客户端转到后端，给我最大的感触就是我看项目看的范围更大了，之前客户端只是很片面的看到自己所负责的功能，后端能把整个项目都看透了，尤其是业务方面的知识点。 给我最大的教训就是：后端编码和客户端还是存在不同，因为我的不熟练，在项目上线的第一个晚上，因为扛不住峰值的压力，把网站给瘫痪了，业务宕机了一个小时，也是老大帮我解决的，给我当头一棒，原来代码不是这样写的。这也是让我坚定，在做业务的同时，需要持续的精进自己的技术。 第三个项目，是最近几个月在做的，帮公司的合作伙伴半路救急。 一开始是在他们外包的项目上进行接口的新增，但是外包的项目估计收钱给代码之后就不来管了，让我在新增的时候做的很痛苦。没有文档，没有业务说明，只有一个勉强能用的App，以及一份新需求的文档提供过来，全程懵逼，这就是项目？ 没办法，硬着头皮做呗。加了两个多月的班，完成了近40个接口的编写和调试，过程很痛苦，遇到问题问对方的负责人，他也只是一知半解，所以只能自己通过数据库，通过简单的注释进行编写，苦啊。 完成第一版之后，老大和我们着手进行重构，现在正在进行中。根据App提供出来需要使用的接口，从接口中重构代码，完善文档，把代码分层，轻便化。 因为项目复杂，又拉动了一个比我工作经验更丰富的C++转岗到Java，减轻了压力，也感受到转岗同事的超强适应力，给我的警示就是争哥在加餐里说的：**觉得自己做得很好，领导不识货，同事都没他强**。我有部分符合，所以以后还需要虚心写代码，提升技术，冲冲冲

刚接手一个这样的项目，没办法，也是读代码，梳理代码逻辑，然后再拉上产品对比很久不更新的文档，最后总结一个新的文档，同时把代码中不合理的地方重构掉。希望我们的文档可以持续维护

这个专栏不仅可以学习知识和技术，还有端正态度，纠正“价值观”的“正念”效果。

最近接手的一个项目，真的是一堆烂代码，业务员逻辑又复杂无比，只能是硬着头皮去啃了

年初加入一家公司，项目差不多有5 6年了，几乎没有任何的文档，熟悉该项目的产品经理，程序员几乎都离职了，唯一熟悉的老大每天又很忙，不能经常问他，实在是太痛苦了，不敢动，不敢改，数据库字段也没有注释，代码写的很随意，果断跳槽了，我之前写代码也特别不注意规范和命名，自从来了新公司，虽然公司不大，后端开发差不多就三个人，但是代码结构看起来非常的舒服，命名规范，老大还是对我写的代码进行CR，老大是一个非常注重细节和规范的人，对自我的提升还是挺大的，有时候工期紧张，保证代码规范还是有一定的难度的，都是先上线再说~