一个软件工程师的反思：我的一次非主流重构经历

上期导读：一个软件工程师的反思：关于重构

我的一次非主流重构经历

最近的一个项目，基于一个其他项目，根据新的需求，对功能做一些裁剪，然后自己测试一把，通过没问题，就可以正式发布给测试组，通过了就可以了。

因为是单片机项目，硬件上难免有些小改动，比如说某些引脚发生了变化，比如说显示从显示屏换成了LED等等。相对来说，改引脚一般就是修改一个宏的事情，但是，从LCD屏换到LED屏，这里面可以玩的就比较多，事情就出在这里。

我们组的项目，基本都以这个原始项目为基线，因此我对这个项目的代码相当熟悉，因而我也一直深深痛恨它的繁琐，臃肿。好不容易到了一个由自己主导的项目（固件部分），        我就决定乘着这个LCD到LED屏不一样的“时机”，对它进行修改。（对，就是我自认为的重构）。因为这套代码，经过很多次项目需求变更，经过很多人的手，一方面是千锤百炼，另一方面也可以说是千人千面。而我偏偏又是一个代码洁癖综合征患者。

终于，在以上种种因素的作用下，这次，我干了，并且“我的重构主张第一次得到了来自领导的注意”——可惜，注意的方式和原因有点特别。

因为我破坏了几个原有功能，导致项目在最后几天如同惊险过山车，尽管最后有同事支援补救，勉强顶过结项，然而我这个不安分子还是被领导提溜了起来。其实我们领导平时挺开明也好说话，对我们也算是百般纵容，有这样一个领导不容易，然而还是第一次被吊了起来做典型。

和所有软件悲剧一样，基本上，所有的问题都出在对需求的理解有误。这次的需求有误倒不是因为项目本身使然，而是我一直就没怎么正确理解过需求。

这里有很多原因，原因之一，我们从来没有正式的需求文档，更谈不上什么需求评审，确认，大多数时候都是口头交流，所以相互扯皮，理解有误的事情非常常见，哪怕是像我这样干了大半年，但因为彼此都没有重视确认这件事情，都有可能出现被指责“怎么回事！干了大半年你连这个都一直没理解对！”

尽管我没有因此受到什么更加严厉的斥责，没有扣钱，更没有像阿里抢月饼那几个哥们被开掉。但是，我受到了来自同事无声的压力——毕竟我成了他们麻烦的制造者。领导第一次在部门会议上指名道姓“提醒”我，还搬出了华为的“所有老项目允许创新的部分都不许超过30%”以及更严厉的说法——“开发打击创新”。

说实话，我对于被批评这种事情，不算特别介意，算不上什么过不去的坎。但是，这一次，我真正难受的是：我终于意识到自己真的错了，而且我依然不明白到底错在哪里，该怎么办？

曾经，我视重构为拯救混乱代码的利器，而如今，它锋利的利刃却划伤了我自己。我没有办法不去反思。而这个过程非常痛苦——不得不承认，我是一个相当顽固的人。曾经，我身边的所有人（不管在哪一家公司）都反对我重构，但我依然蔫蔫地坚持，我总是隐忍着不去和身边的同事讨论这件事情，我默默一个人顶着可能会发生的所有可能的后果（比如上述）。因为我认为这样做，是对的，然后其实我内心忐忑不安。没有人告诉我，到底怎么个错法，错在哪里。

大家都很忙，没人有权利去管你的那么多为什么，而我也不擅长沟通。假如——不是这次，闹出了这么一个不大不小的祸端，也许，我永远不会真正去反思这件事情。

这次，我不仅找到一些技术层面的原因：
比如，我从来就不会真正的构建测试，我也没有耐心和时间去构建测试也比如，我没有真正理解需求，却以自己的想法去替代真实。

但这些都不是最重要的。这次最重要的收获在于，我第一次认识到，我必须放下自己的自以为是，尝试着用一个我并不习惯的角度去思考问题：如果，他们那么反对重构，那到底是为什么？

于是就有了以下的一些反思和最终通过搜索百度完成的统计：你为什么反对或者支持重构？

有时候MF大神也只是消极地“做了再告诉boss我重构了”

以前，我简单地把这归结为他们的不思进取，守旧保守。然后选择和包括MF在内的大多数程序员那样的消极态度：不告诉他们，不和他们商量，按照自己的想法去做。

MF，或者其他也很牛很厉害的程序大牛，也许可以任性地按照自己的想法去做，然后不会闯祸，不会搞砸事情，所以，他们不需要和别人商量，得到别人的首肯，他们甚至可以以自己的技术影响力带动身边的程序员，让他们自觉加入重构支持者的队伍。

但是，我不行，我，只不过是一个拥有五年开发经验，技术上不上不下，青黄不接。自保尚且未必有余，遑论影响他人。其实说实在的，除了C语法纯熟，对单片机开发具有一套自己的套路以外，其实，别无所长。所以，在顽固地坚持自我的时候，总有一天会惹出麻烦。

不过，这次，我庆幸自己现在就闯祸，现在就被逼到南墙，然后，开始换一个角度，真正地去思考站在我对面的群族的反对意见。

重构有足够的好处和吸引力，但是长期以来，我们对于那些反对的声音都是选择忽略性的消极态度。支持者和反对者双方都消极而粗野地反对对方，这实际上掩盖了很多真相。

包括MF在内——百度搜索的文章里，有一篇提到一个观点：几乎所有的关于重构的书都有论及这个问题，而且基本都是单独开一章节，来阐述诸如“你如何向身边的人或者领导解释你为什么要重构”。

我没有做过验证，我看过的关于重构代码的书只有两本，一本是 MF的，一本是 Michael Feather的（好吧，我刚发现，他也是MF）《修改代码的艺术》。是，这本书尽管谈及的是如何修改代码，但其实他的书里有许多部分讲述的都是 重构。

其他的书我没有看，不知道还有什么新鲜观点，但是，即使Martin Follwer本人，他对于如何解释重构，尤其是在如何说不通“不懂技术的领导”的时候，他选择的，也不过是消极地选择不解释，然后偷偷摸摸地做自己实际想做的事，用自己的方法去做。

而我自身的经验告诉我，这样偷偷摸摸地按照自己的想法去做，或者我们干脆点，承认自己是 肆意妄为，通常都会很惨——别问我怎么知道的，请叫我活雷锋。

因为我越来越发现，软件开发和许多事情一样，沟通非常重要。过去我总是一人负责一个项目，没什么机会和身边的同事，尤其是同为嵌入式固件开发的同事有过什么有效沟通。这导致我走了很多弯路。孤胆英雄注定是悲情的。

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

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

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

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

to be continue……