重构

java if else 如果嵌套很深，代码的易读性差和冗余，遇到多个判断条件，适当提前 return，可以让代码结构清晰。 我们下看一个反例，代码如下： public static boolean isInArea( double latitue, double longitude, double areaLatitude1, double areaLatitude2, double areaLongitude1, double areaLongitude2) { if (isInRange(latitue, areaLatitude1, areaLatitude2)) { if (areaLongitude1 * areaLongitude2 > 0 ) { if (isInRange(longitude, areaLongitude1, areaLongitude2)) { return true ; } else { return false ; // 冗余 } } else { if (Math. abs (areaLongitude1) + Math. abs (areaLongitude2) < 180 ) { if (isInRange(longitude, areaLongitude1, areaLongitude2)) { return true ; }

面向过程设计和面向对象设计的主要区别是：是否在业务逻辑层使用冗长的if else判断。如果你还在大量使用if else，当然，界面表现层除外，即使你使用Java/C#这样完全面向对象的语言，也只能说明你的思维停留在传统的面向过程语言上 传统思维习惯分析 为什么会业务逻辑层使用if else，其实使用者的目的也是为了重用，但是这是面向过程编程的重用，程序员只看到代码重用，因为他看到if else几种情况下大部分代码都是重复的，只有个别不同，因此使用if else可以避免重复代码，并且认为这是模板Template模式。 他范的错误是：程序员只从代码运行顺序这个方向来看待它的代码，这种思维类似水管或串行电路，水沿着水管流动（代码运行次序），当遇到几个分管（子管），就分到这几个分管子在流动，这里就相当于碰到代码的if else处了。 而使用OO，则首先打破这个代码由上向下顺序等同于运行时的先后循序这个规律，代码结构不由执行循序决定，由什么决定呢？由OO设计；设计模式会取代这些if else，但是最后总是由一个Service等总类按照运行顺序组装这些OO模块，只有一处，这处可包含事务，一般就是Service，EJB中是Session bean。 一旦需求变化，我们更多的可能是Service中各个OO模块，甚至是只改动Service中的OO模块执行顺序就能符合需求。

面向过程设计和面向对象设计的主要区别是：是否在业务逻辑层使用冗长的if else判断。如果你还在大量使用if else，当然，界面表现层除外，即使你使用Java/C#这样完全面向对象的语言，也只能说明你的思维停留在传统的面向过程语言上。 传统思维习惯分析 　　为什么会业务逻辑层使用if else，其实使用者的目的也是为了重用，但是这是面向过程编程的重用，程序员只看到代码重用，因为他看到if else几种情况下大部分代码都是重复的，只有个别不同，因此使用if else可以避免重复代码，并且认为这是模板Template模式。 　　他范的错误是：程序员只从代码运行顺序这个方向来看待它的代码，这种思维类似水管或串行电路，水沿着水管流动（代码运行次序），当遇到几个分管（子管），就分到这几个分管子在流动，这里就相当于碰到代码的if else处了。 　　而使用OO，则首先打破这个代码由上向下顺序等同于运行时的先后循序这个规律，代码结构不由执行循序决定，由什么决定呢？由OO设计；设计模式会取代这些if else，但是最后总是由一个Service等总类按照运行顺序组装这些OO模块，只有一处，这处可包含事务，一般就是Service，EJB中是Session bean。 　　一旦需求变化，我们更多的可能是Service中各个OO模块，甚至是只改动Service中的OO模块执行顺序就能符合需求。 　

文章首发于 【博客园-陈树义】 ，点击跳转到原文 浅谈重构中踩过的坑 最近重构了公司一个将近10年的核心功能模块，踩了不少坑。在做这个重构的时候好几次都觉得做不下去，好几次压力都非常大，心想着我该不会做着做着就退出编程届了吧。 不过还好，自己还是坚持下来了，回想写这个项目的时候自己曾三次推翻重来，那种心路历程真的只有经历了才知道，真是煎熬。后来回想起这一路踩过的坑，其实更多的是经验问题，而不是技术方面的问题。 关于心态 回顾做这个项目，我觉得心态问题是最重要的，技术问题倒是其次。为什么这么说呢？因为对于10余年的老功能模块来说，其中最复杂的其实是业务逻辑，而并非技术实现。所以对于老系统的重构，你首先需要将这十余年来积淀在该模块的业务逻辑梳理清楚，这本身就给了重构者一个无形的压力。再加上又是核心业务模块，少一点业务逻辑就会导致线上收入的减少，最后就是程序员祭天的悲惨命运。这一系列的背景，使得重构之时心理压力真的很大。 现在回头来看，对于重构项目，最好的方式还是先仔仔细细梳理清楚所有的业务逻辑，之后将其用 思维导图 画出来，这样你会对这十几年来的业务逻辑一清二楚。清楚了业务逻辑，对于你后面进行系统重新设计以及编码都是大有裨益的，甚至是起决定性作用的一环。 说到心态这个话题，无论是做什么项目，即使是重构，也会涉及到排期问题。有时候很可能你自己还没完全了解业务逻辑之时

什么是敏捷开发？ 敏捷开发以 用户的需求变化 为核心，采用 迭代 、 循序渐进 的方法进行软件开发。 敏捷开发模式的分类 XP极限编程（eXtreme Programming） SCRUM 水晶方法 动态系统开发方法 精益开发 其中XP和SCRUM最为流行。 极限编程 极限编程是一种轻量，高效，弹性的软件开发方式。 四大核心价值观 沟通： 完善的流程和详细的文档用于团队协作虽然能够保证一致性，但效率往往不高。 极限编程提倡通过高效的口头沟通来保证整个团队的高效协作。（并不是舍弃流程和文档，只是更加侧重口头上的沟通） 简单： ==今天够用就行。 那么系统的扩展性怎么实现？ 极限编程提倡重构。（对开发人员要求较高） 重构建立在软件开发中无法避免出现BUG的前提下，与其最后修改整体的BUG，不如在一次次的重构迭代中反复扩展优化。 反馈 通过提前编写测试代码，经常性的反馈代码的问题和进展。 在开发过程中，通过持续集成，使得每一次的发布都可以成为可执行版本。 勇气 应用极限编程，每时每刻都在应对变化。这要求开发者时刻面对快速开发，重新开发。 变化在软件开发中是不可避免的，极限编程的思想就是将变化扼杀在摇篮中，避免最后形成一个无法重构的庞大工程。 13个最佳实践 计划游戏 快速制定一个概要的计划，随着项目细节的不断更新和迭代，再完善这份计划。 主要分为三个步骤：客户编写故事

1. 《代码大全》（第二版） 作者: [美]史蒂夫·迈克康奈尔 第2版的《代码大全》是著名IT畅销书作者史蒂夫·迈克康奈尔11年前的经典著作的全新演绎：第2版不是第一版的简单修订增补，而是完全进行了重写；增加了很多与时俱进的内容。这也是一本完整的软件构建手册，涵盖了软件构建过程中的所有细节。它从软件质量和编程思想等方面论述了软件构建的各个问题，并详细论述了紧跟潮流的新技术、高屋建瓴的观点、通用的概念，还含有丰富而典型的程序示例。这本书中所论述的技术不仅填补了初级与高级编程技术之间的空白，而且也为程序员们提供了一个有关编程技巧的信息来源。这本书对经验丰富的程序员、技术带头人、自学的程序员及几乎不懂太多编程技巧的学生们都是大有裨益的。可以说，无论是什么背景的读者，阅读这本书都有助于在更短的时间内、更容易地写出更好的程序。 2. 《程序员修炼之道》 作者: Andrew Hunt /David Thomas 《程序员修炼之道》由一系列的独立的部分组成，涵盖的主题从个人责任、职业发展，直到用于使代码保持灵活、并且易于改编和复用的各种架构技术。利用许多富有娱乐性的奇闻轶事、有思想性的例子以及有趣的类比，全面阐释了软件开发的许多不同方面的最佳实践和重大陷阱。无论你是初学者，是有经验的程序员，还是软件项目经理，本书都适合你阅读。 3. 《计算机程序的构造和解释》 作者: Harold

1.push（p1,p2...）；入栈，在数组最后面添加元素 　　参数：要入栈的元素 　　返回值：数组长度； 2.pop();出栈 最后一个元素出栈 　　参数：none； 　　返回值：出栈元素 结果： shift();出队，第一个元素出队 　　参数：none 　　返回值：出队元素 运行结果： sort(comparator);排队 　　comparator为一个比较器函数，函数可以接受两个值a,b；当a位于b之前的时候返回 　　comparator（a,b）; 　　用 最少代码，完成可以自由选择按照对象id/name/age/grade来升序或者降序排列 　　　　 　　　　排序后结果： 　　　　 重构sort(); 　　利用冒泡排序 　　 来源： https://www.cnblogs.com/ys199610/p/11411001.html

三种错误描述及基本解决方案 1.错误网络异常错误 当网络出现异常（比如网络不通）的时候，发送请求会触发XMLHTTPRequest对象实例的error事件。于是，我们可以在onerror的事件回调函数中捕获此类错误。 我们在xhr.ts中添加如下代码： ... request.onerror = function handleError() { reject(new Error('Network error')) } ... 2. 处理超时错误 我们可以设置某个请求的超时时间timeout，也就是当请求发送后超过某个时间仍然没有收到相应，则请求自动终止，并触发timeout事件。 请求默认的超时时间是0，即永不超时，所以我们首先需要允许程序可以配置超时时间： export interface AxiosRequestConfig { // ... timeout?: number } 接着在xhr函数中添加如下代码： const { /**...*/ timeout } = config if (timeout) { request.timeout = timeout } request.ontimeout = function handleTimeout() { reject(new Error('Timeout error')) } 3. 状态码错误 对于状态码不在200

前段时间做了一个售后商城的项目，由于项目进度比较赶，所以代码质量相对差了很多，现在有时间了因此准备重构一下。 开发语言：Asp.net Core，部署环境：Azure。同步功能使用了Azure function。 首先给大家介绍一下这个项目。 售后商城主要做的是通过APP在线销售虚拟券，就是维护活动产品，以及把经销商放在我们平台的产品售卖，用户买到的产品其实就是虚拟券，可以到Aftersales Client使用。。 先看看项目的架构设计图： 前端主要是H5，通过网关调用后台微服务，我主要后端开发，因此H5就不在此介绍了。 我们公司在构建统一的基础服务，比如： BMW Gateway 公司内部项目网关； Partner Gateway 公司对接外部第三方服务回调网关； Partner Center 合作伙伴微服务（在我们平台卖券的供应商信息管理）； Coupon Center 虚拟券微服务； Product Center 产品微服务（关联券，合作伙伴，以产品的形式展示售卖）； User Center 用户微服务； Order Center 订单微服务； Aftersales Client 券核销终端； Yesway 第三方支付公司。 因此我们的项目是在现有基础服务的基础上进行开发的。而由于产品和订单微服务现在功能还不完善，所以我们还需要把产品微服务里面的数据同步到我们的服务

IntelliJ Idea 常用快捷键 列表(实战终极总结！！！！) 1. -----------自动代码-------- 常用的有fori/sout/psvm+Tab即可生成循环、System.out、main方法等boilerplate样板代码 例如要输入for(User user : users)只需输入user.for+Tab 再比如，要输入Date birthday = user.getBirthday();只需输入user.getBirthday().var+Tab即可。代码标签输入完成后，按Tab，生成代码。 Ctrl+Alt+O 优化导入的类和包 Alt+Insert 生成代码(如get,set方法,构造函数等) 或者右键（Generate） fori/sout/psvm + Tab Ctrl+Alt+T 生成try catch 或者 Alt+enter CTRL+ALT+T 把选中的代码放在 TRY{} IF{} ELSE{} 里 Ctrl + O 重写方法 Ctrl + I 实现方法 Ctr+shift+U 大小写转化 ALT+回车 导入包,自动修正 ALT+/ 代码提示 CTRL+J 自动代码 Ctrl+Shift+J，整合两行为一行 CTRL+空格 代码提示 CTRL+SHIFT+SPACE 自动补全代码 CTRL+ALT+L 格式化代码 CTRL+ALT