重构

参考书籍： 《重构 改善既有代码的设计 第2版》马丁 福勒著 人民邮电出版社 马丁 福勒的其他著作：《分析模式》，《UML精粹》，《领域特定语言》 目录 这本书一共有12章，像代码的坏味道，测试体系这类词已经屡见不鲜了。 第1章：重构，第一个示例 第2章：重构的原则 第3章：代码的坏味道 第4章：构筑测试体系 第5章：介绍重构名录 第6章：第一组重构 第7章：封装 第8章：搬移特性 第9章：重新组织数据 第10章：简化条件逻辑 第11章：重构API 第12章：处理继承关系 关于重构的定义 作者对于重构的定义有着非常严谨的要求，我提炼一下，大概是这个意思： 在不改变软件可观察行为的前提下，提高代码可读性。 嗯，差不多没了。关于代码可读性这个话题是具有一定适应范围的，对于一个简单的应用并不显得重要，但对于复杂的业务系统就显得十分关键。试想一下，如果5000行代码写的乱七八糟还能咬咬牙硬着头皮看一下；倘若是50万行乱七八糟的代码......就只能......你懂的！ 代码的可读性对于后续代码维护，代码修改起到了相当重要的铺垫作用。 来源： https://www.cnblogs.com/noneplus/p/12047378.html

LLE(locally linear embedding)降维算法 LLE(locally linear embedding)LLE 即局部线性嵌入算法，它是一种非线性降维算法。该算法核心思想为每个点可以由与它相邻的多个点的线性组合而近似重构，然后将高维数据投影到低维空间中，使其保持数据点之间的局部线性重构关系，即有相同的重构系数。在处理所谓的流形降维的时候，效果比 PCA 要好很多。 LLE 降维算法展示 详细内容可参见《LLE 原理及推导过程》 https://blog.csdn.net/scott198510/article/details/76099630 代码地址： https://github.com/heucoder/dimensionality_reduction_alo_codes/tree/master/codes/LLE 来源： CSDN 作者： Luara_lyy 链接： https://blog.csdn.net/weixin_40801364/article/details/103553959

using UnityEngine; public class Platformtool { public static bool IsAndroid { get { bool retValue = false; #if UNITY_ANDROID retValue = true; #endif return retValue; } } public static bool IsEditor { get { bool retValue = false; #if UNITY_EDITOR retValue = true; #endif return retValue; } } public static bool IsIOSiPhone { get { bool retValue = false; #if UNITY_IOS if ((float)Screen.width / (float)Screen.height >= 1.5f) { retValue = true; } else { retValue = false; } #endif return retValue; } } public static bool IsiOSIpad { get { bool retValue = false; #if UNITY_IOS if ((float)Screen.width /

无服务器准备： 近两年无服务器是软件开发热门话题。AWS引领这项技术且在不断进步，而各云厂商都具有自己的技术标准，如果要做各个云厂商之前无缝移植，从目前看来几乎不可能，不过我相信对这一技术的创新未来有可能会出现第三方无缝对接或者统一标准，我们期待有这么一天。 由于无服务具备以下突出的优点，如： 1.实现业务快速上线、2.无须运维人员维护基础资源，降低运维成本、3.系统级安全性更高、4.降低开发成本、5.适合微服务框架， 在这些优点吸引下以及大云厂商推荐下，很多用户就会试着把他们原来在On-prem的业务使用重构的方式往Lambda迁移，而这些尝试首先必须要求用户的人员能够在微服务基础上继续拆分成Function的能力，能够把业务做成无状态。 业务演进图1 从原来巨型业务Refactor到Function，这对开发人员要求越来越高，需要开发人员对业务进行细粒度拆分 ，以满足这种新技术的要求。 实践分享： 由于客户原来在On-premises的应用已经无法满足业务的日益扩展，需要对原来的应用进行代码重构后上云。客户没有具备技术很强架构师或开发人员，几乎都是初级外包人员。我们的人工程师协助过客户的外包人员做一个基于Python的Lambda Demo测试之后，他们的外包人员开始自己使用SpringBoot借助Lambda技术对原来的应用进行重构上云

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 可以说,到了今天,我才真正能开始做我想要的重构/改进。之前，只是补充测试，调整了一下结构。 是的，非常的缓慢，这居然被称为“敏捷”!? 你说奇怪不奇怪? 还好，这种节奏适合我这种大龄青年，合用就好，关它是风花还是雪月。 ==》 测试覆盖 上一次漏掉了最重要的异步，测试覆盖: 本以为会秀一个漂亮的100%覆盖率的测试出来，人算不如天算，居然有一个方法是75%！ （本文版权属于© 2012 - 2013 予沁安 ） 恩，无效的生日没有测试。 很简单，就增加一个测试而已，就不在这罗嗦了。直接贴覆盖率，显摆一下。 再显摆一下代码质量参数： 复杂度 最大的就是构造器了。可维护指标还是不错的 76分。 ==>优化改进：属性，静态设值 和其他 零零碎碎的改进，你可以如前面一样，基于一个一个测试纵向改，也可以全部改完在一起测试，没有太大关系，前者是严格的测试驱动。但是，我觉得不需太学术化，关键是，你的任务足够小，能在今天完成，那就是合适。 1。 把所有的信息块改成属性方式，因为，一个是Java与C#的区别，第二，把原代码的缓冲生日的逻辑做到极致（极限编程？呵），一开始就缓冲（构造器中） public string CardNumber { get;private set; } public string AddressCode

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 又是一个清新的早晨, 开始我们新的测试之旅. 2 - 第二个测试, 从身份号取到正确的性别信息. ==>很简单,依葫芦画瓢, 容易的写出第二个测试. （本文版权属于© 2012 - 2013 予沁安 ） ==>很惊奇,居然没有过? 却不知, 测试的旅途中,Failed是常态. ==>好吧, 看看错误在哪? 在取性别代码时,作了验证,而且是全套. 为什么取地址时却不验证呢? 这个不一致性来源于---不是测试驱动,赫赫. ==>解决方案,把验证去掉, 呵呵. 一是解耦, 二是敏捷,还没有测试到的东西,不花过多的时间. ==>搞定. ==>可是,回过头来看测试的两个断言,一个生日,一个性别,毫无相关嘛? 于是,就有了下面的测试拆分: ==>测试类的名称也作了相应的修改,表意性更强. 然后，增加一个女性的测试，只是完善测试路径覆盖而已。 ==》最后，很有成就感的看看测试结果 最后，成品代码和测试： SocialID.cs SocialIDSpecs.cs （本文版权属于© 2012 - 2013 予沁安 | 转载请注明作者和 出处 ） 来源： oschina 链接： https://my.oschina.net/u/871522/blog/94405

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 寻找重构的案例 重构的案例不好选取,我们自己实际的项目当然有不少重构的情况,却不适合作为文章阐述出来。并不是因为保密的考量,而是业务本身的内容太复杂。当然，这个复杂是相对的,对短短一篇文章来说,那怕是最小一部分的业务逻辑拿出来,也显容量不够。而且,过多的阐述业务逻辑,导致喧宾夺主,掩盖了重构的注意力。所以,要选取一个大家都熟悉的东西,身份证号恰恰中了我第一个要求。 即然是重构,必然要有个原始的版本,而且,要完成了实际的功能。开源中国的代码分享也刚好为我提供了一个资源库。代码分享这个平台,真是太理想了,代码规模不大不小,每一个分享又有一个明确的目标功能。 看起来,确实是个金矿。可是随着深入的搜索查看,能进入我目标范围的却是寥寥无几。大部分代码只是粘合剂,把外部库的调用综合起来,完成一个任务而已。还有些代码,方法体太大,而代码却是简单重复,似乎重构的必要,却未能展现出重构该有的不同侧面,而且也有前面所提到的毛病,是粘合剂代码块。 （本文版权属于© 2012 - 2013 予沁安 ） 而当我看到 身份证 这三个字,才眼睛一亮,看似简单的身份征号包括了太多内容: 它是一个典型业务域的 Value Object (不要与C#语法概念的Value Object混淆),我们自己的系统中,刚好也有做一个身份证号值对象的想法

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 首先感谢原作者的代码: 《 面向对象的15位、18位中国大陆身份证号码解析、验证工具 》. 如果有版权问题，敬请告知。 原代码给了我很好的起点，是的，这些代码都是玉，我在这只是再琢磨琢磨。 即使如此，重构的过程依然很繁琐，文章也许会很长，每一次的重构都需要把全部代码显示一遍。 知易行难, 重构是个动态过程, 不那么容易呈现出来,需要点耐心，慢慢看啊。 （本文版权属于© 2012 - 2013 予沁安 ） 1 - 转化为C#代码，增加第一个测试 是的，这不是必须的，可以说是我自己的原因，不会Java。但是，你也可以看作是一种重构的场景，不是吗？ 更改的代码就不再放了，比较简单，与C#和Java的区别有关，留个连接 SocialID.cs 。可是，我的测试代码却很重要。可能很多人会诟病我的测试框架（Machine.Specification)和代码风格。前者，我想以后会多介绍MSpec和BDD让大家根熟悉，后者，只能是希望大家适应了。 ==>写测试 第一个测试代码：当用正确的输入创建身份证时，应该能够得到正确的生日。 namespace Skight.eLiteWeb.Domain.Specs { public class when_create_social_id_with_proper_input {

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 前两天的进度似乎有些慢,今天加快了一点, 不把每一步说的那么详细了. ==》地区信息的提取 继性别和生日之后,最后一个信息块,只是列出测试如下. ==》有效性 这是一个比较大的问题. 前面,我临时性的把不同地方的验证去掉了. 代码原作者也过来, 畅叙了他关于验证的看法. 他是对的, 这种完全验证的方式,根本上说是 DDD的设计思想。不过，想我所说，我知识临时性的去掉，保证测试的单元性。验证的功能，由验证的测试来驱动。而第二点考虑，我的验证打算放在构造器中，也就是说，如果，有任何错误的输入，连第一道门都进不来。 这里，测试和实现都很简单，看起来很多，只是一些罗列，不同的错误场景而已。 [Subject("身份证,有效性")] public class when_create_social_id_with_valid_format { private Because of = () => subject = new SocialID("430103123456780020"); private It should_create_social_properly = () => subject.getCardNumber().ShouldEqual("430103123456780020"); private

一、何谓重构（What） 视上下文的不同，重构有两种定义： 重构（名词）：对软件内部结构的一种调整，目的是在不改变软件可观察行为的前提下，提高其可理解性，降低其修改成本。 重构（动词）：使用一系列重构的手法，在不改变软件可观察行为的前提下，调整其结构。 1、重构的目的是使软件更容易被理解和修改。 2、重构不会改变软件的可观察的行为——重构之后软件的功能一如以往。 在使用重构技术开发软件时，有两种截然不同的行为：添加新代码，以及重构。这便是“ 两顶帽子 ”。 添加新功能时，你不应该修改既有代码，只管添加新功能。通过测试，你可以衡量自己的工作进度。 重构时你就不能再添加新功能，只管改进程序结构，只在绝对必要时才修改测试。 二、为何重构（Why） 1、重构改进软件设计 2、重构使软件更容易理解 3、重构帮助找到bug 4、重构提高编程速度 三、何时重构（When） 这里作者提出：几乎任何情况下，都反对专门拨出时间进行重构。重构应该随时随地进行。你不应该为重构而重构，之所以重构，是因为你想做别的什么事，而重构可以帮你把那些事做好。 三次法则：第一次做某事只管去做；第二次做类似的事，虽然会反感但也可勉强去做；第三次再做类似的事，你就该重构了。 事不过三，三则重构。 1、添加功能时重构 最常见的时机就是给软件添加新特性的时候，可以帮助我理解需要修改的代码。 如果你发现自己需要为程序添加一个特性