32 | 应用的改进：如何改进我们的软件设计？

我们正在重构一个40多万行的应用，这个应用的开发，产品，业务都走光了，现在团队有的开发要重写，有的开发的意见是不动老代码，两种意见，我都是反对的，全部重写不现实，一个跑了5年的系统，需求根本没人弄的清楚，就算弄清楚需求，重写代码，就能做的更好？设计水平达到了吗？另外，不动老代码不现实，很多新需求，虽然是新需求，正因为设计的不好，不得不动老代码。面对这样的困境，我们还是采用小幅重构的办法，我们做了重构方案，目标清晰可落地，效果可检视。我们对重构进行分类。 1.瘦身，瘦身就是把系统的各种接口，页面接口，服务接口，job，通过监控统计已经下线的功能，把代码删除掉，最近一年没有访问的请求，把代码删除掉。另外，通过表，sql反向梳理，就是表里没有新数据，sql最近一年没有执行过，把这样的代码都删除掉。 2.重构，精准重构，1个是性能，梳理接口，统计超过一定阀值的接口，根据成本收益原则，确定优先级，分布实施，1个是功能复杂度，统计最近1年每个源代码文件提交的次数，我们的依据是开放封闭原则，一个类被频繁修改，就说明设计存在问题了。 3.新需求，新应用，对于业务领域是个全新的子域，我们坚决开发新应用解决，另外我们计划做服务标准化，对于新接口和服务，通过一个新应用实现。同样的遵守开放封闭原则。 我们已经重构了半年，下半年还要重构，我认为明年也要重构，重构得到领导的大力支持，我相信也是提升团队设计，开发水平的机会，加油吧！

10年+复杂系统改善坑： 坑一：需要同步修改的点无法确定，如：上层接口变化导致下游未同步、数据源变化（分析人员方了）； 坑二：面条逻辑，数据库、后台服务、前台、网关均有逻辑 坑三：神一般坏味道，if能在屏幕左侧写到右两屏的那种 坑四：红线需求层出不穷 坑五：替换了依赖组件版本、修改底层一行代码，平台直接起不来 然后，我们的解决方案大致如下： 止损： 1、建立规范，防止代码分层不明确、代码风格迥异 2、防止平台出现大变动 3、更新底层、尽量以新的能力承载，然后慢慢迁移到新的实现方式 4、外部基础组件版本不允许变化 搭建安全网： 1、建立后台服务接口监控 2、建立核心业务流程自动化测试流程，防止挂的太离谱 3、建立验收环境，上线版本必须在该环境进行验收测试 落地实施： 1、先拆基础服务，文件、消息等。 2、新业务关联性不强，另起炉灶 3、将代码中的阈值一律移入配置管理，不允许写代码中 4、业务侧发起，哪些功能不要的，直接砍、删---做好长期战斗准备 5、建立核心业务平台标准接口(业务上做调整)，外部平台陆续迁移新接口 6、数据库中单表超20个业务含义字段的都是危险分子，分析职责权属 7、让资深业务、测试、开发周期性来培训团队系统都有撒撒撒，他们重点关注的撒撒撒 重构项目需要有愚公移山的精神，然后每次就来一点点。

个人补充: 1.项目质量的好坏，与公司发展情况，项目价值息息相关。在业绩不好的条件下，举债前行就是合理的。所以我们讨论项目质量，谈设计和重构，都是建立在价值和公司业务发展需要的前提条件下的。(反之，逆势而为有违天和，事倍功半) 课后题: 1.问题: 最大的问题就是缺少共同设计。 2.解决思路: 开发与产品间的沟通应该基于统一、公开的业务建模。 3.问题描述: 产品和开发之间沟通都是基于一个个零散发散的功能点。在系统和业务间没有做一定的模型抽象。导致开发不了解业务全貌，产品不理解系统现状。进而在知识传承的成本就很大。往往新产品出的功能很难兼容现有系统（复用已有能力和兼容其他已有功能）;新的开发也很难看清系统的全貌。（进而问题就多，问题多团队氛围就比较差，就容易扯皮） 4.价值: 产品需要开发通过模型勾勒出系统的现状，屏蔽掉实现的复杂度。开发需要产品通过模型屏蔽掉无关的业务复杂性，串联整体业务脉络，快速准确的理解业务全貌。如此也有利于新人介入，知识传承。 6.外在问题: 因为不是一个人的事,所以天时地利很重要,同样的时间也可以做很多事情,没必要吃力不讨好不是。 旁外话 郑烨大佬的专栏都是金玉良言啊，不温不火着实费解。

公司以前业务是2C，后来钱烧完了，开发人员走的差不多，现在做2B。 但把各个服务拆的非常细，几十个微服务，，几个人维护，现在也不敢做的大的改动。 想了想问题： 1. 微服务拆分的太多，各种服务之间RPC调用经常超时 2. 各个服务报错之后，没有事务和补偿机制，存在数据不一致问题 3. 微服务相关调用，一个服务挂了，好多功能停摆，无法用 4. 监控体系没有做，各种服务的状态和接口的调用情况不清晰 5. 服务熔断、链路追踪等没有 有时候，我在想，2B业务量不大，不如保持现在各个微服务的样子，只是不再一个个部署了，合并到一个进程里面跑算了（相当于模块化开发，把RPC调用禁掉）。只是有点回到老路的样子，大家有些不甘心。

我非常赞同从改进一个小的模块设计开始，不断地小步前行的做法。 我最近也是在重构项目，虽然是APP项目，但这个项目很大，安装包已经有200M。 因为需求复杂，经历人员也比较多，结构设计也没有统一，有使用rxjava，dagger，MVP等等框架，交互层和业务层的逻辑交织在一起，改一个bug相当得耗时间。 现在第一步做法是梳理模块，统一每个模块对外的接口，这个改动目前来说是最小的，也是更进一步改造的基础。 曾多次问自己如果重新开始我会怎么设计这样的问题。其实回答这个问题可以帮你更好的理解现有系统的业务逻辑，也是你重构的目标，重新设计它是一个理想状态，不可能一下子就达到，但是可以不断地逼近目标。

这一片真的是感触很深，当前我们团队正在进行一个项目的改进，之前是甲乙双方合作的，二次开发的商业产品，这个产品存在很多问题，扩展性低、代码未全部开源、我们掌控力不足，而且目前也没有乙方运维支持。属于公司战略项目，正在扩展全集团使用，因此推倒重来是不可能的，我们决定只进行架构扩展升级，在现有基础上增强，新旧业务分开，页面嵌入形式（用户无感知），基础数据、支撑域等用现有的（确定改进目标），问题是开发人员有各自任务，而且原系统掌控力不足，因此我们决定从几个方面入手：1.梳理现有系统开发模式，和可以了解的部分，2、做登录集成，保证新旧系统登录状态一致，页面一致，3、保证现有支撑域共享，4、后期做好新旧业务区分，找到分离关注点。学习来事的课后发现，虽然大体方向没问题，但是细节上有欠缺，比如分离关注点太粗等。

“微服务应该是结果，而不应该成为目标。” 怎么理解这个呢👆🏻

目前还没有重构老系统，感受不是很深，后面再来深度感受

改进既有设计，从做一个正常的设计开始，小步向前--记下来

自己也独立负责公司的一个系统模块，看前几篇专栏时就在想这个系统的设计有什么不足，哪里可以改进优化，如果能够重新设计可以是什么样，今天这篇专栏正好就说了这点，真棒！后续设计改进正好借鉴起来。