重构

从此重构 设计是如此重要，那么开发者的基本设计能力与素质又从何下手来培养呢？ 最好的办法，就是请个老师。从框架中了解，从系统中实现，从书文中汲取。然而，设计能力的提升绝非一朝一夕之功，软件开发中的设计大师，往往必须具备多年的修行方可称之为“架构师”。 一个在简历中轻描淡写的“ 10 年软件设计经验”，并非是所有软件人都能修炼成的真功夫，这里没有任何虚情假意可言。在一个项目的实现过程中，逐渐了解什么是对象、什么是对抽象编程、设计模式是如何应用在实际的系统架构、设计原则到底是什么秘密武器，而重要的是完成一个软件项目，对于更多人来说是认识一种软件开发的科学流程。这种体验，才是难能可贵的经验。在设计的广义概念里，几个必需的概念是应该首先被了解和认知的，以排名不分先后的原则罗列，它们大概包括： · 面向对象 （ Object-Oriented ），关于面向对象没有必要重复嚼舌了，本书的第 1 章“ OO 大智慧”中对 .NET 的面向对象进行了有别于其他专著的介绍，除了以实例突出面向对象之思想大成，还以浓墨铺陈了 .NET 是如何在底层技术上来实现继承、多态和接口映射等机制，从而使读者可以更加有效和深刻地把握面向对象之精髓。 · 面向服务 （ Service Oriented ）， SO 至少是个时髦的话题， WCF 伴着 .NET 3.5 的发布，一个一统江湖的面向服务的基础架构横空出世

6.1Extract Method（提炼函数） 1，你有一段代码可以被组织在一起并独立出来 将则这段代码房间一个独立函数中，并让函数名称解释该函数的用途 void printData ( double amount ) { printBanner ( ) ; //print detail System . out . println ( "name:" + _name ) ; System . out . println ( "amount:" + amount ) ; } 修改成： void printData ( double amount ) { printBanner ( ) ; printDetail ( amount ) ; } void printDetail ( double amount ) { System . out . println ( "name:" + _name ) ; System . out . println ( "amount:" + amount ) ; } 2，动机 如果每个函数的粒度都很小，那么函数复用的机会就很大 这会使高层函数读起来象一系列注释 如果函数都是细颗粒度，那么覆写也会更加容易 3，做法 创建一个新函数，根据这个函数的意图命名（做什么） 将提炼的代码从原函数复制到新建目标函数中 检查是否有“仅用于被提炼代码段”的临时变量

第二章 重构的原则 2.1 何谓重构 重构分为了动词和名词两种意义。 重构（名词）：对软件内部结构的一种调整，目的是不改变软件可观察行为的前提下，提高其可理解性，降低修改成本。 （问题来了，重构真的降低了可理解性吗） 重构（动词）：使用一系列重构首发，在不改变软件可观察行为的前提下，调整其结构。 重构和代码清理的区别是：重构的关键在于用大量且微小，保证软件行为的步骤，一步一步达到大规模的修改。每个单独的重构要么很小，要么由若干小步骤组合而成。 （问题来了，我换一个代码架构重写，这个过程算重构吗？从作者的定义来看，这并不算重构，叫做“结构调整”） 如果有人说他们的代码在重构过程中有一两天时间不可用，基本上可以确定，他们做的事不是重构 重构并不等同于性能优化，重构理论上不会带来任何的性能优化，可能会变快，也可能会变慢。性能优化的目标只是使得代码运行的更快，但可能会使得代码变得更难理解。 2.2 两顶帽子 这里作者指的两顶帽子，分别是重构，和添加新功能。 重构：不再添加新功能，且不加任何的测试。 添加功能：添加功能，添加测试。 在编写程序的过程中，你可能会随时的切换这两种状态，但是你要知道，你什么时候戴的是什么帽子。 2.3 为何重构 重构可以改变软件的设计 如果没有重构，程序的内部设计会逐渐腐败变质。因为当人们只为了短期目的而修改代码的时候，他们经常会没有完全理解架构的整体设计

Inline Temp 内联临时变量 动机:临时变量影响了其他构造方法 当程序有一个临时变量只被赋值一次，而且影响到了其他的重构，那么我将这个变量去除，用赋值给他的表达式来替换临时变量； 确认等式右边的表达式无副作用 然后尝试将临时变量声明为final，确定只赋值一次 替换临时变量 Replace Temp with Query 当临时变量保存一个运算结果或者查询结果，将表达式提取到一个独立函数，然后用函数替代； 优点：这样去除了临时变量不能被其他函数引用导致的多余代码问题 找出临时变量，如果只是一次赋值的变量则可直接提取替代，如果是收集的是循环里面的结果则将整个循环提点。注意：当你的提取代码有副作用时候，记得要用Separate Query from Modifler来切割查询和副作用。（副作用:即会影响数据库的修改类操作或者非当前查询的参数被修改的情况） Introduce Explaining Variale 当你的表达式复杂难懂时，将其提取出来用自定义命名的临时变量替换 优缺点：让代码变动容易理解，被局限于单个函数内 适合场景： 1.当用函数提取工作量比较大的时候就用引入解释性变量 2.当提取函数代码十分复杂，我们可以先引入解释性变量帮助理解，然后再提取 Remove Addignments to Paramters 移除对参数赋值，当代码对参数赋值时候吗

扯 学校清明竟然给放两天假期，心血来潮突然想去学习平衡树。 可是我太弱了学不会有旋转操作的treap和splay，这可怎么办啊qaq。 诶？我以前好像看过一种叫做替罪羊树的平衡树可以不用旋转操作，那还是学这个吧…… 替罪羊树 用处 替罪羊树是一种平衡树，支持插入，删除，查找第k小元素，查找元素的排名等操作 什么数据结构优雅？ 暴力即是优雅！ 替罪羊树就是一种暴力平衡树，旋转？不存在的！ 替罪羊树保持平衡的方法就是暴力重构，即当树不平衡时拍扁重新建树，那么如何才能知道一棵树是否平衡呢？ 在替罪羊树中选用了一种叫做平衡因子的东西，听起来很高端，其实就是一个0.5~1之间的任意浮点数，保持平衡的方法是这样的： 如果一棵树的左子树/右子树的 存在的 节点数量大于这棵树的 存在的 节点数量*旋转因子，那么就要重构这棵树 为什么我特意标出了是存在的节点数呢？是因为替罪羊树的删除不是真正的删除，而是惰性删除。 所以我们就可以写出代表替罪羊树的每个节点的结构体 1 const double alpha = 0.75; //旋转因子 2 struct Node { 3 Node* ch[2]; //左右子节点 4 int key,siz,cover; //key是值，siz是以该节点为根的树的存在的节点数，cover是所有节点数量 5 bool exist; //exist标志该节点是否被删除 6

如何编写可读性好的代码 1. 什么样的代码是可读性好的代码？ “让人阅读你的代码，就像阅读优美的文章一样流畅！” ——这就是好代码！ 把代码当作一篇优美的散文来写！用这样的标准来要求自己，一定会写出好代码，一定会成为一个优秀的程序员。 代码不仅是写给机器编译的，更是写给人看的！ 代码不仅是代码，更是文档！ 2. 先写注释，再写代码；理清思路再动手 清晰的思路是编程行动的良好指南。花点时间思考一下，不要一接到任务就动手编代码，从而陷入技术细节不可自拔。 我一般这样编程： （1）在一个空的函数体内用注释写出自己的思路，如： // 功能说明：XXX private void MyMainFunction() { // 第一步，XXX // 第二步，XXX MySubFunction ();// 实现XXX // 第三步，XXX } // 功能说明：XXX private void MySubFunction() { } （2）理清思路后，在空白处填写自己的代码。 如果某个步骤中实现起来感觉有点麻烦，那就先放一个空的子函数，为这个子函数建一个空的函数体——保证编译始终通过，稍后再填充这个空函数体。这种方法不影响你的整体思路，避免陷入编程细节，同时又让“大事化小，小事化了”。 （3）编完主函数后，填充空的子函数体。 其实是对（1）（2）的迭代。通过主函数的运行效果

关于烂代码的那些事（上） - Axb的自我修养 http://blog.2baxb.me/archives/1343 关于烂代码的那些事（上） 六月 21, 2015 57 条评论 目录 [ 显示] 1.摘要 最近写了不少代码，review了不少代码，也做了不少重构，总之是对着烂代码工作了几周。为了抒发一下这几周里好几次到达崩溃边缘的情绪，我决定写一篇文章谈一谈烂代码的那些事。 这里是上篇，谈一谈烂代码产生的原因和现象。 2.写烂代码很容易 刚入程序员这行的时候经常听到一个观点：你要把精力放在ABCD（需求文档/功能设计/架构设计/理解原理）上，写代码只是把想法翻译成编程语言而已，是一个没什么技术含量的事情。 当时的我在听到这种观点时会有一种近似于高冷的不屑：你们就是一群傻X，根本不懂代码质量的重要性，这么下去迟早有一天会踩坑，呸。 可是几个月之后，他们似乎也没怎么踩坑。而随着编程技术一直在不断发展，带来了更多的我以前认为是傻X的人加入到程序员这个行业中来。 语言越来越高级、封装越来越完善，各种技术都在帮助程序员提高生产代码的效率，依靠层层封装，程序员真的不需要了解一丁点技术细节，只要把需求里的内容逐行翻译出来就可以了。 很多程序员不知道要怎么组织代码、怎么提升运行效率、底层是基于什么原理，他们写出来的是在我心目中烂成一坨翔一样的代码。 但是那一坨翔一样代码竟然他妈的能正常工作。

1.Decompose Conditional (分解条件表达式) 应用场景：你有一个复杂的条件（if-then-else）语句。从if、then、else三个段落中分别提炼出独立函数。 示例： if (date.before(SUMMER_START) || date.after(SUMMER_END)) { 　　charge = quantity * mWinterRate + mWinterServiceCharge; } else { 　　charge = quantity * mSummerRate; } 重构为： if (notSummer(date)) { 　　charge = winterCharge(quantity); } else { 　　charge = summerCharge(quantity); } private boolean notSummer(Date date) { 　　return date.before(SUMMER_START) || date.after(SUMMER_END); } private double winterCharge(int quantity) { 　　return quantity * mWinterRate + mWinterServiceCharge; } private double

EPM版本：11.1.2.4 随着系统应用及时间的推移，存储在Essbase中的数据会越来越多且由于规则的计算，会产生大量空块，进而数据文件膨胀，最终导致在一些特定操作后刷库、重构时，消耗大量的时间重构数据文件，一次刷库、重构甚至耗时几小时！ 理想状态下，我们应该在系统开放之前维护并刷库、重构，但实际情况中我们难免遇到预算等编制过程中需要新增科目等修改稠密维的操作，这个时候重构一次若耗时几小时会对业务造成很大的影响，是不能接受的。所以，提升刷新、重构效率是一件非常重要的事情。 那么，如何提升效率呢？ 我们知道稀疏维修改，不会触发Essbase重构，所以速度很快，耗时大约在秒级。当做了一些特定操作，如稠密维新增member等，刷库时会触发Essbase重构，此时后台将对pag数据文件进行重构，数据越多、数据文件越大（空块会导致数据文件膨胀），重构速度越慢，所以优化的第一个方法就是减少数据文件的大小。 一、减少数据文件大小（操作需谨慎、操作前做好数据备份） ①历史数据归档迁移 将历史数据归档迁移到备份应用中，并将原应用中历史数据及其块删除，注意，如果仅使用cleardata那么仅仅是将数据清除，并不会将删除数据后的空块清掉，所以还需要clearblock操作，具体应用请参考官方文档； ②定期reset、reload数据，消除执行规则产生的空块 二、启用并行重构 减少数据文件大小后

var link="www.marenzy.top"//完整视频资源获取地址,复制链接在浏览器打开 var vx="aishangit666"//如链接失效可添加微信下一代前端开发语言 TypeScript从零重构axios 下一代前端开发语言 TypeScript从零重构axios 下一代前端开发语言 TypeScript从零重构axios vue3.0的代码中98%以上由TypeScript编写，TypeScript是前端的发展趋势，但是很多同学却缺少实战经验，而且市面上缺少TypeScript 的实战课程。本课程首先讲解TypeScript的一些基础语法和常见用法，接着带同学们使用TypeScript一步步去实现一个完整的axios JS库，然后进行完整的单元测试，最后把开发的JS 库打包并发布到npm上。通过课程学习完全掌握axios的实现原理，修炼原生JavaScript内功，提升个人职场竞争力。 下载地址: 基于typescript冲中axios 来源： https://www.cnblogs.com/itjiunian/p/12174151.html