请记住，最好的重构通常是最终用户看不到的，但却能让开发人员的工作变得更加轻松。它们在不破坏整体系统的情况下，提高了可读性、可维护性和效率。
代码重构如果操作不当，可能会造成巨大损失。功能失调的系统改造或新功能加上错误的重写，毫无疑问会造成损害。至于危害程度如何，人们可以争论不休。
冗长的重构工作之所以被人诟病，是因为大多数重构工作所耗费的时间远远超出了我们的预期。漫长的重构会导致压力、笨拙的代码库、混乱的团队，而且往往看不到尽头
什么时候不应该重构？如果你能把代码当作一个你不需要理解的 API，那么它就可以保持丑陋。作者还建议，不要重构你没有在积极工作的代码。
我的老板邀请我进行了一次一对一的谈话，他们礼貌地要求我还原我的改动。我大吃一惊。旧代码一团糟，而我的代码很干净！ 我勉为其难地答应了，但过了好几年才发现他们是对的。
根据百度百科消息，2023 年 4 月 23 日，新版 Windows QQ 正式开启用户公测，采用全新 QQ NT 架构，并带来了全新交互界面。
近20年过去了，Martin Fowler先生终于推出了新版的《重构》。本人有幸于ThoughtWorks技术雷达十周年峰会现场率先拿到了此书的国内发行版。
本文整理于《重构改善既有代码的设计》，这本书是用java写的，整理的目的是为了自己能写出更健壮、更具扩展性的代码，为以后的编码做参考。
重写大型系统比小型系统风险更高，考虑一下能否逐步重写。我们同时执行了以下几项工作：切换到新的数据库、使用“SOA”架构、更换为二进制协议，其实本可以逐步执行这些更换。
这个机会可能来自于各个方面，比如实现一些新功能或修复一个bug的时候。一个机会是“准备阶段的重构”，在你开始实现任务之前，你发现如果这个现有类的API稍微改变的一点的话，这个任务实现起来可能会更加的容易。这时候，你可以先将它重构为应该有的样子，然后再开始添加你的功能。
统一的代码风格规范是团队开发的重要要素之一。代码规范的统一有利于代码的阅读维护，有利于代码的“集体所有制”。试想，如果团队中每个人都使用自己的一套代码规范，那整体的代码风格就可谓“百花争放”，最后的结果就是代码越来越混乱，且难以阅读维护。我们项目中统一的代码风格概括来讲有如下几个方面：
本文主要起因是，一次在微博上和朋友关于嵌套好几层的if-else语句的代码重构的讨论（微博原文），在微博上大家有各式各样的问题和想法。按道理来说这些都是编程的基本功，似乎不太值得写一篇文章，不过我觉得很多东西可以从一个简单的东西出发，到达本质，
经常听到开发人员抱怨 ，“这么烂的代码，我来重构一下！”，“这代码怎么能这么写呢？谁来重构一下？”，“这儿有个坏味道，重构吧！” 作为一名 QA，每次听到“重构”两个字，既想给追求卓越代码的开发人员点个赞，同时又会感觉非常紧张，为什么又要重构？马上就要上线了，怎么还要改？是不是应该阻止开发人员做重构？
首先，我们这里说的「重构」，和《重构:改善既有代码的设计》这本书中的重构不太一样，这是本好书，它主要说的是代码级别的重构，这种重构是需要在编码的时候时时刻刻进行的，更多的是一种编程思想的训练，而我们这篇的重构主要是说系统设计的重构。
对于如何进行代码重构，一直有着很多种说法。很多人都认为应该将重构代码放在backlog里。但是其实，这并不是一个理想的方法。
第二年夏天，公司拿到了真实收入，我的职位变成了开发主管，公司又招了些新人，正待蓬勃发展，一切都很美好。然后我们做了一个巨大的决策失误：决定重写软件——从头开始。
当日本计算机科学家松本行弘决定创造一种名叫 Ruby (这种技术支撑了 Twitter、Hulu 以及其他许多现代 Web 流行网站) 的程序语言时，他是从 1966 年一部名为 Babel-17 的科幻电影中获得了灵感。
重构软件，就是重组现有的源码，让其更加易读、高效和可维护，这也是所有开发人员时不时都会做的事情。然而，最新研发发现，重构并不会给软件代码质量带来多大的提升。
如果你认为这是一个标题党，那么我真诚的恳请你耐心的把文章的第一部分读完，然后再下结论。如果你认为能够戳中您的G点，那么请随手点个赞。
应该还能用
【外评】谷歌：从源头消除内存安全漏洞
【外评】在 RiSC-V 上运行《巫师 3》游戏
【外评】法官驳回大部分 GitHub Copilot 版权索赔要求
谷歌内部推出 SQL 中的管道(Pipe)语法
你们干扰不了我写开源代码
【外评】FreeBSD 将 Rust 纳入基本系统
【外评】电脑从哪里获取时间？
【外评】为什么 Stack Overflow 正在消失？
有时
