yuanbli yiyi2870
关注数: 16 粉丝数: 8 发帖数: 303 关注贴吧数: 9
标题五个字
标题五个字
标题五个字 这是什么鸟@孙吧老哥
愚人节表白 @孙吧老哥 愚人节表白怎么说
普京现在到底开不开心 他慌了吧
发贴前缀1打分贴测试 djjdjdj
重构-改善既有代码的设计 第十一章 在前边的章节主要是讲了函数和模块的重构，本章节的主题是重构API，将模块和函数串联。作者介绍了一些重构API的方式： 1、将查询函数和修改函数分离 将查询动作从修改动作中分离出来，使函数变得简单 2、函数参数化 两个函数逻辑非常相似，只有一些「字面量值」不同，可以将其合并成一个函数，以参数的形式传入不同的值，从而消除重复。 3、移除标记参数 针对参数的每一种可能值，新建一个明确函数。 4、保持对象完整 代码从一个记录结构中导出几个值，然后又把这几个值一起传递给一个函数，应该把整个记录传给这个函数，在函数体内部导出所需的值。 5、以查询取代参数 如果想要去除的参数值只需要向另一个参数查询就能得到，这是使用以查询取代参数最安全的场景 如果可以从一个参数推导出另一个参数，那么几乎没有任何理由要同时传递这两个参数 6、以参数取代查询 相反地，如果函数内部需要多次查询同一对象以获取不同信息，并且这些信息在函数外部已经可用，那么可以考虑将这些信息作为参数传递给函数，以减少函数内部的查询次数。 7、移除设值函数 如果为某个字段提供了设值函数，这就暗示这个字段可以被改变。如果不希望在对象创建之后此字段还有机会被改变，那就不要为它提供设值函数。 8、以工厂函数取代构造函数 使用工厂函数来创建对象可能比直接使用构造函数更加灵活和方便。工厂函数可以根据需要返回不同类型的对象实例。 9、以命令取代函数/以函数取代命令： 命令对象：将函数封装成自己的对象，在命令对象中添加更丰富的方法来设值命令的参数值。命令对象的灵活性也是以复杂性作为代价的，所以如果这个函数不是太复杂，应该考虑将其变回普通的函数。
《重构 改善既有代码的设计》第十章 简化条件逻辑 程序的复杂度也大多来自条件逻辑。 1、分解条件表达式：这个技巧涉及将复杂的条件逻辑（if-else 语句）分解成更简单的、单独的函数。对条件判断和每个条件分支分别运用提炼函数 2、合并条件表达式：当有多个条件表达式都导致相同的结果或动作时，使用“逻辑或”和“逻辑与”将它们合并为一个条件表达式。这减少了重复代码，并提高代码的可维护性。 3、以卫语句取代嵌套条件表达式：说白了，就是不要在多个if-else中维护一个返回变量，而是在满足条件的时候直接返回。从而减少代码嵌套。 4、以多态取代条件表达式：一组类型如果每个类型处理各自的一种条件逻辑，我们可以针对switch语句中的每种分支逻辑创建一个类，用多态来承载各个类型特有的行为，从而去除重复的分支逻辑。作业举了鸟和远洋航船的例子，来方便我们理解这一方式。 5、引入特例：在获取某个变量的时候，需要判断nil，这时候可以封装函数，对nil特例做处理，和pb.go提供的get方法的思想是一致的 6、引入断言：只有当某个条件为真时，该段代码才能正常运行，使用断言明确标明这些假设
重构-改善既有代码的设计 第9章 重新组织数据 第九章主要讲了简化条件语句，使得程序逻辑更清晰，同时方便扩展。 作者介绍了几种方式： 1. 拆分变量：如果变量承担多个责任，它就应该被替换（分解）为多个变量，每个变量只承担一个责任。每次都在声明处对变量改名，并修改下次赋值之前的引用，直至到达最后一处赋值。 2. 字段改名：在对字段改名时，有4个地方需要留意：取值函数、设值函数、构造函数以及内部数据结构。 3. 以查询取代派生变量：尽量把可变数据的作用域限制在最小范围 4. 将值对象改为引用对象：把值对象改为引用对象会带来一个结果：对于一个客观实体，只有一个代表它的对象。这通常意味着我会需要某种形式的仓库，在仓库中可以找到所有这些实体对象。只为每个实体创建一次对象，以后始终从仓库中获取该对象。
重构-改善既有代码的设计 第8章 第八章主要讨论了如何系统地识别和实施代码中的重构机会。在这一章中，作者介绍了一系列的重构技术，这些技术可以帮助开发者改进代码的内部结构，同时不改变其外部行为。 1. 搬移函数：将一个函数从一个类或模块移动到另一个更合适的类或模块中，将功能组合相似的函数聚集到一起； 2. 搬移字段：搬移字段是将一个字段从一个类移动到另一个更合适的类中。当一个字段在另一个类中更频繁地被使用时，进行这种重构可以减少耦合，提高数据的封装性； 3. 搬移语句到函数：将一组相关的语句提取到一个独立的函数中，可以提高代码的可读性和复用性。这种重构有助于简化复杂的函数，使代码更易于理解和维护； 4. 搬移语句到调用者：把表现不同的行为从函数里挪出，并搬移到其调用处； 5. 以函数调用取代内联代码：将重复的内联代码替换为函数调用，可以减少代码的冗余，提高代码的复用性和可维护性。这种重构有助于集中和统一处理逻辑，减少错误的可能性； 6. 移动语句：通过调整语句的顺序，使代码逻辑更加连贯和清晰。这种重构有助于减少变量的作用范围，提高代码的可读性； 7. 拆分循环：将一个复杂的循环拆分成多个简单的循环，每个循环只处理一种逻辑。这样可以提高代码的清晰度和可维护性，降低出现复杂错误的可能性； 8. 以管道取代循环：使用函数式编程的管道操作（如map, filter, reduce）来替代传统的循环，可以使代码更具声明性，减少副作用，提高代码的可读性和可维护性； 9. 移除死代码：移除不再使用的代码可以减少代码库的复杂性，提高代码的清晰度和可维护性；
重构-改善既有代码的设计 第五章 这一章介绍了重构名录,是理解重构技术的重要基础。 每个重构手法都有如下 5 个部分。 - 名称（name）。要建造一个重构词汇表，名称是很重要的。列出常见的别名。 - 速写（sketch）。可以帮助更快找到你所需要的重构手法。 - 动机（motivation）为你介绍“为什么需要做这个重构”和“什么情况下不该做这个重构”。 - 做法（mechanics）简明扼要地一步一步介绍如何进行此重构。 - 范例（examples）以一个十分简单的例子说明此重构手法如何运作。
重构-第三章 这一章详细阐述了代码中常见的“坏味道”，即那些可能预示着代码需要进行重构的征兆。 1.神秘命名：整洁代码最重要的一 环就是好的名字，所以我们会深思熟虑如何给函数、模块、 变量和类命名，使它们能清晰地表明自己的功能和用法。 2.重复代码：如果要修改重复代码，你必须找出所有的副本来修改。 3.过长函数：函数越长，就越难理解。应该更积极地分解函数。 4.过长参数列表：使用类可以有效地缩短参数列表。 5.全局数据：从代码库的任何一个角落都可以 修改它，而且没有任何机制可以探测出到底哪段代码做出了修改。 6.可变数据：用封装变量来确保所有数据更新操作都通 过很少几个函数来进行，使其更容易监控和演进。 7.发散式变化：如果某个模块经常因为不同的原因在不同的方向上发生 变化，发散式变化就出现了。 8.霰弹式修改：如果每遇到某种变化，你都必须在许多不同的类内做出许多小修改，你所面临的坏味道就是霰弹式修改。 9.依恋情结：一个函数跟另一个模块中的函数或者数据交流格外频繁，远胜于在自己所处模块内部的交流。 10.数据泥团：你常常可以在很多地方看到相同的三四项数据，首先请找出这些数 据以字段形式出现的地方，运用提炼类将它们提炼 到一个独立对象中。 11.基本类型偏执：运用以对象取代基本类型(174)将原本单独存 在的数据值替换为对象，从而走出传统的洞窟，进入炙手可 热的对象世界。 12.重复的switch：重复的switch的问题在于:每 当你想增加一个选择分支时，必须找到所有的switch，并逐 一更新。 13.循环语句：管道操作(如 filter和map)可以帮助我们更快地看清被处理的元素以及 处理它们的动作。 14.冗赘的元素：程序元素(如类和函数)能给代码增加结构，从而支持 变化、促进复用或者哪怕只是提供更好的名字也好，但有时 我们真的不需要这层额外的结构。 15.夸夸其谈通用性：企图以各式各样的钩子和特殊情况来处理一些非必要 的事情，这种坏味道就出现了。 16.临时字段：其内部某个字段仅为某种特定情况而设。 17.过长的消息链：在实际代码中你看到的可能是一长串取值函数或一长 串临时变量。 18.内幕交易：在模块之间大量交换数据，这会增加模块间的耦合。 19.过大的类：想利用单个类做太多事情，其内往往就会出现太多字段。 20.注释：当你感觉需要撰写注释时，请先尝试重构，试着让所有注释都变得多余
重构-改善既有代码的设计 以一个代码组织不甚清晰的喜剧演出团账单打印为例子。 > 如果你要给程序添加一个特性，但发现代码因缺乏良好的结构而不易于进行更改，那就先重构那个程序，使其比较容易添加该特性，然后再添加该特性。 是需求的变化使重构变得必要。 1、我得确保即将修改的代码拥有一组可靠的测试。重构前，先检查自己是否有一套可靠的测试集。这些测试必须有自我检验能力。 2、分解函数 将可以服用的功能点，提炼函数，便于后续复用。修改完成后，看是否能进一步提升其表达能力，比如变量改名，使它们更简洁。 为参数取名时都默认带上其类型名，php中也可以这样做。 删除了多余（并且会引起误解）的注释。 计算相关的逻辑从主函数中被移走，改由一组函数来支持。每个单独的计算过程和详单的整体结构，都因此变得更易理解了。 3、拆分文件 额外的包装将混杂的逻辑分解成可辨别的部分，分离了详单的计算逻辑与样式。 > 编程时，需要遵循营地法则：保证你离开时的代码库一定比来时更健康。 4、抽离通用计算逻辑 通过多态实现不同子类的业务逻辑即可 > 好代码的检验标准就是人们是否能轻而易举地修改它。
1 下一页