假设 MKH 项目要重构的 13

个要点
1 、构建 springboot-common-starter 包
• S3Service 已经在多个项目中重复出现，应该抽
取到 springboot-common-starter 包中（或者 co
mmon-utils 中）， maven 库中只维护一份，组
内所有项目共享
• 基本环境的配置 bean 在多个项目中重复出现，应该统
一纳入 springboot-common-starter 包中
利用 SpringBoot 自动化配置的能力
@Bean
@ConditionalOnBean(ObjectMapper.class)
2 、构建 common-domain 包
• 在多个项目中重复出现的相同的 domain(lesson,class,school…) 、 E
num 应该抽取到 common-domain 包中， maven 库中只维护一份
，所有项目共享
• 考虑到跨项目的交互， domain 中应该只封装常用不常改的数据
库表映射实体， Enum 封装业务常用的各种状态字段
3 、构建 common-utils 包
• 在多个项目中重复出现的相同的 utils （ JsonUtils ）应该抽取到 co
mmon-utils 包中， maven 库中只维护一份，所有项目共享
4 、自定义组合注解
• 重构要点：把组内项目常用的业务耦合的 N 个注解合并为一个
• Negative example
• Positive example
5 、弃用 JPA+JSONAPI
• 支付宝 API
• https://docs.open.alipay.com/api
• 微信公众号 API
• https://mp.weixin.qq.com/wiki?t=resource/res_main&id=mp1445241432
• ZOOM API
• https://zoom.github.io/api/
• 特征
• 正常
• status=200,{“body”:”...”}
• 异常
• {“code”:“30001”,”message”:” 请求 XXXid 为空” }
• Mybatis,Spring-JDBC 的优势
• 完全使用原生 SQL ，可以利用 MySQL 各种语法上的优化特性（例如 forc
e index ）
• 使用 XML 维护 SQL 语句，规范明了（ JPA 在使用原生 SQL 时，大量 SQL
暴露在外，用某位同事的观点阐述：不美观，不简洁）
• XML 中的 SQL 语句具有半文档的业务作用，对接替、维护工作的新人非
常优化，可以通过对这些 SQL 的学习快速适应业务
• MyBatis 在映射数据时不会构造过多对象，查什么存什么，省内存
• 数据量更大时， MyBatis 和 JPA 哪个更快 ?
• https://mp.weixin.qq.com/s/dUMXl-KaZPbiEDr5zoRqGw 芋道源码作者
6 、分布式、微服务架构的引入
• 好处此处不再赘述
7 、弃用 memcache, 全面拥抱 Redis
• redis 5 种数据结构的灵活运用，能够分摊大量排序的工作，减轻
服务器的压力
• 分布式锁的应用
8 、分布式配置中心的应用
• 目前同一份配置在多个项目中重复出现，用分布式配置中心（ ap
olo 、 nacos 、 zookeeper ）都可以一次配置，所有项目共享
• 项目要结合实际业务，多做开关功能，现在分布式配置中心或者
Redis 都具有这样的能力
9 、避免过于消耗服务器资源的开源技术
使用
10 、组内新技术引入投票制
• 推荐 Jimmy 、 超哥、 David 、鹏飞组建组内技术栈投票决定制度
• 1 、所有项目使用的基础技术
• 2 、因新需求带来的是否要引入某种新技术、组件
• 3 、任何人不得私自引入新技术、组件，统一按照规范进行开发
• 如果真理往往在少数人手中，公司成立的技术委员会是茶话会么
11 、项目分层的思考
• 现状
• 阿里的项目分层
• 原则：不跨级调用、单一职能
• controller
• service
• userservice （单一业务）
• 只依赖 userdao ，由 userdao 提供 CRDU 的能力，跟 user 有关的业务封装到 userservice
• userclassservice （复合业务）
• 依赖 userdao 、 classdao ，提供复合业务的能力
• dao
12 、异常包的统一封装处理
• 现状
• 框架组封装的 Exception 不全，不能完全满足日常业务使用，常常要自行
封装异常
• 自行封装 common-exception ，或者加入到 common-domian 中
• 集体讨论，共同给出哪些异常是日常开发中必须使用的
13 、对于框架组提供的支持包
• 不熟悉、不使用的包可以不引入依赖
• 加强与框架组的联系、沟通，知道框架组提供的包都有哪些能力
，哪些要用，哪些不要用，不盲目引入，加重项目规模，影响 CI
的速度
写在最后的话
• 感谢 Jimmy 哥给了这个表达自己想法的机会
• 很多技术的认知平时不说不代表不会不懂，有的人喜欢表现，我
就喜欢低调，表现出来的就一定厉害？低调的就一定不好？
• 我建议重构，我拿出了重构的意见
• 有人说 XXX 性能不行，那么哪里性能不行？为什么性能不行？如
何解决这种性能不行？
• 脚踏实地的执行比什么嘴上空炮都重要