强迫症与代码洁癖

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

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

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

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

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

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

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

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

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

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

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

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

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