反思重构(更完）

辛昕

反思重构(更完） [复制链接]

 

本来我只想把这些内容发在空间里的日志，毕竟，这不是什么具体的问题或者代码。
而且，反思这种东西，尤其还是出自辛昕的手笔是吧？
太长太难看完。

可是，大表哥看了说，既然是干货，应该发到论坛。
我想了想，那就发吧，反正我自己的 板块 已经吃草很久。

关于重构，其实这个话题，和以前我曾经所关注的，关心的，期待的那些话题
比如
极限编程
测试，还TDD呢
等等等等，其实应该提到过，但是，如同接下来的反思内容。

其实，在这四五年里，我一直处在一种走火入魔的状态。
好了，不多说，具体的内容，请看接下去的内容吧。

内容不会一次发出来，一点一点发。都在这个楼里更新~~

armink

兄弟，总结、反思、复盘，是最好的提升自己思想广度、深度、角度的方式，这点你做的很棒，我也得多像你学习。

虽然一时间很难改变其他人对于 “重构” 的认识，但是自己通过反思，加深了对于软件设计、开发的认识，为以后提供了更好的思路，对自己来说，这也是很大的收获。

“重构”对于不同角色的人、不同层次的人、不同水平的人、不同处境的人认识和使用不一样是正常的。没有绝对的好与坏。我一直以来坚持的理念是“改变是成长的唯一手段”，重构又何尝不是一种更为巨大的改变，所以我也一直鼓励新人去“改变”、去“创新”、去“重构”。

只不过具体执行的过程中，决定权掌握在管理者手里，管理者往往需要考虑的因素太多，判断的结果往往倾向于风险最低的方向，只有这样企业才好更容易的生存下来。等企业发展到一定层面，才有更多的精力和能力去为未来铺路，这时“重构”与“重写”也会大范围的出现。这也是我认为的，那些 BAT 企业在 GitHub 有那么多开源软件一个原因。

辛昕

重构是什么？

    重构，简单地说就是，在不改变软件的外在功能的情况下，对其内部结构做出调整，使其更容易理解、维护，调整和优化软件结构。

    有个地方要特别注意，它和另外两种软件改动行为，性能优化和软件重写是不一样的。

    所谓性能优化，就是指增强或者改善的功能，比如说提高系统的响应速度，减少系统占用的存储空间，既然提升了，改善了，就不叫“外在功能没改变”；

    不同于 软件重写，所谓重写就是抛弃原来的代码，另起炉灶。

    因为重构，指的是在原有基础上做出调整和部分改写。不管是指对某个部分还是系统整体，重写都是“在废墟上堆建新城”，而重构则是“缝缝补补又三年”。

   为什么重构？

    不同的人，对重构的期望值是不一样的，各人有各人的的侧重点。而在那么多支持重构的理由中，其实归结起来就一点：

    代码难以理解，接手代码的人甚至是代码原作者都难以继续维护下去，消除BUG或者是新增功能。

    而重构通过以下的一些手段，可以在很大程度上改观这种情况：

    1.消除重复，重复是代码的大敌，重复不仅造成繁琐臃肿，浪费资源，更会造成修改不一致，容易出现错漏；

    2.使代码，尤其是接口和结构梳理清晰，而清晰的代码更容易理解，也更容易定位BUG，找到合适的添加新功能的地方。

辛昕

     我知道重构这个概念，应该和大多数人一样，源于 Martin Follwer的一本书 《重构：改善既有代码的技术》。

    以后，如无特别注明，Martin Follwer 简称 MF。

    我2011年毕业开始工作，第一家公司非常小，员工其实只有两人，而单片机下位机部分实际上是我一个人独立完成。那时候的我，C语法尚未纯熟，写程序更没章法可言，while(1)之类的东西...如今会被我痛骂，但这种事那时候我也是干得出来的。

    那份工作，做了两年，实际上就只做了那么一个项目，整份代码从零开始，最后总共大概20K行，就单片机C部分而言，算是中等规模项目。如前所述，因为当时写程序毫无章法，而老板在这方面也差不多，谈不上什么指导，所以最后这20K行很是换乱，BUG越来越难，增加功能也越来越慢，维护地十分艰难。

    另一个同事和我是一个学院毕业的，他和我当时半斤八两，所以也说不上什么交流，讨论，相互提高。进入职场的头两年，就是在这样的环境里度过。没有人可以告诉你其实代码应该这样写，你哪里错了，一切全凭自己领悟，自然是非常地苦逼，也非常地非主流。

    所以，完全可以想象我第一次阅读这本书时的激动心情，就像武侠小说里那些被逼上绝路，突然喜获一本武功秘籍的情形。

    但以那时候我的经验和能力，其实是完全驾驭不了的。所以在囫囵吞枣地读了几本关于软件开发思想（涉及 TDD、敏捷、极限编程）的书以后，激动兴奋了好一阵子后，并没有什么卵用，原来怎样写现在还怎样写，没有半点提高。

    不仅如此，这些看起来很好很强大的思想，非但没有帮助，反而如同武侠小说里的 走火入魔——真正是各种杂七杂八的思想，方法，如同几道真气在体内乱窜。

辛昕

       这其中是有好些原因的：
             1.工作/应用领域不一样：我是 单片机/C，大多数时候是 无OS裸机系统。而这些书绝大多数java/C++，大多数应用是 windows/linux或者web应用。
       而那时候的我，缺乏经验，也远没到能借他山之石可以攻玉的地步，因此，尽管我能大致看懂他们在说什么，但很难产生更多共鸣，难以模仿、照搬他们的解决方案和思路。
       2.强调测试，尤其是更密集的单元测试，速度更快的自动测试。
      说起来，测试桩，测试驱动（即对被测试内容的主调环境），以及利用数据模拟外设，这些思路和方法，我都是很清楚的。
      但是，我却很少有足够的耐心和勇气，真的在我的工作代码里，花本来就已经很紧急的工作时限，去添加各种测试代码。
      与其说我懒惰，不如说我不知道应该怎么去实际应用。看起来很美好，但落地却困难重重。

      3.心理上过于希望，这些是万灵丹，能包治百病
      我过于希望，重构（还有敏捷，极限编程等）会是一个解决这些问题的灵丹妙药，我没有过多考虑它的使用条件，副作用等等。但大师们早已告诉过我们:
      软件界，没有银弹。
      如果这句话，我们东方人不太好理解，那我翻译一下就是：
      软件界，没有包治百病的万灵丹。

      关于 银弹 这个说法，我个人的理解是，在西方传说里，吸血鬼是一种如同我们文化里鬼魂或者僵尸一样普遍的鬼魅存在，传说中，吸血鬼刀枪不入，唯独，怕银制的武器，比如银制的子弹，所以才有银弹一说。

       4.我在试图做这些事情的时候，过于鲁莽，急躁
       如同下面的统计和分析，重构不仅不是万灵丹，它更有其自身的不足和缺陷，然而，在我没有足够经验的情况下，又过于鲁莽、武断地试图去模仿这些工作，以至于画虎不成反类犬。甚至惹了不少麻烦（下面我即将写到我最近的一次尴尬经历）。
       同时，又因为身边始终缺乏良好的沟通（后面我逐渐跳到开发人员更多的公司，然而我发现，似乎这方面的讨论一直都很困难）。
       一方面，没有良好的沟通，一方面我又没有令人信服的实践和能力，因此，这件事情更加难往下做。我只好像地下党一样潜入地下，“偷偷摸摸”地做着我认为对的事情。但实际上这更加糟糕，它只会让我更加地鲁莽和急躁，而这是不可能把事情做好的。

      以上种种，导致我最终，实际上，并没有真正了解太多重构这件事本身，在实施的过程也是非常的非主流，就像武侠片里那些上不得台面的无名小卒，即无法与人进行更多讨论，及时纠正自己，又深深希望重构能拯救人生，最终，就落得如此的尴尬场面。

ywlzh

okhxyyo

我认真的看完已发部分了。

白丁

看不懂也硬着头皮看完了

辛昕

白丁 发表于 2016-9-22 22:22
看不懂也硬着头皮看完了

哪些地方看不懂？

辛昕

    最近的一个项目，基于一个其他项目，根据新的需求，对功能做一些裁剪，然后自己测试一把，通过没问题，就可以正式发布给测试组，通过了就可以了。
    因为是单片机项目，硬件上难免有些小改动，比如说某些引脚发生了变化，比如说显示从显示屏换成了LED等等。相对来说，改引脚一般就是修改一个宏的事情，但是，从LCD屏换到LED屏，这里面可以玩的就比较多，事情就出在这里。
    我们组的项目，基本都以这个原始项目为基线，因此我对这个项目的代码相当熟悉，因而我也一直深深痛恨它的繁琐，臃肿。好不容易到了一个由自己主导的项目（固件部分），        我就决定乘着这个LCD到LED屏不一样的“时机”，对它进行修改。（对，就是我自认为的重构）。因为这套代码，经过很多次项目需求变更，经过很多人的手，一方面是千锤百炼，另一方面也可以说是千人千面。而我偏偏又是一个代码洁癖综合征患者。
    终于，在以上种种因素的作用下，这次，我干了，并且“我的重构主张第一次得到了来自领导的注意”——可惜，注意的方式和原因有点特别。        
    因为我破坏了几个原有功能，导致项目在最后几天如同惊险过山车，尽管最后有同事支援补救，勉强顶过结项，然而我这个不安分子还是被领导提溜了起来。其实我们领导平时挺开明也好说话，对我们也算是百般纵容，有这样一个领导不容易，然而还是第一次被吊了起来做典型。
      

辛昕

    和所有软件悲剧一样，基本上，所有的问题都出在对需求的理解有误。这次的需求有误倒不是因为项目本身使然，而是我一直就没怎么正确理解过需求
    这里有很多原因，原因之一，我们从来没有正式的需求文档，更谈不上什么需求评审，确认，大多数时候都是口头交流，所以相互扯皮，理解有误的事情非常常见，哪怕是像我这样干了大半年，但因为彼此都没有重视确认这件事情，都有可能出现被指责“怎么回事！干了大半年你连这个都一直没理解对！”
    尽管我没有因此受到什么更加严厉的斥责，没有扣钱，更没有像阿里抢月饼那几个哥们被开掉。但是，我受到了来自同事无声的压力——毕竟我成了他们麻烦的制造者。领导第一次在部门会议上指名道姓“提醒”我，还搬出了华为的“所有老项目允许创新的部分都不许超过30%”以及更严厉的说法——“开发打击创新”。
    说实话，我对于被批评这种事情，不算特别介意，算不上什么过不去的坎。但是，这
一次，我真正难受的是：我终于意识到自己真的错了，而且我依然不明白到底错在哪里，该怎么办？
    曾经，我视重构为拯救混乱代码的利器，而如今，它锋利的利刃却划伤了我自己。我没有办法不去反思。而这个过程非常痛苦——不得不承认，我是一个相当顽固的人。曾经，我身边的所有人（不管在哪一家公司）都反对我重构，但我依然蔫蔫地坚持，我总是隐忍着不去和身边的同事讨论这件事情，我默默一个人顶着可能会发生的所有可能的后果（比如上述）。因为我认为这样做，是对的，然后其实我内心忐忑不安。没有人告诉我，到底怎么个错法，错在哪里。
    大家都很忙，没人有权利去管你的那么多为什么，而我也不擅长沟通。假如——不是这次，闹出了这么一个不大不小的祸端，也许，我永远不会真正去反思这件事情。
这次，我不仅找到一些技术层面的原因：
比如，我从来就不会真正的构建测试，我也没有耐心和时间去构建测试也比如，我没有真正理解需求，却以自己的想法去替代真实。
    但这些都不是最重要的。这次最重要的收获在于，我第一次认识到，我必须放下自己的自以为是，尝试着用一个我并不习惯的角度去思考问题：如果，他们那么反对重构，那到底是为什么？
    于是就有了以下的一些反思和最终通过搜索百度完成的统计：你为什么反对或者支持重构？

辛昕

    以前，我简单地把这归结为他们的不思进取，守旧保守。然后选择和包括MF在内的大多数程序员那样的消极态度：不告诉他们，不和他们商量，按照自己的想法去做。
    MF，或者其他也很牛很厉害的程序大牛，也许可以任性地按照自己的想法去做，然后不会闯祸，不会搞砸事情，所以，他们不需要和别人商量，得到别人的首肯，他们甚至可以以自己的技术影响力带动身边的程序员，让他们自觉加入重构支持者的队伍。
    但是，我不行，我，只不过是一个拥有五年开发经验，技术上不上不下，青黄不接。自保尚且未必有余，遑论影响他人。其实说实在的，除了C语法纯熟，对单片机开发具有一套自己的套路以外，其实，别无所长。所以，在顽固地坚持自我的时候，总有一天会惹出麻烦。
    不过，这次，我庆幸自己现在就闯祸，现在就被逼到南墙，然后，开始换一个角度，真正地去思考站在我对面的群族的反对意见。
    重构有足够的好处和吸引力，但是长期以来，我们对于那些反对的声音都是选择忽略性的消极态度。支持者和反对者双方都消极而粗野地反对对方，这实际上掩盖了很多真相。
   

辛昕

    包括MF在内——百度搜索的文章里，有一篇提到一个观点：几乎所有的关于重构的书都有论及这个问题，而且基本都是单独开一章节，来阐述诸如“你如何向身边的人或者领导解释你为什么要重构”。
    我没有做过验证，我看过的关于重构代码的书只有两本，一本是 MF的，一本是 Michael Feather的（好吧，我刚发现，他也是MF）《修改代码的艺术》。是，这本书尽管谈及的是如何修改代码，但其实他的书里有许多部分讲述的都是 重构。
    其他的书我没有看，不知道还有什么新鲜观点，但是，即使Martin Follwer本人，他对于如何解释重构，尤其是在如何说不通“不懂技术的领导”的时候，他选择的，也不过是消极地选择不解释，然后偷偷摸摸地做自己实际想做的事，用自己的方法去做。
    而我自身的经验告诉我，这样偷偷摸摸地按照自己的想法去做，或者我们干脆点，承认自己是 肆意妄为，通常都会很惨——别问我怎么知道的，请叫我活雷锋。
    因为我越来越发现，软件开发和许多事情一样，沟通非常重要。过去我总是一人负责一个项目，没什么机会和身边的同事，尤其是同为嵌入式固件开发的同事有过什么有效沟通。这导致我走了很多弯路。孤胆英雄注定是悲情的。

辛昕

下一次，下一次更新。
就会到这次反思的最关键部分。

看我是如何用百度搜索来完成这项我认为很重要的调查的？

如果你那么反对重构，到底是为什么？
我们这么支持重构，又是为了什么？

不能只看到支持的一面，现在起，我们也要看到我们对岸的人的意见，只有不偏颇，才能更加看到事情的真相，以及推动事情按照我们希望的方向发展

jack4103

辛昕

    当我尝试这样询问身边的同事的时候，我发现他们要么根本不知道重构是什么，要么把重构和重写混为一谈，更有甚者在知道了重构的定义以后，直接粗暴的说，那我还不如重写！
    所以我决定换一个方式，利用网络搜索工具，听到更多的人的意见。
    关键词：“周围的同事不愿意代码重构怎么办？”
    搜索工具：百度

    最开始我想知道的主要是：人们为什么会那么反对重构。               
    所以这个关键词具有一定的指向性，但48页的搜索页结果，其实已经消除了这个指向性，其中充斥着大量比我更为狂热的重构支持者。
    最后需要说明的是，为什么采用中文搜索工具？
    按我的经验，搜索技术话题，英文最好，中文经常是大量重复，而仅有的几篇内容也通常流于平庸。但这次，我仍然选择中文，理由有二：
    1.我生活工作在中国，所以我想知道的答案应该更多来源于读写说用中文的人。
    2.虽然我用英语阅读技术资料不会特别困难，但我预测这次的搜索统计需要阅读大量文章，所以用中文会比英文更加流畅。
    当然，最重要的还是第一个理由。
    对于每一篇文章或者帖子（重复的不算），一般来说，都会有作者对重构的态度，此外，帖子回复者，文章评论者，也会表达自己的意见。作者和每个回复，评论者都作为一个独立的个体。我把他们的观点提炼，列在表格里，出现重复的计数。
    最后，再做统计，以期得到最多人关心，最多人介怀的地方。
    这里需要说明的是，这个统计的数值不能作为一个精确的结果。因为，是我在对内容做过滤和提取，不管我如何试图客观，仍然有所难免。此外，由于工作跨越的时间比较长，我在不同状态下的提取和过滤结果也不尽相同。
    我这么看待这个结果，它就像给类似于喜爱，厌恶，满意等的程度做个分值量化，0~5分比如说。数值的绝对值本身没意义，重点在于数值的相对大小。

辛昕

按照上一目提到的方式，大量统计了48页百度搜索页的表格后，按照四个方面去总结统计结果。
1、为什么反对重构？
2、为什么支持重构？
3、重构需要的条件；
4、重构需要注意的事项；

    核心的是前两个，它们完全相对。有一种可能是，同一种论述、客观事实都将被双方引用。反对者认为它是反对重构的原因，而在支持者眼里，它可能会成为需要注意和提前准备，扫除障碍的点。
    在这种情况下，我们不认为这是简单重复，因为事实上这些重合点，很可能正是整合反对者和支持者的关键区域。支持者可以通过提出针对它们的有效处理方式，消除反对者的疑虑，从而推动双方达成某种程度的一致。

辛昕

    1-1.重构即便成功，它也不产生直接效益（毕竟不改变现有软件功能），它也只能让开发者证明自己的能力，只对开发有作用，而对其他环节毫无价值——而那些环节可能恰恰是真正价值所在）。
    1-2.即使经过重构的代码，当变化来临时，或者产生了新的想法和意见时，你又得继续重构，这容易产生一种强迫症，没完没了。（4）
    1-3.重构好的代码能否达到原来的水准（或是否能比原来好？），是否会改变原来的成果；/ 可能会引入新BUG，需要额外时间去修复（5）
    1-4.该系统很关键；
    1-5.你对系统来说，或者说对于团队，项目，语言来说，是新手；
    1-6.你没有时间去充分理解，但代码逻辑对你来说很复杂/你其实不了解业务；
    1-7.积极重构，然而却引发了系统崩溃等严峻的后果时，是难以承受的职场压力；
    1-8.好的重构成功率并不高/重构不容易/很难按照小步骤的计划去执行；        （3）
    1-9.目前并没有出现性能瓶颈，而且性能优化应该向后推；
    1-10.根本就没得救了，干脆推倒重写；

    结论：
   重构本身是有风险的，轻则做的不如从前，重则导致崩溃死机。
   另外，重构的实施需要投入很多东西，但重构即使成功也不会带来什么直接效益，相反，实施重构需要相当的资源投入（详见下列第三点：重构的条件）。
   很多时候，重构要求实施者对项目具有相当的了解，和技能方面相当高的要求。
   没有直接好处，却有风险，而且对人员资源要求高，自然也就反对重构了。

辛昕

    2-1.因为原有的代码经过很多人的修改，风格混乱，接口和结构混乱，各模块耦合地非常厉害），难以理解，而重构可以使其清晰。（5）
    2-2.（主观）感觉很好很酷，代码很漂亮，结构好懂。或因为完美主义，为重构而重构。（4）
    2-3.（成功的重构）可以证明自己的能力；（2）
    2-4.当前的代码很复杂，而我确实已经经过完全分析，可以做得更简洁。
    2-5.不知道原作者的意图和这么实现的原因，甚至有的时候原作者已经离职，找不到人/接手的代码本身就有错误或者不完整；
    2-6.重构即使一开始花费了时间，但长远来说，还是速度更快，也更利于维护、修改和扩展（5）
    2-7.代码量减少（尽管不是根本目标，但至少是一个系统良好的信号）
    2-8.BUG少了，不那么容易死机崩溃了。
    2-9.有时直接就顺带解决了新需求（或旧BUG） ——但这样真的好吗？
    2-10.为即将的重写做准备；

    结论：
    大多数时候，遗留代码都是腐烂的：风格混乱，结构接口混乱，模块耦合严重，代码难以阅读，而且缺乏文档，原开发者可能不在或者忘却了实现意图......在这种情况下，无论是维护和扩展都极其困难，而重构尽管一开始需要花费更多时间，但是重构后的代码会更加清晰，对后期维护和扩展都有提速作用。
    只是需要注意的是，很多时候，风格或者代码混乱这种事情，是很主观的，好或者坏，都缺乏量化评价标准。

辛昕

    3-1.个人足够的（技术）能力；
    3-2.改动的代码需要在自己控制的范围内（比如该软件部分是你主导）
    3-3.对原有的项目、代码要有足够的了解； （5）
    3-4.了解代码涉及的实际业务本身；
    3-5.要明确原有代码坏在哪里？要明白重构后的目标，并列出一个清晰的重构方案。（3）
    3-6.要对重构可能引发的危险进行评估，同时还有需要的时间、人力和测试的更多投入；（4）
    3-7.重构完后必须做完善测试，并有时间做回归测试；（3）
    3-8.需要和原作者沟通，并最好得到认可；重构完成后，要进行代码走查，最好有原作者参与；（2）
    3-9.重构完成后，要长期跟进，直到大多数参与人员都能明白为止；

   总结起来：
   1.对项目本身要了解，尤其是涉及的实际业务（这方面，笔者有惨痛经验）；
   2.明确重构的目标，制定具体方案，了解并评估其风险；
   3.重构需要相当的时间人力测试等资源投入；
   4.最后一点很重要也是长期被忽略的，与人的沟通，重构涉及的最重要的沟通是与代码的原作者或者所在的团队人员；

辛昕

    4-1.重构要小步伐进行；
    4-2.把重构控制在一个尽可能短的周期内完成；
    4-3.除非是一些轻量的重构动作（如重命名），否则一个时间段内只该做一个重构；
    4-4.改动要从 轻的小的重构动作（如整理代码外观和重命名函数）到 较大的重构动作（如抽取重复的代码，提炼方法、类等）过渡；（2）
    4-5.改动要尽可能独立化，或者说其他措施，已保证很容易哪里出了问题（并回到安全点）。
    4-6.涉及框架和结构的重构很难；
    4-7.当你试图重构时，如果需要和人协作，并且对方比你资深而且拒绝重构，将很困难；
    4-8.当你的重构得不到支持（而你还是坚持要做的时候），你一定会忐忑不安，害怕出错，害怕出错后被指责。
    4-9.在得不到支持的情况下，你可能需要先重构，并且自己完全测试，再和别人说（这真的不是好事）。
    4-10.在项目时间很紧或者项目尾期的时候，不宜重构；（2）
    4-11.重构必然是会引起时间延迟的。（2）