强迫症与代码洁癖

每个人都有强迫症,我是比较严重的,所幸的是我早已意识到这点,并用了各种方法去尽力消减其负面影响。

最近,我给自己换了个饮水杯,以前用的乐扣乐扣的那个小茶杯断了一个卡口,我一直用得有些不爽,丢了又可惜,这回总算把它淘汰了,但这货想想看还是有些用的,可以放在家里,临时装些喝的啥的。但断掉的那个卡口令我难受,我得想办法把它复原如初(但这是不可能的),或者——把其它三个卡口也给裁了。于是我用火烧热了小刀,把其余三个卡口削了,再全部磨平,这回终于感觉好多了,至于滤网和杯盖,用不到的东西,扔掉了。

这么一来,我觉得自己是拯救了这个要废弃的茶杯,干了件不错的事情。

我的强迫症似乎是与生俱来的,记得我很小的时候(大约四岁)我父母给我买了个地球仪,我却一直认为这个地球仪不正确,令我不舒服,在我心目中,地球仪应该是这样的:

我不知道为什么地球仪总是“歪”的,为什么不能扶正它?(当然了,现在你不需要跟我解释什么是地轴和黄道面)还有框架为什么只有半边,能不能弄个“全框”的?

令我不适的东西还很多,如:衣服上脱出来的线头,褶皱或部分破损的书页,地板上的一片纸屑,杂乱的电线,通讯录里不知道名字的联系人……解决方法通常是:剪掉、补好、捡起、扎好和删掉。如果我不去做这些,我会很不适,这跟传统的“洁癖”有所差别,我追求的似乎是一种和我心理一致的统一和整齐。但很明显,这样对“极致”和“完美”的追求是很浪费时间的,(有时还会浪费不少钱,但相比时间那是比较小的损失)而得到的好处仅仅是令自己“舒服”了点,心理上的,我开始考虑自己的这个特质是不是应该改改。

事实上,我做得还不错,如前面我提到的那个断了卡口的杯子,我是用了很久,到最近才换掉,我容忍着这个缺陷很久了,我在挑战自己的“极限”,学习如何和这个不完美的杯子共存,如果我只是因为它破损了这么一点点而去换一个新的杯子的话,我得花上一些钱,我需要节省,要知道,这点小瑕疵不影响正常使用啊?我一次次如此般给自己心理暗示,结果就是大大地延长了这个杯子的生命。

世界上没有完美的东西,相信大家都体会,对我而言,这种体会在我前些年玩“刷机”的时候感受特别深刻,那时候拿到了一款智能手机,并且知道它的“ROM”是可以刷的(这是一种不太专业的叫法),于是开始了第一次刷机,但刷完后马上发现了一些小问题,如某个系统程序会出现“闪退”,令人不快,换了一个“ROM”继续刷,刷了之后发现界面风格十分不习惯,难以接受,继续找“ROM”刷,刷完后发现电话有时候会没声音,无法忍受,于是又找了一个“ROM”……完全停不下来啊!这让我想起我拿到我的第一款手机的时候,那时候功能简单,也没有什么“刷机”一说,那手机明显也不完美,但就这样用下去貌似也没什么太大不妥啊?我现在这样折腾来折腾去,有必要吗?

都说“生命在于折腾”,完全不想折腾的人对生活往往是消极和悲观的,因为他已经觉得周围一切跟他无关,而跟“生命在于运动”一个道理,运动要有个度,折腾也要有个度,运动过头了对身体就是损伤而不是有益,折腾过头了也会浪费时间金钱又弄得身心俱疲。所以,道理就在于:如何把握这个度。

自从2003年10月开始从事软件开发这个行当以来,大大小小的项目是做了不少,现在回想起来大多数时候都是一个人在做,即便是一个几个人的项目,也是各自完成自己的部分,这种感觉就有点像给自己的窝做装修,总想装修得尽量好一点,再好一点。编译出来的产品自然是功能正确,但底下的代码看起来也要井井有序,我给自己定了一套编码规则,并严格执行,让一切看起来不错。哪里的变量常量命名不够规范,改!哪里该换行却没有换行,改!哪里的函数调用不够“地道”,改!对同一种操作若不使用相同的方法,改!

但每个人的眼光和能力都是有限的,自己看起来不错的东西别人看起来就未必好了,而且自己也不是一成不变的,昨天认为OK的东西,今天一看就觉得不舒服,这完全有可能,更糟糕的是,对于别人的意见或建议,我这种强迫症患者有着本能的抵触,有些“不是我的我不爱”的味道,所以以前公司的一个高管给我们开会的时候就提到了:工程师是最固执的。我明白这个意思,并且知道这种固执的特质应该是很普遍的。(如果公司里还有设计师的话,我相信那位高管也会把设计师加进去^_^)程序员对自己的代码的这种洁癖很多时候并没有什么坏处,除了会多费一点时间之外,但如果项目大了,要多费的这点时间就变得很可观,即便项目不大,如果在这种细节上太过追求完美,甚至都可以让项目严重滞延。

我一个人战斗的时候,这种对细节的重视令我自己挺满意,我觉得我写的每个程序都是“艺术品”,而且我过去的上司也因此夸奖过我工作认真,但,当我开始作为技术经理,需要给别人安排工作的时候,就再不能有如此般“洁癖”了。对代码的“洁癖”往往会让自己变得有些与人格格不入。我甚至自己一点点去修改同事的代码,以追求和自己的“一致”,但这种行为无疑耗费了我大量时间,让我的工作变成了苦力活而没有时间去思考,不仅如此,同事的积极性还可能因此被降低,每个人都会有些心理保护意识:凭什么你的就是最好的?后来我尝试改变了一下模式。我不再事必躬亲地去查看每一行代码,而是逐步减少自己对具体编码的干预,我把自己的工作变成“培训”和“咨询”,“培训”就是确定了技术框架之后跟大家分享,头头是道地讲为什么这样为什么那样,并且用实际的代码演示,大家都觉得能从我的“培训”中学到一些东西,而不是强硬把自己的观点塞给他们,这样就容易接受很多;“咨询”就是当开发中遇到什么问题的时候,随时拿来跟我讨论,我来给大家寻找解决方案,工作嘛,顺利进展,大家积极性也好了很多,至于代码该换行的地方有没有换行,我想我真的不应该再去管了。

对于一个项目,我如何尽量在设计的时候,就让它足够优秀,这当然会随着自己项目经验的积累而一步步接近,但如前面所说,没什么东西是完美的,我得学会权衡,这比一开始就做出接近完美的设计要靠谱。记得以前听某位“培训大师”说过,性格特质这个东西啊,没有什么优劣之分,要看你如何发挥,你要努力把它的优势发挥到最大,而劣势尽力收敛。是这么个道理。

原文地址:https://www.cnblogs.com/guogangj/p/3597869.html