重构

Introduce Explaining Variable 概述 将复杂表达式的结果放进一个临时变量，以此变量名称来解释表达式用途。 动机（Motivation） 表达式有可能非常复杂而难以阅读，临时变量可以帮助你将表达式分解为比较容易管理的形式。 作法（Mechanics） 1、声明一个final临时变量，将待分解之复杂表达式中的一部分动作的运算结果赋值给它。 2、将表达式中的运算结果这一部分，替换为上述临时变量。 如果被替换的这一部分在代码中重复出现，你可以每次一个，逐一替换。 public class IntroduceExplainingVariable { double _width,_higth; //before introducing public double getPrice() { return _width * _higth - Math.max(0, _width - 1000) * _higth * 0.03 + Math.min(_width * _higth * 0.1, 100); } //after introducing public double getPriceAdvanced() { return normalPrice() - quantityDiscount() + shipping(); } public double

Inline Temp 概述 一个临时变量，只被一个简单表达式赋值一次，而它妨碍了其它重构手法。 动机（Motivation） Inline Temp多半是作为Replace Temp with Query的一部分来使用。惟一单独使用Inline Temp的情况是：你发现某个临时变量被赋予某个函数调用的返回值。一般来说，这样的临时变量不会有任何危害，你可以放心地把它留在那儿。但如果这个临时变量妨碍了其它重构手法---例如Extract Method，就应该将它inline化。 作法（Mechanics） 1、如果这个临时变量并未被声明为final，那就将它声明为final，然后编译。 这可以检查该临时变量是否真的只被赋值一次。 2、找到该临时变量的所有引用点，将它们替换为为临时变量赋值的语名中的等号右侧表达式。 3、每次修改后，编译并测试。 4、修改完所有引用点之后，删除该临时变量的声明式和赋值语名。 public class InlineTemp { //before inline-temp public double GetUserSalary(String name) { double salary = userSalary(name); return salary ; } //after inline-temp public double

引用自 Refactoring Improving the Design of Existing Code ---Martin Fowler 1.Extract Method(提炼函数) 2.Inline Method(内联函数) 3.Inline Temp(内联临时变量) 4.Replace Temp with Query(以查询取代临时变量) 5.Introduce Explaining Variable(引入解释性变量) 6.Split Temporary Variable(分解临时变量) 7.Remove Assignments to Parameters(移除对参数的赋值) 8.Replace Method with Method Object(以函数对象取代函数) 9.Substitute Algorithrm(替换算法) 来源： https://www.cnblogs.com/newbee0101/p/11968861.html

通过这次读《从小工到专家》这本书，我认识到了黑板的重要性。黑板，给出的信息可能是图片文字等，我们可以从中了解信息，加上我们自己的发现、我们可能接受了不同的训练，有不同程度的教育背景和专业经验、不同的看法等。但是，我们渴望写出代码的心是一样的。 避免靠巧合编程，有时候巧合是一个很幸运的词，但是，它依旧会带来不幸。所以我们要深思熟虑的编程，总在知道自己在干什么、不盲目的编程、按照计划行事、依靠可靠的事物、为自己的假定建立文档、不要只是测试代码，还要测试假定、划分优先级、不做历史的奴隶。 重构对我们来说是非常重要的。重写、重做、重新架构代码合起来称为重构。因为代码不是静态的，它需要演化。我们应该在重复、非正交的设计、过时的知识、改善性能时进行重构。 来源： https://www.cnblogs.com/dixingchen/p/11965338.html

在了解什么是重构和回流之前，我们应该先看看浏览器是怎么渲染的？ 浏览器的渲染过程： 1.处理HTML脚本，生成DOM树（DOM树里包含所有的HTML标签，包括display:none和js动态添加的元素等） 2.处理CSS脚本，生成CSSOM树（DOM和CSSOM是独立的数据结构） 3.将DOM树和CSSOM树合并为渲染树,render树中不包含定位和几何信息。虽然，render树与dom树类似但还是有区别的。render树中不包含隐藏的节点 (比如display:none的节点，还有head节点)，因为这些节点不会用于呈现，而且不会影响呈现的，所以就不会包含到 render tree中。注意 visibility:hidden隐藏的元素还是会包含到 render tree中的，因为visibility:hidden 会影响布局(layout)，会占有空间。 4.对render树中的内容进行布局，计算每个节点的几何外观 5.将渲染树中的每个节点绘制到屏幕中. 什么是重构和回流 重构 ：当元素的某些属性发生变化，这些属性又只影响元素的外观和风格，而不改变元素的布局、大小比如颜色、背景。此时触发的浏览器行为称作重构。 回流 ：当元素的布局、大小规模和显示方式发生改变时，触发的浏览器行为叫回流。而且，每个页面都会在第一次加载时触发回流。 注意：回流必将引起重绘，而重绘不一定伴随回流。同时

什么样的代码才是美的代码？一千个coders可能会给出一千个答案。今天，让我从一个简单的角度来谈谈对于代码之美的理解。 可读性高的代码才有可能是美的代码 相信大家都有过这样的经历：接手一个项目要修复bug或者开发新功能的时候，发现代码可读性非常差。哪怕是在有说明文档的情况下，都不太敢提交代码，唯恐引入新的bug或者直接导致系统崩溃。 软件系统在代码方面的成本分为两部分，第一部分是开发成本，第二部分是维护成本。 开发成本很好理解，就是把一个系统开发出来需要支付的各种成本，其中最大一块很可能是人力成本。任何一个大型软件系统都不可能没有bug。系统开始运作之后，这些bug可能会导致业务出错、运行缓慢，甚至是宕机，需要程序员找出漏洞并且修复上线。在这一阶段的成本，我们称之为维护成本。 运维成本往往会超过开发成本。我毕业后的第一份工作是在一家ERP公司做二次开发，最早的代码注释时间有十几年前的，常年从事维护开发工作的人员超过十个人。开发需要的时间远比维护的时间要短得多，维护人员的数量并不会比开发人员的数量要少太多。 如果适当增加开发成本可以大幅减少维护成本，那么对节省整体成本有着极大的帮助。 在进入到互联网时代的今天，像ERP这样开发完成之后变化不大的“重”系统已经不多了，模块化、服务化的“轻”系统已经占到绝大多数。这些现代软件系统强调的是迭代开发，以月或者周为单位更新版本

继数据结构与算法之美后，王争老师的专栏又开始更新了，这次是《设计模式之美》，希望学习之后会对自己有所提升。在此记录下自己的学习笔记，希望对自己或者看到的读者都有所裨益。 为什么每个程序员都要尽早地学习并掌握设计模式相关知识？ 1. 应对面试中的设计模式相关问题 学习设计模式和算法一样，最功利、最直接的目的，可能就是应对面试了。 不管你是前端工程师、后端工程师，还是全栈工程师，在求职面试中，设计模式问题是被问得频率比较高的一类问题。特别是一些像 BAT 、 TMD 这样的大公司，比较重视候选人的基本功，经常会拿算法、设计模式之类的问题来考察候选人。 2. 告别写被人吐槽的烂代码 我们经常说， Talk is cheap，show me the code 。实际上，代码能力是一个程序员最基础的能力，是基本功，是展示一个程序员基础素养的最直接的衡量标准。你写的代码，实际上就是你名片。 3. 提高复杂代码的设计和开发能力 大部分工程师比较熟悉的都是编程语言、工具、框架这些东西，因为每天的工作就是在框架里根据业务需求，填充代码。实际上，这样的工作并不需要你具备很强的代码设计能力，只要单纯地能理解业务，翻译成代码就可以了。 但是，有一天， leader 让开发一个跟业务无关的比较通用的功能模块，面对这样稍微复杂的代码设计和开发，就发现会有点力不从心，不知从何下手了。因为只是完成功能、代码能用

浅谈单元测试和重构 隐喻 年纪大了，腿脚不利索，拄着拐杖走路，走的稳不说，还能预防跌倒。 但如果真的跌倒了呢？ 跌倒后有没有人敢扶？扶起来还能不能走？如果能走，走得还能不能像以前那样快？如果不能走，是不是要去医院？ 没了拐杖，产生了灾难性的骨牌效应。 意义 单元测试之于开发人员，相当于老人的拐杖，离开拐杖，也能走，但就是深一脚浅一脚，而且还有随时跌倒的危险，跌倒之后还会产生一系列的问题，搞的人焦头烂额。 在没有单元测试支撑的情况下写代码，你不会知道代码里面有没有逻辑 BUG ，是否符合预期，不能发现编码过程中引入的错误，更不能发现设计和需求中存在的问题。 我曾经所在的一家公司，开发人员是不写测试的，他测试自己代码的方法，是写完之后运行一下，点点看有没有问题，效率低下容易漏测不说，还很业余，简直侮辱软件工程师这个高大上的职业（看我鄙视的眼神）。 假设你写了一个服务，每写一个方法你都写单元测试将方法中的路径全覆盖掉，如异常， if-else, switch 语句等，刚准备提交，突然接到通知，需求变了，你不得不改动编码逻辑，这个时候怎么办呢？首先要跑一遍单元测试，确保你当前功能的测试全跑通，然后分析需求，按照要求对相应的代码进行了修改，之后，修改或增加单元测试对改动代码进行覆盖，你点下了开始按钮，看着所有测试都打了绿色的对勾（ ✔），你从容淡定的提交了代码，拿起菜刀，哦不，端起水杯

上一篇 讲到经过上面两篇的优化与重构，整体来说，前面提到的问题，除了性能问题之外，其它问题都已经顺利的解决了。 现在还存在多次扫描处理的问题，也就是说虽然代码结构性重构是成功的，但是性能问题还是没有根本解决。 在给出解决方案之前，需要对这个处理方式缕一缕： 处理方式1：每次遍历全路径找到待处理文件，文件然后批量进行处理。优点是处理起来比较简单，但是会重复扫描。 处理方式2：一次遍历所有文件，然后对每个文件进行注解检测。扫描全路径只有一次，然后要把每个文件与过滤器进行比较如果比较成功那就做，比较不成功就不做。 稍加分析就会发现，两种方式的比较次数是一样的，但是第二种方案遍历文件的次数就少到极限了，还能比1次更少么？？ 这次的做法就有点复杂了（相对的，实际上也很简单）,做一个过滤器，里面放个Map存储过滤器：处理器。 对于每个一个文件，都对所有的过滤器进行校验，如果校验成功，就执行对应的处理器。 public class ComplexFileFilter implements FileObjectFilter { Map<FileObjectFilter,FileObjectProcessor> filterProcessorMap; public boolean accept(FileObject fileObject) { for(FileObjectFilter filter

阅读名著《万物重构》读后感3000字： 上上周趁着京东图书做活动，买了一堆书回来，主要还是小朋友的书了，不过媳妇也给我挑了几本。这几天每天晚上趁着在厕所泡脚的功夫读完了一本，叫《万物重构》，作者是微软中国区的CTO（首席技术官）。书不算厚，200多页，但是行间距比较大，所以看起来还是比较快的，只花了3个晚上，大概总共也就4个多小时看完。下面就介绍一下这本书的内容，还算是比较有意思的。 万物重构 这本书重点介绍目前非常热门的技术话题，按他的话来说就是“云-物-大-智”（云计算-物联网-大数据-人工智能）。从这几个技术发展的角度来看整个人类社会未来的发展趋势。从人类历史的发展过程来看，人类在每一次技术上的进步都会带来一次人类社会的重新分工和社会结构调整，从最远古的原始社会到奴隶社会，到封建社会，资本社会和目前的科技社会，都是技术的发展带来的生产力发展，从而带来了社会结构的变化。他认为现在的云计算，物联网，大数据和人工智能的发展必然会带来一次新的社会分工的重新调整以及社会结构的变化。 世界上唯一不变就的就是变化。他认为整个趋势不可阻挡，我们作为现代人只有去顺应，适应这个社会或者被社会遗弃。在这几种技术驱动下社会的发展和分工的重新洗牌不可避免。而且因为这次变革中物联网的发展，必然会影响到人类、机器设备和其它动植物等的变动，所以他认为这次的技术发展会带来所谓的《万物重构》。 云计算，物联网