阿昌喜欢吃黄桃的博客_CSDN博客-408,JavaSE,MySQL领域博主

原创阿昌教你看懂mybatisplus的sql语句的创建过程

前言前置版本：MybatisPlus3.0.5前些日子，阿昌写过一篇【mybatisplus的SqlSessionFacotry的创建过程】的菜鸡文章，这里我打算再记录一篇，关于mybatisplus的sql语句的创建过程。前戏同样，学过springboot的人都知道，如果要整合什么框架，肯定要去找XXXAutoConfiguration。在MybatisPlusAutoConfiguration中有如下，对SpringIoc容器进行注入sqlSessionFactory在这个方法中，他

2021-11-23 18:36:55 3469 7

原创 Day973.授权码许可类型中，为什么一定要有授权码？ -OAuth 2.0

从为什么需要授权码这个问题开始讲起，并通过授权码把授权码许可流程整体的通信过程串了一遍，提到了授权码这种方式解决的问题，也提到了授权码流程的通信方式。总结来说，以下两点。授权码许可流程有两种通信方式。一种是前端通信，因为它通过浏览器促成了授权码的交互流程，比如京东商家开放平台的授权服务生成授权码发送到浏览器，第三方软件小兔从浏览器获取授权码。正因为获取授权码的时候小兔软件和授权服务并没有发生直接的联系，也叫做间接通信。另外一种是后端通信，在小兔软件获取到授权码之后，在后端服务直接。

2023-06-05 23:06:33 128

原创 Day972.OAuth 2.0是要通过什么方式解决什么问题？ -OAuth 2.0

OAuth 到底是什么，为什么需要它，以及它大概的运行逻辑是怎样的。OAuth 2.0 的核心是授权许可，更进一步说就是令牌机制。也就是说，像小兔软件这样的第三方软件只有拿到了京东商家开放平台颁发的访问令牌，也就是得到了授权许可，然后才可以代表用户访问他们的数据。互联网中所有的受保护资源，几乎都是以Web API 的形式来提供访问的，比如极客时间 App 要获取用户的头像、昵称，小兔软件要获取用户的店铺订单，说 OAuth 2.0 与安全相关，是用来保护 Web API 的。

2023-06-03 15:42:02 88

原创 Day971.为什么要学OAuth 2.0？ -OAuth 2.0

开放平台相关的技术，主要包括网关、授权两块的内容。在开始的几年时间里面，一直都认为是开放平台的核心，起到 “中流砥柱” 的作用，毕竟网关要。随着对开放平台理解的不断深入，要想在开放平台支持更多样的业务场景，才发现网关和授权同样重要，相当于开放平台的 “两条腿”。而对于授权 “这条腿”，它不仅要像网关一样要承载访问量，还要同时兼顾业务场景的发展。什么样的业务场景呢？类似的微信登录就是其中之一，越来越多的，来。而这个解决方案的背后原理，也是要讲到的。

2023-05-18 23:21:18 73

原创 Day970.数据库表解耦 -遗留系统现代化实战

一张表格，对比了拆分查询 SQL 的三种方案，以及上面没有提到的一些优势和不足。结合自己的实际需求，对照表格选择更合理的方案。解耦数据库表的方法都是基于查询的 SQL，对于 INSERT、UPDATE 和 DELETE 的 SQL，也可以用 API 调用来取代。

2023-05-16 23:24:24 261

原创 Day969.如何拆分代码 -遗留系统现代化实战

反向代理”和“数据同步”是之后的基础，微服务拆分的方方面面都离不开这两个实践。如果数据库是 Oracle，强烈建议使用基于 DBLink 的同义词来进行“数据同步”。其实严格来说，这并不算是同步，而只是一种转换，但它可以让暂时不用考虑数据的问题，降低了认知负载的同时，还能帮梳理数据的所有权。等代码解耦完成，在核保库中所创建的同义词，都是需要拆分到核保库中的数据表。除此之外，还分享了“用 API 取代代码依赖”，这也是比较基础的一个实践，是代码解耦的基本方法。

2023-05-15 23:21:21 200

原创 Day968.如何开启一个遗留系统现代化项目？ -遗留系统现代化实战

讨论了如何开启一个遗留系统现代化项目。花了不少篇幅去梳理开启项目的步骤，需要先对不熟悉的业务进行梳理，得到初步的用户旅程或用户故事地图；再通过动名词法等工具，对系统进行战略建模，并设计出目标架构；然后选择一个端到端的业务进行试点，并以假设驱动的方式寻找合适的现代化方案；确定目标架构以及制定演进计划，并按照计划逐个迭代地增量演进；最后，每个迭代都需要得到充分验证。目标很明确，就是要把核保业务从单体大泥球架构中拆分出来，形成具有独立数据库的微服务。这已经是个非常艰巨的任务了。

2023-05-14 14:17:47 266

原创 Day967.团队拓扑学 -遗留系统现代化实战

一种全新的团队结构模型——团队拓扑学。所以在它后面加了一个“学”字，是因为它相比特性团队和 Spotify 模型，更接近一门学问。它提出的团队认知负载和团队优先的理念，更是超前于这个时代。组件团队、特性团队、Spotify 模型或团队拓扑，它们并不是相互替换的关系，而是可以按需合并和剪裁的。它们面向的问题域不同、目标不同、出发点不同，因此不存在谁比谁高明的情况。一张表格，总结几种讲过的团队类型，做个参考。应该根据自己团队的实际问题，找出合适的方案。

2023-05-11 23:37:07 276

原创 Day966.从组件团队到Spotify模型 -遗留系统现代化实战

Hi，我是阿昌，今天学习记录的是关于的内容。。这个方向跟管理有关，但无论掌控全局的 CTO、架构师，还是身处遗留系统一线战队的队员，都有必要了解现代化团队结构是什么样子的。这是因为遗留系统的现代化，除了技术调整，也离不开人的因素。在维护遗留系统的团队，结构往往并不合理。直接后果就是给软件开发的质量与速度拖后腿，长远来看，还会让我们的架构规划无法落地，回到满是泥潭的老路上。

2023-05-11 00:17:03 337

原创 Day965.从持续集成到持续部署 -遗留系统现代化实战

分支策略。这是一个充满争议的话题，每次对于 GitFlow 的批判，都会引发热议。只有应用了主干开发，遗留系统现代化的增量演进原则才能更好地贯彻。每次增量演进都能及时 PUSH 到主干，从而过一遍持续集成流水线，并部署到各个环境。而如果是特性分支策略，会不自觉地等着全部完成后再合并代码。灵活的分支功能是 Git 的一大亮点，但它并不是为了开发特性而设计的。利用特性分支在本地长期保存多份代码版本，这是对 Git 分支的滥用，增加了不必要的认知负载。

2023-05-09 23:06:05 563

原创 Day964.从持续构建到持续集成 -遗留系统现代化实战

如何在一个没有持续集成流水线的遗留系统中，逐步搭建基础设施，从持续构建开始，慢慢做到持续集成的初级阶段。这其中包含很多工作习惯的改变，比如任务分解、小步提交等，一开始你可能并不适应，但要知道，只有做好任务分解，才能做到小步提交，才能做到持续提交代码并持续构建。这些都是 DevOps 文化的一部分。一个遗留系统要想真正做好 DevOps 现代化，就必须转变思想，摒弃成见，彻底拥抱 DevOps。七步提交法，图解，供参考。在做到持续构建之后，可以逐步引入分级构建、制品晋级等实践，慢慢向持续集成演进。

2023-05-09 00:57:18 469

原创 Day963.如何拆分数据 -遗留系统现代化实战

Hi，我是阿昌，今天学习记录的是关于如何拆分数据的内容。，这个场景在建设新老城区，甚至与其他城市（外部系统）交互时都非常重要。作为开发人员，理想中的业务数据存储方式是什么样呢？当然是负责一个业务的数据都在一张或几张名称相关的表中，这样通过名称就可以一目了然，查找起来很方便。不过很遗憾，现实有时候总是事与愿违，遗留系统中负责处理一个业务的数据，有的放在这张表，有的放在那张表，总是不在一起，名称甚至都没关系；而一张表中也有可能存放几种业务的数据。

2023-05-07 16:35:07 362

原创 Day962.如何更好地重构和组织后端代码 -遗留系统现代化实战

修缮者模式和绞杀植物类似，可以用来改善单体内的某个模块。抽象分支模式可以通过一个抽象，优雅地替换旧的实现。扩张收缩模式主要用于接口无法向后兼容的情况，一张一缩，一个接口就改造完了。同时，除了代码中的接缝，架构中也存在接缝，可以利用它们来实现架构中的替换。无论是绞杀植物、修缮者、抽象分支还是扩张收缩，它们在实施的过程中，都允许新旧实现并存，这种思想叫做并行运行这是贯彻增量演进原则的基本思想，希望能牢牢记住。

2023-05-05 21:52:54 360

原创 Day961.老城区前端改造 -遗留系统现代化实战

遗留系统前端的特点，以及前端重构的八个步骤，分别是：梳理业务、模块化、重构 JavaScript、移除 Scriptlet、引入前端框架、前端组件化、前端工程化和 API 治理。最后，为了在旧页面中更好地集成新的前端组件，粗略地了解了微前端技术。在重构前端的时候，对开发人员的要求是很高的。如果他只会前端，可能无法移除 Scriptlet；如果只会后端，也许可以按重构 Java 代码的方式重构 JavaScript，但却很难对前端进行组件化和工程化，更别提什么微前端。

2023-05-04 22:18:47 541

原创 Day960.架构现代化-微服务 -遗留系统现代化实战

如何选择遗留系统的目标架构，到底是单体合适，还是微服务合适呢？看起来“二选一”的题目，还有更适合自己业务的隐藏选择么？拆与不拆，要看认知负载。拆成什么样，要按步骤演进。除了微服务，基于组件的单体架构和基于服务的分布式架构也有可能是大泥球单体的最终目标，如何取舍主要还是看业务上是否具有弹性需求。在拆分时，你可以使用基于组件的分解和战术分叉两种模式。微服务是个非常庞大的话题，很难在一节课中体现所有内容。奉劝你一句，拆分微服务一定要想清楚为什么要拆。

2023-05-02 19:09:23 1103 2

原创 Day959.架构现代化模式 -遗留系统现代化实战

从 Martin Fowler“灵光一现”发明的绞杀植物模式出发，接着学习了 Eric Evans 发明的气泡上下文和自治气泡模式，以及在气泡中可以使用的数据同步和访问方式，包括变动数据捕获、事件拦截和遗留系统封装 API。从气泡上下文，到自治气泡，再到微服务，这其实描述了一个新需求落地成微服务的演进路线。一步到位地去开发一个微服务，认知负载偏高，而且你可能也并不需要。按需演进地去开发，认知负载就会低得多，也更容易得到一个刚刚好的架构。有很多新需求都可以通过气泡上下文来构建，比如报表、问卷、评分等。

2023-05-01 23:04:59 394

原创 Day958.代码的分层重构 -遗留系统现代化实战

遗留系统中常见的代码样例说起，将一个事务脚本一步步重构成了 DDD 中常见的分层架构。这期间穿插着介绍了领域模型、数据映射器、仓库、应用服务等多种模式。不管系统位于这个路线的哪个阶段，都应该有能力把它重构好。项目业务没有这么复杂，事务脚本也能解决绝大部分应用场景。没错，事务脚本本身就是一种解决领域逻辑位置的模式，这条路最终会走向混乱。有的时候，之所以觉得业务没那么复杂，是因为在脑子里将业务映射成了数据库表，那么写出的代码自然是事务脚本。

2023-04-29 12:59:05 1002 1

原创 Day957.重构“烂代码” -遗留系统现代化实战

重构手法和模式还有很多很多，之所以认为这两个特别实用，是因为在重构了大量遗留代码后，发现拆分阶段和方法对象是必不可少的中间步骤。当通过这两种方式完成了初步重构之后，还要审视一下代码，根据坏味道实现下一步的重构。方法对象的时候，穿插了如何使用快捷键来完成重构。可能会觉得记住额外的快捷键属于外在认知负载，其实不然。它们能够提高你的工作效率，而且一旦记住并且熟练掌握，就能一劳永逸。这种知识属于内在认知负载，是完成工作必须具备的技能。

2023-04-28 01:04:12 720 1

原创 Day956.代码现代化 -遗留系统现代化实战

首先学习了接缝的位置和接缝的类型。接缝的位置是指那些可以让 DOC 的行为发生改变的位置，有构造函数、方法参数、字段三种；而接缝的类型则是说改变 DOC 行为的方式，包括对象接缝和接口接缝。遗留代码中有了接缝，就可以着手写测试了。然而复杂的遗留代码很难去梳理清楚头绪，想你推荐用决策表的方式，将测试用例一一列出来。在遗留系统中，如果存储过程中包含大量的业务逻辑，传统的金字塔型的测试策略可能并不适合，可以多写一些端到端的 UI 测试，以及与数据库交互的集成测试（服务测试）。

2023-04-26 23:25:52 533

原创 Day955.到底是重构，还是重写？ -遗留系统现代化实战

遗留系统现代化的几种策略，不同的策略有不同的适用场景，总结到了一张表中。要记住的是，一定要根据项目的情况来选择不同的策略组合。不要上来就大张旗鼓地重构或重写，一定要弄清楚想要的是什么。除了重构和重写，其实还有很多选择。

2023-04-25 22:20:49 607 3

原创 Day954.以增量演进为手段 -遗留系统现代化实战

什么是增量？什么又是演进呢？这要从演进式架构开始说起。《演进式架构》这本书中给演进式架构下了精准的定义：支持跨多个维度的引导性增量变更的架构。这么多的限定词，乍一听挺懵。其中，多维度是指技术、数据、安全、运维等不同的看待架构的视角；引导性是指在适应度函数的引导下，向着正确的方向演进架构；而增量变更是指以小步快跑的方式，细粒度地构建和部署软件，同时在一定程度上允许新旧两种实现并行运行。这里说的遗留系统中的增量演进，借鉴了演进式架构中“增量”的概念。

2023-04-24 23:19:50 218

原创 Day953.以假设驱动为指引 -遗留系统现代化实战

假设驱动实际上是一种科学的研究方法，在面对一个问题时，先要分析问题，然后试着提出一种阐述或者假设，去解释我们的发现。接着就到了实验环节，如果实验结果满足假设，就证明理论是正确的。假设驱动的思想在数学、物理、生物等科学领域都是十分常见的方法，比如哥德巴赫猜想、量子力学等，最初都是通过假设的方式提出来，并在后期通过实验加以证明或验证的。实验是科学研究的基础，但并不是只有在实验室里才能做。在软件开发领域，同样可以做实验，这就是假设驱动开发。

2023-04-23 22:05:31 323

原创 Day952.如何降低认知负载 -遗留系统现代化实战

活文档（living document），顾名思义，就是指活着的文档，也就是在持续编辑和更新的文档，有时候也叫长青文档或动态文档。比如维基百科中的一个词条，随时都有人更新和维护，这就是一个活文档。与之相对的是静态文档，也就是一旦产生就不会更新的文档，比如大英百科全书中的一个条目。可以想象一下，在软件开发过程中，无论是瀑布模式还是敏捷，拿到的需求文档或故事卡是“维基百科”还是“大英百科”呢？

2023-04-21 20:42:13 405

原创 Day951.认知负载 -遗留系统现代化实战

认知负载的三个分类：内在认知负载、外在认知负载和相关认知负载。内在认知负载是指从事一项工作必须付出的努力，比如学习 Java 知识、前端知识等；外在认知负载是指知识呈现的形式，代码越糟糕、越难读，外在认知负载越高；相关认知负载是指人们要学习一个知识所要付出的努力，在软件开发领域就特指业务知识。其中，外在认知负载是最痛恨的，一定要尽可能地降低。在做遗留系统现代化的时候，所有的决策在制定之前都要思考一下，是否有利于降低当前的外在认知负载。

2023-04-20 23:18:01 334

原创 Day950.遗留系统的四化建设 -遗留系统现代化实战

本质上就是将先进的、现代化的软件开发方法应用到遗留系统上，让遗留系统重获新生、保持活力。是的，日光之下并无新事。遗留系统之所以成为遗留的，就是因为既缺乏现代化的软件开发方法，又没有随着潮流的发展而不断演进。遗憾的是，这里还应该引入一个“需求现代化”，但是在权衡之后我将它删除了。因为一个企业里的需求方与开发方是不同的部门，要想进行需求的现代化，必然要让需求部门参与进来。然而国内很多企业的需求部门和开发部门，还无法亲密无间地展开合作。

2023-04-19 22:16:06 377

原创 Day949.遗留系统之殇：为什么要对遗留系统进行现代化？ -遗留系统现代化实战

说了这么多，我们似乎已经有了一个很具体的关于遗留系统的画像了，参考如下：那是不是可以进一步抽象一下概念了呢？很简单，不妨直接看看维基百科是如何定义的吧：在计算机领域，遗留系统是一种使用旧的方法和技术的、过时的，却仍旧在使用的计算机系统。而 Gartner 给出的定义是：基于过时技术但对日常运营至关重要的信息系统。嗯，有信息重合，找找关键字：旧的、过时的、重要的、仍在使用的……这里找找对应的例子，辅助下理解。不知道是否看过一些医疗类型的美剧，还记得发生危急情况时，医院是如何通知医生们的吗？

2023-04-18 23:16:10 833

原创 Day948.组件化成熟度评估，你的目的地在哪里呢 -系统重构实战

组件化成熟度评估模型。该模型分为 5 个等级，分别为原始级、入门级、标准级、进阶级以及创新级。同时从组件化的核心能力体现为 6 个维度，包括组件设计、集成编译、测试保障、架构守护、分支策略以及持续发布，每个维度同样也有 5 个等级，最终要以最低得分的维度作为最后的评估等级。成熟度模型一方面可以帮助制定改进目标，另一方面也可以帮助我们更好地度量结果，从而帮助我们去持续改进。

2023-04-17 22:35:51 273

原创 Day947.Android系统组件化 -系统重构实战

组件化设计就是将自己扩展的代码独立成内聚的组件，以二进制与整机集成，尽量减少在 AOSP 框架中的代码修改量。下面给你总结了组件化解耦常见的 3 种情况，你可以通过后面的表格回顾。一方面，能够帮助我们有效减少分支数量、多版本维护工作，让团队更聚焦在高价值的业务研发和质量打磨工作中。另一方面，也能帮助我们减少产品的质量问题、提高产品的响应力。相比应用的解耦，系统解耦的复杂度和需要处理的耦合场景更多，特别是相对于框架的解耦，编译调试验证的难度更大。

2023-04-16 23:16:11 147 1

原创 Day946.厂商定制的Android系统为什么也要解耦？ -系统重构实战

各个分层职责清晰，从上到下依次为应用框架层、Binder IPC、系统服务层、硬件抽象层以及 Linux 内核层。但是当厂商开始定制 Android 系统时，由于项目管理、交付压力等等情况，非常容易出现不按规矩出牌的情况，总结了 3 种最常见的耦合场景，后面的表格回顾。由于耦合的问题，团队需要完成大量重复、机械性的代码合并工作，也需要同时维护多个并行的版本。

2023-04-15 14:15:59 358

原创 Day945.Android系统开发的版本管理、编译与自动化测试 -系统重构实战

Android 系统开发的一些基础设施工具，与应用开发相比，系统开发更加复杂。为了解决多仓库开发的问题，官方提供了 Repo 及 Gerrit 工具。Repo 帮助我们可以去批量操作多个 Git 仓库，这大大简化了我们跨仓修改时代码提交同步的工作量。Gerrit 工具也通过 Change-ID 的形式帮我们关联多个仓库的提交记录，方便我们做 CodeReview。

2023-04-15 00:45:10 205

原创 Day944.度量指标 -系统重构实战

通过度量指标可以帮助明确方向，及时反馈结果，推动持续改进。通常在项目中，都会搭建度量相关的看板来持续观察数据的变化，同时也会在团队定期的回顾会上，复盘这些数据制定改进目标。不建议团队将度量指标纳入 KPI 中，这样非常容易导致走向另外一个极端，失去了度量关键的意义。下面度量指标的定义、目的、建议阈值及趋势等总结成表格。给出了一些通用的建议参考阈值，具体的产品不同，情况可能会有差异。

2023-04-13 22:26:17 515

原创 Day943.持续集成流水线 -系统重构实战

持续流水线是一种软件开发的实践，目的是通过自动化为软件的发布创造一个稳定且可重复的过程。流水线带来的效果是显而易见的，从效率上帮助减少低价值的重复工作，例如本地编译打包，另外也能减少团队成员间不必要的沟通。从质量上看，统一了构建发布环境，整个环境会更可靠，减少了人工操作带来的意外风险。另外，结合流水线增加质量门禁，可以在版本发布前检查代码质量，避免不符合规范及要求的代码合入代码仓库中。当然要让流水线发挥最佳的作用，还得依靠团队成员共同来遵循流水线的纪律，保障流水线红不过夜，当运行失败时能及时修复。

2023-04-12 21:57:24 606

空空如也

空空如也