我决定花些时间梳理一下我程序员生涯中看到的各种问题，看看它们都去哪儿啦。

外科医生剪箭尾

在我博客上的“无Bug不生活”一文中，我罗列了程序员对Bug的态度，感兴趣的朋友可以跳过去看看。

程序员经常这么处理Bug：花上点儿时间撸撸代码，哎呀，找不到Bug出现的根源；再花点时间看看能不能搞点沙土增高一下堤坝（想象黄河河堤的形成过程），嘿，真不错，还真找到了，我只要这里塞点代码堵一下那里扔几个判断围一下，这Bug貌似就不出现了啊……哈哈，有才，搞定，太佩服我自己了耶。说实话，这种策略是把自己当作了外科医生，把软件当做了中箭之人。因为外科医生弄不懂内外科的分别也找不到起出箭头的办法，只好通过剪断箭尾来安抚病人，殊不知箭头还在肉里，要是烂在肉中，病人的疼痛只会更加厉害。

我管不着啊

现在我们开发软件通常都是兵团作战，有时我们就会发现签入到代码库中的某段代码很烂，比如各种条件分支未覆盖全面逻辑不严密，比如变量名凌乱导致可读性很差，比如类库设计不合理违反了单一职责原则（SRP：Single Responsibility Principle）……，此时大部分程序员的做法是：算了，这代码是别人的，我管不了那么多，还是先忙我的吧……

有的程序员在开发过程中会感觉到软件系统设计有问题，就会认为这是系统分析师或架构师的责任，因为我可能没他牛逼或者我也没有更好的解决方法或者我不大可能说服他采用我的方案，于是就放弃了，就按“我只要实现我的模块就行了”这种方式往前走了……

还有的时候开发人员觉得产品某处不合理，交互方式不符合用户使用习惯，但因为这是产品经理的责任，就被“算了，我只负责实现”这种想法给俘虏了……

还有的时候阿猿觉着UI给的这个商品详情展示界面看着色调不协调，可还是放弃沟通照着做出来了……

类似的情况很多很多……

须知我们这么多人叮叮当当忙活，虽然每个人干的事儿不同担的责不同，但其实是在造同一条船，没有谁的工作与别人无关，任何一处出现纰漏，都可能导致我们造出的船无法下水或者倾没深水不能远航。

也许问题不会在用户那里出现

很多软件在测试过程中都会出现一些难缠的Bug：没有规律，几率极小。就连微软这样的大公司发布的操作系统，也要不断地打补丁。

作为程序员，有时遇到一个概率很小的Bug，会因为难以重现而决定先不管它，我们会这么说服自己、测试、产品经理：这个Bug可能是极端操作或操作不当引起的，用户根本不会那么用，所以在用户那里很可能不会出现，就算出现了，按这种概率，也是极个别极个别的用户才会碰到，而我们还有很多其他功能没实现，不能因为这种小概率的Bug影响整体的进度。OK，事就这样成了。可是我们每个人头上都悬了一把达摩克利斯之剑。

要知道，用户环境比测试环境更为复杂，测试环境无法重现的、几率很小的Bug，很可能就被某个用户Duang的碰上了，那对这个用户，发生一次就是百分百啊，对他来讲，根本不存在千分之几万分之几这种鬼东西，他就知道他碰上了，你跟他说这个Bug实在是很难重现真的是小概率事件，任你舌灿莲花屁用不顶，他的痛苦真真切切摆在那里，怎么可能认同你的解释。这个用户失去了，还会有下一个“幸运 ”用户，最终一定是星星之火燃起燎原之势，你的产品口碑会烂到家，然后你的产品十有八九就这么死翘翘了。

我在使用手机时，像App闪退、App停止运行等问题经常会遇到，给人的感觉实在是太差了，你绝对不能让我接受这是无伤大雅的小概率事件，我情感上绝对接受不了你知道吗。

跳过技术难题，别影响进度

软件开发的一个特点就是随时都会遇见未知的问题。比如开发互联网电视产品，很可能会遭遇音视频失步问题，具体表现是有时一个影片刚开始播放几分钟就失步，有时播放半个多小时才失步，有时超过一个小时也不失步，有时在这台机顶盒上失步，有时在那台机顶盒上失步……这个怎么办？

有一种做法是，承认这是个技术难题，一时半会难以解决，别让它影响进度，先跳过去干别的，以后专门抽时间解决它。

这种做法很常见，它的后果也很常见：项目进度还是无可奈何地被这个难题拖累了。

别人都这样

有时你会碰见这种开发团队：执行力差，产出率不高，忙闲不均。作为一个原本追求上进的社会主义四有青年，你看到这种状况往往在开始时感到不正常，想要去改变它，可是久了之后发现你一个普通程序员改变不了什么，要是你执意去做这个事儿劝那个人，反倒把关系给搞僵了，种种担心或实践让你意识到，你不是那个可以改变团队面貌的角色，怎么办？

最后的最后，现实的结果往往是：算了，睁一只眼闭一只眼吧，我管好我自己就行了。更让人不能接受的结果是：大家都这样得过且过，我也没必要这么卖力，于是自己也慢慢放松自己得过且过了。

慢慢向生产率下限看齐，这是非常令人伤心无奈的事实。

我们后面会追上进度

软件项目，延期的占大多数。很多项目，干着干着就感觉要延期了。可是很多团队的项目经理、开发人员在这件事情上却表现得充满童话风格：只要解决了某个问题，只要某某猿加个班往前赶一赶，最终会赶上交付期的……

结果呢……

没奖金没加薪干个什么劲儿

不是每个软件公司都能持续盈利，都能大把大把地发奖金，都能隔三差五地加薪。实际情况是，相当一部分公司在艰难地生存，没有办法发可观的奖金，也没有办法按承诺的节奏加薪。在这样的公司里做开发，程序员会怎么想怎么做？


来源：foruok的博客
本文已发表于《程序员》201505期B。版权所有foruok，网站转载请务必保留出处，微信订阅号转载请先联系我。

我决定花些时间梳理一下我程序员生涯中看到的各种问题，看看它们都去哪儿啦。

外科医生剪箭尾

在我博客上的“无Bug不生活”一文中，我罗列了程序员对Bug的态度，感兴趣的朋友可以跳过去看看。

程序员经常这么处理Bug：花上点儿时间撸撸代码，哎呀，找不到Bug出现的根源；再花点时间看看能不能搞点沙土增高一下堤坝（想象黄河河堤的形成过程），嘿，真不错，还真找到了，我只要这里塞点代码堵一下那里扔几个判断围一下，这Bug貌似就不出现了啊……哈哈，有才，搞定，太佩服我自己了耶。说实话，这种策略是把自己当作了外科医生，把软件当做了中箭之人。因为外科医生弄不懂内外科的分别也找不到起出箭头的办法，只好通过剪断箭尾来安抚病人，殊不知箭头还在肉里，要是烂在肉中，病人的疼痛只会更加厉害。

我管不着啊

现在我们开发软件通常都是兵团作战，有时我们就会发现签入到代码库中的某段代码很烂，比如各种条件分支未覆盖全面逻辑不严密，比如变量名凌乱导致可读性很差，比如类库设计不合理违反了单一职责原则（SRP：Single Responsibility Principle）……，此时大部分程序员的做法是：算了，这代码是别人的，我管不了那么多，还是先忙我的吧……

有的程序员在开发过程中会感觉到软件系统设计有问题，就会认为这是系统分析师或架构师的责任，因为我可能没他牛逼或者我也没有更好的解决方法或者我不大可能说服他采用我的方案，于是就放弃了，就按“我只要实现我的模块就行了”这种方式往前走了……

还有的时候开发人员觉得产品某处不合理，交互方式不符合用户使用习惯，但因为这是产品经理的责任，就被“算了，我只负责实现”这种想法给俘虏了……

还有的时候阿猿觉着UI给的这个商品详情展示界面看着色调不协调，可还是放弃沟通照着做出来了……

类似的情况很多很多……

须知我们这么多人叮叮当当忙活，虽然每个人干的事儿不同担的责不同，但其实是在造同一条船，没有谁的工作与别人无关，任何一处出现纰漏，都可能导致我们造出的船无法下水或者倾没深水不能远航。

也许问题不会在用户那里出现

很多软件在测试过程中都会出现一些难缠的Bug：没有规律，几率极小。就连微软这样的大公司发布的操作系统，也要不断地打补丁。

作为程序员，有时遇到一个概率很小的Bug，会因为难以重现而决定先不管它，我们会这么说服自己、测试、产品经理：这个Bug可能是极端操作或操作不当引起的，用户根本不会那么用，所以在用户那里很可能不会出现，就算出现了，按这种概率，也是极个别极个别的用户才会碰到，而我们还有很多其他功能没实现，不能因为这种小概率的Bug影响整体的进度。OK，事就这样成了。可是我们每个人头上都悬了一把达摩克利斯之剑。

要知道，用户环境比测试环境更为复杂，测试环境无法重现的、几率很小的Bug，很可能就被某个用户Duang的碰上了，那对这个用户，发生一次就是百分百啊，对他来讲，根本不存在千分之几万分之几这种鬼东西，他就知道他碰上了，你跟他说这个Bug实在是很难重现真的是小概率事件，任你舌灿莲花屁用不顶，他的痛苦真真切切摆在那里，怎么可能认同你的解释。这个用户失去了，还会有下一个“幸运 ”用户，最终一定是星星之火燃起燎原之势，你的产品口碑会烂到家，然后你的产品十有八九就这么死翘翘了。

我在使用手机时，像App闪退、App停止运行等问题经常会遇到，给人的感觉实在是太差了，你绝对不能让我接受这是无伤大雅的小概率事件，我情感上绝对接受不了你知道吗。

跳过技术难题，别影响进度

软件开发的一个特点就是随时都会遇见未知的问题。比如开发互联网电视产品，很可能会遭遇音视频失步问题，具体表现是有时一个影片刚开始播放几分钟就失步，有时播放半个多小时才失步，有时超过一个小时也不失步，有时在这台机顶盒上失步，有时在那台机顶盒上失步……这个怎么办？

有一种做法是，承认这是个技术难题，一时半会难以解决，别让它影响进度，先跳过去干别的，以后专门抽时间解决它。

这种做法很常见，它的后果也很常见：项目进度还是无可奈何地被这个难题拖累了。

别人都这样

有时你会碰见这种开发团队：执行力差，产出率不高，忙闲不均。作为一个原本追求上进的社会主义四有青年，你看到这种状况往往在开始时感到不正常，想要去改变它，可是久了之后发现你一个普通程序员改变不了什么，要是你执意去做这个事儿劝那个人，反倒把关系给搞僵了，种种担心或实践让你意识到，你不是那个可以改变团队面貌的角色，怎么办？

最后的最后，现实的结果往往是：算了，睁一只眼闭一只眼吧，我管好我自己就行了。更让人不能接受的结果是：大家都这样得过且过，我也没必要这么卖力，于是自己也慢慢放松自己得过且过了。

慢慢向生产率下限看齐，这是非常令人伤心无奈的事实。

我们后面会追上进度

软件项目，延期的占大多数。很多项目，干着干着就感觉要延期了。可是很多团队的项目经理、开发人员在这件事情上却表现得充满童话风格：只要解决了某个问题，只要某某猿加个班往前赶一赶，最终会赶上交付期的……

结果呢……

没奖金没加薪干个什么劲儿

不是每个软件公司都能持续盈利，都能大把大把地发奖金，都能隔三差五地加薪。实际情况是，相当一部分公司在艰难地生存，没有办法发可观的奖金，也没有办法按承诺的节奏加薪。在这样的公司里做开发，程序员会怎么想怎么做？


来源：foruok的博客
本文已发表于《程序员》201505期B。版权所有foruok，网站转载请务必保留出处，微信订阅号转载请先联系我。