50多岁的程序员不合群、写防御性代码，能力再好又能怎样？

是不是年纪大一些的程序员都喜欢写防御性代码？我已经见过好几个了，基本上都是40岁以上的程序员，但是，我以前见到的，基本上都是在代码里面埋坑但是不说的，这回我们公司这个年纪超过50岁的程序员不光脾气不好，还把防御性代码摆在了明面上！需要说明的事，接下来我所说的事情仅仅只是我所遇到的情况，不代表广大大龄程序员。

我们公司有个50多岁的程序员，下面就叫他老常吧，说起来，老常还是我招聘进来的，当初面试老常的时候，我就知道他不是个好说话的人，再加上年纪大了，所以我有些犹豫。

但是，本着只要能干活，其他无所谓的心态，面试完老常后，我还是在老常的简历上写了一个“OK”，并标明“可能有点难沟通”。

当时我们公司也缺人，尤其是老常是专门写运动控制模块的，这部分本来人才就少，碰到老常这种几十年工作经验的，我和老板也比较谨慎，生怕因为年龄歧视导致流失了一个人才。

事实证明，我们的选择是没有错的，老常的工作效率和在运动控制这块的经验真是无人能比，基本上专业知识信手拈来，几乎碰到任何问题不管是软件上的还是硬件上的，都能轻松找到问题点并且解决。

总之，说老常是个运动控制方面的专家，也一点不为过。

但是，很快问题就出现了，我们发现，老常在分工协作方面显得非常霸道，基本上团队所有人都得按照他的思路来，只要有人没有按照他的思路来，老常就会和那个人争得面红耳赤。

慢慢地，大家为了不和老常产生冲突，和老常讨论问题的时候总是会观察老常的情绪，只要老常表现出一点不耐烦的意思，就只能妥协，按照老常的方法来。

其实，这种情况，对于团队管理来说，其实是不对的，虽然老常可能是运动控制方面的专家，但是也仅限于运动控制，像其他方面，比如说系统架构、机器视觉、用户体验方面考虑得还是不如团队中的一些其他人的。

更让人难以接受的是，老常总摆出一副只要是他写的代码，其他人都接受不了的态度，意思就是，只要别人改了或者接手他的代码，他就会直接告诉那个人，还不如让那个人重新写一套。

公司是不可能让别人重构老常的代码的，所以有一次有个新项目，软件部分都是一样的，只不过需要新增一些功能，但是老常在其他项目，所以公司就安排了一个另外一个同样是做运动控制的程序员老胡，让老常把代码跟老胡好好讲讲，争取让老胡在老常的代码基础上去新增功能。

老胡兴冲冲得去找老常，结果碰了一鼻子灰，老胡不管有什么问题，老常在旁边一言不发，搞得老胡很尴尬，老胡也是40岁左右的人了，但是脾气很好，见老常总是一副看不见他的样子，只得自己闷头去研究老常的代码去了。

后来，这事后来老常自己表示，每个人的代码思路都不一样，他之所以不让老胡在他的代码基础上改，就是觉得老胡的思路跟他不一样，还不如重新写一套。

道理虽然是这样，但是这是一个团队，总不能每个人只负责一套系统吧，不管系统出现任何需要增删改的东西，都只能找当初写的那个人负责？那万一那个人离职了呢？

但是，老常就是不肯合作，最后公司也拿老常没办法，只能让老胡自己去研究老常的代码，虽然老胡最终把老常的代码研究清楚了，但是却花了几倍的时间，可憋屈了！

而老常最大的问题就是防御性代码太明显了，最典型的例子就是他和一个机器视觉程序员合作的时候，有个场景，需要标定相机，按照机器视觉程序员的需求，需要老常将多个轴移动到指定位置，然后发送一个消息给机器视觉程序，机器视觉程序通过拍照，寻找标定物，然后得出标定物的位置，从而标定相机位置。

需要标定的位置总共有四个点，业务规则上，标定相机位置也是需要四个点的，用来标定物理距离，但是生产时只需要看两个点的位置，就来纠正物理距离。

四个点的话，需要轴平行移动两次，将四个点的坐标全部作为参数写到标定函数里面去，最终得出相机的物理坐标，其实两个也可以，但是会有些许误差。

机器视觉程序员最开始使用的是两点距离标定的，后来发现这个方法不行，就改成了四个点标定，但是老常不愿意动代码了，每次标定相机物理距离的时候，老常的做法是先做两点坐标标定，然后再手动移动到另外两点上，再做一次两点标定，最后将两次的结果手动算出来，得出一个偏差值，写到代码里。

这么说可能大家不理解，简单的说两点标定做一次会有偏差，但是做两次，将两次的结果相减，会得出另外一个值，这个值就是做一次标定的偏差值。

这个值，是老常靠手动算出来的，并且选择写死在代码里，而不是自动算出来的。

这就是典型的防御性代码了，不管老常是不是这么想的，但是很显然，只要这套系统离开了老常，那么谁也玩不动了！

结语

这几个事情的发生，让公司下定了要找人替代老常的决心，公司决定把希望寄托在老胡身上，并且，老常也感受到了。

在老常眼里，公司这就是“卸磨杀驴”，但是，从公司角度来说，一个人的能力再好，可不服从管理，不愿意别人碰自己的代码，甚至牺牲用户体验，写防御性代码，这是公司接受不了的。