本章提出了重构的前提，得有一套稳固的测试集合。 测试的价值：一套测试就是一个强大的bug侦测器，能够大大缩减查找bug所需的时间。 撰写测试代码的最好时机是在开始动手编码之前。 学习了简要的测试步骤：1.设置好测试夹具（fixture）也就是测试所需要的数据和对象。2.验证夹具是否具备某些特征。 注意的细节点：要注意测试的独立性，测试夹具最好不用共享。 考虑可能出错的边界条件，把测试火力集中在那儿。 每当收到bug报告，可以先写一

构筑测试体系的重要性 重构是提升代码质量和可维护性的有效手段，但仅靠重构是不够的。为了确保重构的正确性，必须有一套稳固的测试集合，帮助发现难以避免的疏漏。 测试代码的价值 节省调试时间：平时写代码的时间相对较少，而调试代码的时间较多。通过测试代码，可以避免代码堆积过久后出现难以发现的bug，从而节省大量用于定位问题的时间。 自动化测试：在每个迭代结束后添加测试代码，未来可以通过自动化测试逐一检测每个小模块

本章讲述了如何构筑测试体系。 在阅读过程中，我意识到自测代码的价值。正如书中所言，编写测试程序可能会增加额外的代码量，但其所带来的好处远超过这些。通过预先编写测试代码，我们可以将注意力集中在接口而非实现上，这有助于我们更清晰地定义功能需求，并确保重构后的代码满足这些需求。

第四章主要讲测试。 作者从测试的各个角度来分析验证测试环节对软件开发及重构的作用 1. 测试的重要性 测试是重构的基石。在进行任何重构之前，我们需要先编写测试来验证现有代码的行为是否符合预期。这些测试为我们的重构提供了保障，使我们能够在改进代码结构的同时，确保功能不被破坏。 2. 测试的类型 重构过程中主要使用的是自动化测试。以下是几种常见的测试类型： •单元测试：测试代码的最小功能单元，如函数或方法，确保其行为

重构的定义 重构是修改一个软件系统，使其不改变外部行为，但改善其内部结构的一种技术。 简而言之，重构不是改变代码的功能，而是改善代码的结构和可读性，使其更容易理解、维护和修改。 重构的原则 重构遵循以下几个原则： 保持行为不变： 重构必须确保代码修改后，其外部行为与修改前完全一致。 小的改动： 重构应该是一次只进行一个小的改动，以降低引入错误的风险。 自动化测试： 在重构之前，应该编写自动化测试来确保代码的正

通过阅读第四章，我深刻体会到了重构在软件开发中的重要性。重构不仅是一种技术，更是一种思维方式。它要求开发者不断反思和改进代码，以追求更高的质量和可维护性。重构的技法是每个开发者的必修课，掌握这些技法将使我们能够更从容地应对复杂的代码和变化的需求。 总的来说，重构不仅仅是改善代码的手段，更是提升我们编程能力和代码质量的必经之路。第四章提供的丰富技法和实践经验，为我们在实际项目中应用重构提供了宝贵的指

阅读第四章的感受： 这一章为我们讲述了在重构过程中测试得重要性，必须要构建测试体系 自测代码：在每个迭代结束后把测试代码加上，让测试代码自动化得检测代码中存在得问题，减少debug的时间如何进行测试： 编写对功能的测试，而非对某个函数的测试 针对一些可能出现的边界情况进行重点测试，避免程序出现异常

第四章的重点讲述了在前三章确定重构的前提下，怎么保障重构能够正确的进行，不会出现难以避免的疏漏。重点介绍了构建测试体系的重要性以及如何编写测试代码的经验。 测试体系的重要性体现在：重构的目的是改进代码质量，但是只靠重构是不够的，可能会引入新的问题，正确的重构需要建立在稳固的测试基础上，以捕捉坑的疏漏和错误，避免重构引入问题；同时，即使不进行重构，测试也能够帮助我们在早期发现问题，大大的减少花在调试

阅读4章的感想 第4章讨论了“测试”的重要性，这一章在《重构-改善既有代码的设计》中占据了一个至关重要的位置。Martin Fowler在这里强调了测试在重构过程中的核心作用。没有良好的测试覆盖，重构就像是在黑暗中摸索，因为你无法确定你所做的改动是否破坏了现有的功能。 Fowler指出，单元测试是重构的基石。它们为你提供了即时的反馈，让你知道你的代码是否依然正确。通过一系列简单但全面的测试，你可以大胆地修改代码，而不用担心引入新

第一部分： 1：本书开头的介绍区别于其他架构介绍，强调人员的重要性 2：人员在一起就是组织，组织可扩展也很重要 3：领导和管理的工作方向是有去别的 第二部分： 1：完成可扩展性与可用性，就是要明确各个角色的责任 2：RASCI 是一个可以帮助减少责任重登，产生清晰角色的工具，RASCI 以矩阵方式出现。 • R代表负责，指决定要做什么事的人，而且负责任务的实施 • A代表批准，指在决策过程中批准任务并验收任务结果的人。 • S代表支持，指

第十三章 -- 联合架构设计和架构审查委员会 联合架构设计 --- 我们在需求设计过程中， 会拉齐server所有人员一起参与， 大家整体取长补短， 需求owner实现做好的设计方案。 架构审查委员会 -- 通过预设计的方式， 前瞻性的对未来的需求进行架构底层的设计和架构原则的实现， 把控业务的底层架构发展。 联合架构设计确实非常好用， 以当前端外pb的通用化设计为例 当『端外pb与端内pb』打齐的联合架构设计的评审结束后， 对于后续贴吧服务端的架构

JAD：联合架构设计，是一个协同设计的过程，所有的工程人员一起共同设计和开发一些符合架构原则的主要新功能 ARB：架构审查委员会，负责选择和决定每一个新功能或业务领域的架构，在架构设计得到最终签署之前，要由该委员会确定设计符合公司所有的架构原则和业界的最佳实践 技术组织的功能障碍经常导致闭门设计，这些问题特别容易出现在基于功能的组织及存在经验鸿沟的组织，解决这个问题的办法是迫使团队为共同的目标一起努力，这也

第13章 本章主要介绍了两个过程：联合架构设计JAD（Joint Architecture Design）和架构审查委员会ARB（Architecture Review Board），讲述了这两个设计过程的准入和退出标准，以及退出遗漏问题的处理规则等 用RASCI术语来描述，对于设计，JAD是R（负责），ARB是A（责任）。 JAD的成员来自于工程、架构和运维（数据库管理员、系统管理员或网络工程师）。 JAD成功的关键在于过程的完整性，严格坚持准入和批准标准。 ARB审查应只授予那些有充分准备的项目。 ARB的决

在任何程序中，最初的输入是数据，最后产出也是数据。所以数据才是用户关心的最根本的东西，把握数据的变化和流转才能更好的去把握整个系统本质。 1、基础类型 String类型：是很特殊的一种数据类型，他是用户和程序能共同认识的最基本数据。，能够无缝的来回穿梭在程序和人脑中。所以在程序开发中string类型使用率非常高。 Int类型：既简单又复杂，简单的时候他是一个数字，描述数据结构的下标或数组的长度，但是复杂的时候，比如int的变

构筑测试体系 重构是很有价值的工具，但只有重构还不行。要正确地进行重构，前提是得有一套稳固的测试集合，以帮我发现难以避免的疏漏。 测试代码价值： 1. 日常中写代码时间少，调试代码时间长，避免代码堆积过久，出现意想不到的bug，难以发现，浪费大把时间去定位问题； 2. 在每个迭代结束后把测试代码加上，日后自动化测试，可以逐一检测每个小模块功能是否正确； 3. 如果不小心引入bug，可通过自动化测试代码快速发现问题，不必花很

Service Locator 它是编程原则 “控制反转”(roe) 的实现方式之一。 控制反转是“某种权力转交给了别人，于是被反转了” 。 在 ServiceLocator里， 就是“你创建对象的权力转移给 Container了”， 被 “反转”了。 实现“控制反转”有第二种方式是依赖注入。 例如，通过属性注入这种依赖注入的方式。自然也可以把创建对象的任务外包，交给外层，从而实现“控制反转”。 控制反转的两种手法，再集成工厂模式 ，可能让本不需要 new的模块里 ，彻底摆脱 new,

mvp模式： MVP 模 式， m是模型，v是视图，p是管理层负责管理数据、UT 视图创建、交互逻辑、动画特效等等一切事务。数据层只负责存储数据，视图层只负责创建视图模板。MVP 与MVC 相比最重要的特征就是MVP 中将视图层与数据层完全解男，使得对视图层 的修改不会影响到数据层，数据层内的数据改 动又不会影响到视图层。因此，我们在管理器中 对数据或者视图灵活地调用就可使数据层内的数据与视图层内的视图得到更高效的复用。 mvvm模式：MVVM 模式

mvp模式： MVP 是 MVC 的变种，其实是一种升级。要说 MVP 就要说说 MVC，在 MVC 中 Activity 其实是 View层级，但是通常在使用中 Activity即是View也是Controller，并没有将 View层 和 Controller层 进行分离， 耦合度大大提高，不利于项目的管理。把 业务逻辑 抽象成 Presenter接口，Model类 还是原来的 Model。Presenter 其实是 Model层 和 View层 的桥梁。 mvvm模式： Model-View-View Model（MVVM）模式是一种常见的UI应用程序结构方式。它使用数据绑定系统来帮助在视图和视图模型之间

39章：MVP模式，是一种用户界面设计模式，它类似于MVC模式，但强调通过Presenter来隔离View和Model之间的交互，以提高代码的可测试性和模块化程度。在MVP模式中，Model负责处理数据和业务逻辑，View负责渲染用户界面，而Presenter则充当View和Model之间的协调者。两者相比，最主要的特征就是MVP模式将视图层与数据层完全解耦，使得对视图层的修改不会影响到数据层，数据层内的数据改动也不会影响视图层。 40章：MVVM模式中，Model代表数据和业务逻辑，View代

widget模式，是分而治之思想的一种体现，特别是在构建复杂的前端界面时。Widget 可以被看作是页面上的一个独立组件，它封装了特定的功能，并且可以与其他组件或页面进行交互，非常适合团队中多人开发。并且能降低相互之间因功能或者视图创建的耦合影响概率。 MVC模式，是一种常见的设计模式，用于将应用程序的数据模型（Model）、用户界面（View）以及控制逻辑（Controller）进行分离。组件式架构开发，将视图、数据、业务逻辑写在一个模块内，

mvp模式：模型、视图、管理器。View层不直接引用Model层内的数据，而是通过Presenter层实现对Model层内的数据访问。将view层与Model层完全解耦，使得对View层的修改不会影响到Model层，Model层内的数据改动又不会影响到视图层。 mvvm模式：模式、视图、视图模型。为View层量身定做一套ViewModel，并在ViewModel中创建属性和方法，为View层绑定Model，并实现交互。mvvm使View层更灵活，可以独立于Model、View而独立修改，自由创建。

第十三章主要讲了隐式约定 隐式约定的最主要特征是数据在传输前要打包，传输后要解包，与其对应的显示约定则是直接将数据拿来使用。 隐式约定逻辑流程：数据打包、数据传输、数据解包 优点：数据传输的两头都要付出额外拆包解包操作的代价，其目的是让数据的传输得到极大的灵活性，解耦 缺点：打包和解包步骤多效率低、开发沟通成本、打包解包过程中可能会出错、阅读性降低。 使用隐式约定两种例子：1、context（散列表）2、序列化和反

在Android开发中，多线程是一个重要的概念，它允许在单个应用程序中同时执行多个任务，从而提高应用程序的性能和响应性。 1. 多线程的定义 * 多线程：指在一个进程中同时执行多个任务的技术。在Android中，多线程技术通常用于执行耗时操作（如网络请求、文件读写等），以避免阻塞主线程（UI线程），从而提高用户体验。 2. 实现多线程的方式 * 使用Thread类：通过继承Thread类或者创建Thread匿名内部类的方式来创建线程对象，并重写run()方法来定义线

对于我们的日常开发，隐式约定主要涉及到Intent的使用，特别是隐式Intent。那么什么是隐式Intent？隐式Intent是指在启动Activity、Service或BroadcastReceiver时，不直接指定需要激活的组件的名称，而是通过设置action、data和category等属性，让Android系统根据这些属性来匹配并启动最合适的组件。系统通过比较Intent中的action、category和data与AndroidManifest.xml中定义的intent-filter来找到最匹配的组件。 并且Intent中的action必须与intent-filter中的某个action完全匹配（区分大小

MVP模式MVC演变而来的软件设计模式，它们的基本思想有相通之处：Controller/Presenter负责逻辑的处理，Model提供数据，View负责显示。MVP模式具有以下优势：View与Model完全隔离，Model和View之间具有良好的松耦合设计。就是说，如果Model或View中的一方发生变化，只要交互接口不变，另一方就无需对上述变化做出改变。使得Model层业务逻辑更好的灵活性和可重用性。MVP模式通过巧妙地分离视图与模型，降低了系统的复杂性，提高了代码的可维护性和可测试性。 M

第十三章：本章介绍了隐式约定的概念。 隐式约定是相对于显示约定提出的，显示约定要求在编写业务逻辑时明确规定数据的类型和结构，而隐式约定则通过将数据结构封装后传输，使用时从数据包中解析出所需数据。隐式约定的优势在于简化代码，使其更加简洁。例如，当一个函数需要多个参数时，显示约定会导致函数参数繁多，而通过隐式约定，可以将参数组装成一个新的数据结构，简化函数定义，提高代码可读性和维护性。 1. 显示可理解为为

第十三章：本章介绍了隐式约定的概念。隐式约定是相对于显示约定提出的，显示约定要求在编写业务逻辑时明确规定数据的类型和结构，而隐式约定则通过将数据结构封装后传输，使用时从数据包中解析出所需数据。隐式约定的优势在于简化代码，使其更加简洁。例如，当一个函数需要多个参数时，显示约定会导致函数参数繁多，而通过隐式约定，可以将参数组装成一个新的数据结构，简化函数定义，提高代码可读性和维护性。 第十四章：该章讨

第十章：该章讨论了条件表达式if else的局限性。if else链条过长会导致代码冗长复杂，而与核心模块的耦合则使得修改任意部分都会影响整体。为了解决这些问题，可以采用以下方法：1）抽取共性逻辑，简化代码结构；2）利用多态，通过继承和接口来减少条件判断；3）数据驱动，将逻辑与数据分离；4）使用动态类型，提高代码灵活性和扩展性。 第十一章：这一章聚焦于static的作用。static并非面向对象的产物，而是源自传统的全局数据和函数。尽管

Widget模式它允许用户将特定的功能组件嵌入到主应用界面或屏幕上，以实现自定义的界面布局和交互体验。在使用Vue时，widget模式可以通过创建可复用的组件来实现。每个widget都可以被设计为一个独立的Vue组件，具有自己的状态、属性和事件。主页面可以根据需要动态地加载和组合这些widget组件。 MVC模式通过业务逻辑数据、界面显示分离的方法组织代码，将业务逻辑聚集到一个部件里面。MVC模式的三个核心组件包括Model（模型）、View（视图）、Controll

《重构：改善既有代码设计》读书笔记——第三章 一、引言 进入《重构：改善既有代码设计》的第三章，Martin Fowler继续深入探讨重构的艺术，并为我们提供了一系列具体的重构手法。这些手法不仅能够帮助我们改善代码的设计，还能使代码更加清晰、易于理解和维护。 二、函数级别的重构 提炼函数（Extract Method） 将过长的函数中的某一部分代码提炼出来，形成一个独立的函数。这样可以使原函数的职责更加明确，易于理解。 内联函数（Inline Method

第四章： 耦合无处不在耦合 ：在软件工程中是指模块或组件之间的依赖关系和关联程度。耦合越高，模块之间的依赖性越强，维护和扩展系统的难度也越大。 好耦合是指在模块或组件之间的依赖关系是必要且符合业务需求的。这种耦合通常反映了底层系统的限制和设计选择，是系统设计的自然结果。例如，数据库模块和数据访问模块之间的耦合是必要的，因为数据访问模块需要直接操作数据库。特点： 依赖关系是清晰的和必要的。 依赖关系符合业

同一个类的两个函数还有相同的表达式，这时需要提炼出重复代码。 两个互为兄弟的子类内含有相同的表达式，可以提炼相同代码，并放到父类中。如果只是代码间相似，并非完全相同，那么可以将相似部分和差异部分拆开，构成单独的函数。然后你可以使用模板方法的设计模式。 如果两个毫不相关的类中出现重复代码，则可以将重复代码提炼成一个函数放到一个独立类中或者只放在某一个类中（总之要放在合适的地方），然后其他类都去调用这个

阅读2章的感想 本章深入探讨了重构的基本原则和其背后的哲学思想。Martin Fowler首先强调了重构的目标，即在不改变软件外部行为的前提下，优化其内部结构。重构的核心在于提高代码的可读性和可维护性，从而减少技术债务，提升开发效率。 本章介绍了几个关键的重构原则。首先是“小步前进”的原则，建议开发者以小步进行改进，每次只做一个小的修改，然后进行测试。这种方法能使问题更容易被发现和解决，降低重构的风险。其次是“持续集

代码的坏味道 本章讲到重构何时需要开始、何时需要结束。 我们通过对代码的阅读， 就能够感知到整个代码架构里 是否有脏东西出现。 1.神秘命名：不能清晰的表明自己的功能和用法，给人造成迷惑。好的名字能节省未来用在猜谜上的时间。如果想不出一个好名字，说明背后很可能潜藏着更深的设计问题。 2.重复代码：同一个类的两个函数含有相同的表达式 。 危害：如果要修改重复代码，你必须找出所有的副本来修改。 3.过长函数：代码太多的函

《重构-改善既有代码的设计》一书中提到的夸夸其谈通用性（YAGNI, "You Ain't Gonna Need It"）的设计问题，是指在软件开发过程中，过度设计和构建过多的通用性和灵活性，而这些特性在未来很可能不会被实际使用。这种设计思想虽然初衷是好的，但却往往导致代码复杂性增加，维护成本上升，并且容易引入更多的潜在问题。 我的感悟是，软件开发应该以实际需求为导向，避免为了追求所谓的“完美设计”而增加不必要的复杂度。过度的抽象和

在第二章中讲了重构的定义与两顶帽子，新添加功能与对代码的重构，重构有动词与名词的定义。我的理解为在实际开发的过程中，我们一定会用的这两顶帽子，但一定要区分出这两顶帽子的区别，明确我们现在需要做的事情，确认我们开发的目的，只有这样才可以保证事情的准确性

引言 在第三章，Martin Fowler详细介绍了代码中的各种“坏味道”（Code Smells），这些坏味道是代码质量下降的征兆，需要通过重构来解决。这一章为开发者提供了识别和处理这些坏味道的指南。 3.1 代码坏味道的定义 代码坏味道是指在代码中出现的一些表面现象，这些现象预示着代码在某些方面存在潜在的问题。坏味道并不一定意味着代码有错误，但它们通常表明代码需要改进。 3.2 常见的代码坏味道 重复代码（Duplicated Code）：相同或相似的代码出现

这一章详细阐述了代码中常见的“坏味道”，即那些可能预示着代码需要进行重构的征兆。 1.神秘命名：整洁代码最重要的一 环就是好的名字，所以我们会深思熟虑如何给函数、模块、 变量和类命名，使它们能清晰地表明自己的功能和用法。 2.重复代码：如果要修改重复代码，你必须找出所有的副本来修改。 3.过长函数：函数越长，就越难理解。应该更积极地分解函数。 4.过长参数列表：使用类可以有效地缩短参数列表。 5.全局数据：从代码库的任

本章核心，一句话：如果尿布臭了，就换掉它！ 代码不是尿布，怎样识别代码是否“臭”了，就也是判断何时该发起重构是个很微妙的问题，很难给个精确的衡量标准，但是还是有一些迹象可以辅助判断，至于怎么结合迹象来决定是否发起重构，则依赖读者自己的判断力。 1. 神秘命名 好的命名是整洁代码的关键。如果名字不能清晰地表明功能和用法，就需要改名。改名不仅能节省猜测的时间，还可能揭示出更深的设计问题。 2. 重复代码 重复的代码

1. 修改神秘的命名 There are only two hard things in Computer Science: cache invalidation and naming things. 命名在编程中其实是一个难事 2. 合并重复的代码 3. 修改过长的函数，精简过长参数列表 群聊代码中对应用户render信息的处理，随着业务复杂性增长导致参数越来越多 4. 针对全局变量，可以封装修改及访问方法，从而控制可能修改全局变量的地方 5. 通过多态替换switch dev-tools中switch逐渐庞大

第三章——代码的坏味道 主要讲述了识别和处理代码中的各种问题，即所谓的“坏味道”。 “坏味道”并不直接代表错误或缺陷，而是代码质量欠佳、可读性差、维护困难的征兆。通过识别这些坏味道，开发者可以判断何时需要进行重构来改善代码。 本章中，Martin Fowler 列出了22种常见的代码坏味道，并提供了解决这些问题的建议。以下是其中一些关键坏味道及其简要说明： 1.Duplicated Code（重复代码）： •相同的代码在多个地方出现，维护成本高。

第三章：代码的坏味道 在第三章中，Martin Fowler讨论了“代码的坏味道”（Code Smells），这些“坏味道”是代码质量下降的预警信号，需要我们及时重构加以修正。阅读这一章让我深刻体会到识别和应对“坏味道”的重要性。 感悟一：认识“坏味道”的重要性 Martin Fowler列举了多种常见的代码坏味道，如冗长函数、重复代码、过长的参数列表、依赖链等。这些坏味道在我过去的开发工作中经常遇到，但往往因为项目进度紧张或缺乏系统的认知，没有及

第三章讲述了多种badcase，重复代码、过长函数等，并针对一些场景提供了一些解决思路。 注释模块中一句tip写的很好：当你感觉需要撰写注释时，请先尝试重构，试着让所有注释都变得多余。

神秘命名：命名是编程中最重要的部分之一。清晰的命名可以极大地提高代码的可读性和可维护性。尽量使用描述性强的名称，避免缩写和含糊不清的命名。 重复代码：重复的代码不仅增加了维护的难度，还可能导致潜在的错误。使用函数、类、模块等抽象手段来消除重复代码。 过长函数：过长的函数通常意味着它承担了过多的责任。将函数拆分成更小、更专注的部分可以提高代码的可读性和可维护性。 过长参数列表：过多的参数通常意味着函数承

《重构：改善既有代码的设计》的第三章主要是告诉我们何时应该进行代码重构的。作者提出了一系列的代码的"坏味道"来帮助我们找到代码中需要重构的地方。这些坏味道包括：重复的代码、过长的函数、过大的类、过长的参数列表、注释等。当我们在代码中发现这些坏味道时，就意味着这里可能需要进行重构。

通过本章学习了怎么辨别代码的坏味道，何时必须重构没有精确衡量的一个标准，必须提高自己的判断力来找到正确的方向。本章讲解了代码的坏味道的常见种类，包括： 1.神秘命名：不能清晰的表明自己的功能和用法，给人造成迷惑。好的名字能节省未来用在猜谜上的时间。如果想不出一个好名字，说明背后很可能潜藏着更深的设计问题。 2.重复代码：同一个类的两个函数含有相同的表达式 。 危害：如果要修改重复代码，你必须找出所有的副本来

本章主要讨论了代码的坏味道（Code Smells），表明了代码设计存在问题的迹象。 主要内容 1、重复代码（Duplicated Code）： 同样的代码在多个地方出现，增加了维护成本。 解决方法：提取公共代码到一个独立的方法或类中。 2、过长方法（Long Method）： 方法过长难以理解和维护。 解决方法：将长方法分解为多个小方法，每个方法完成一个明确的任务。 3、过大的类（Large Class）： 类承担的职责过多，违反了单一职责原则。 解决方法：将类拆分成多个更

重构的时机： 难读 如：函数过长，通过参数控制各种逻辑 难改 如： 重复代码需要多处修改，则需要抽离封装；难读的代码 解决：函数功能单一原则，充分封装抽象

在阅读了《重构-改善既有代码的设计》一书的第三章后，我深感其对于后端开发工作的指导意义。本章详细讨论了如何识别和评估需要重构的代码段，以及重构的具体方法和策略。对于我们这些长期与代码打交道、时常需要面对老旧或设计不佳的代码的后端开发者来说，这无疑是一份宝贵的指南。 首先，本章对于“坏味道”代码的识别进行了深入的阐述。书中通过具体的例子和描述，使我意识到那些看似微小但实则影响深远的代码问题。例如，过长