注册 登录
电子工程世界-论坛 返回首页 EEWORLD首页 频道 EE大学堂 下载中心 Datasheet 专题

辛昕.九门.上 http://home.eeworld.com.cn/space-uid-115166.html [收藏] [复制] [分享] [RSS]

日志

【反思重构】之二:一次由“重构“引发的血案

已有 982 次阅读2016-9-26 09:43

我的一次非主流重构经历

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

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

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

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

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

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

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

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

说实话,我对于被批评这种事情,不算特别介意,算不上什么过不去的坎。但是,这

一次,我真正难受的是:我终于意识到自己真的错了,而且我依然不明白到底错在哪里,该怎么办?

曾经,我视重构为拯救混乱代码的利器,而如今,它锋利的利刃却划伤了我自己。我

没有办法不去反思。而这个过程非常痛苦——不得不承认,我是一个相当顽固的人。曾经,我身边的所有人(不管在哪一家公司)都反对我重构,但我依然蔫蔫地坚持,我总是隐忍着不去和身边的同事讨论这件事情,我默默一个人顶着可能会发生的所有可能的后果(比如上述)。因为我认为这样做,是对的,然后其实我内心忐忑不安。没有人告诉我,到底怎么个错法,错在哪里。

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

这次,我不仅找到一些技术层面的原因:

比如,我从来就不会真正的构建测试,我也没有耐心和时间去构建测试也比如,我没有真正理解需求,却以自己的想法去替代真实。

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

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

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

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

 

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

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

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

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

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

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

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

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

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

评论 (0 个评论)

facelist doodle 涂鸦板

您需要登录后才可以评论 登录 | 注册

小黑屋|手机版|Archiver|电子工程世界 ( 京ICP证 060456 )

GMT+8, 2018-11-21 02:16 , Processed in 0.015914 second(s), 9 queries , Gzip On, MemCache On.

Powered by EEWORLD电子工程世界

© 2018 http://bbs.eeworld.com.cn/

返回顶部