开发人员如何高效编程？

有关技术主管和工程经理职责的文章很多。我们经常会看到的一个相同的主题是：如何提高团队的工作效率。但是在集中精力来提高他们的生产力之前，你可能首先会考虑摧垮生产力的因素是什么，并依据建立一个可靠的基础。不幸的是，尽管30年前《人件》（Peopleware: Productive Projects and Teams）一书就已经出版了，但是至今我们仍然可以看见许多团队由于一些出色（贬义）的做法而遭受巨大的生产力损失！

人人都知道程序员要想完成工作必须要用电脑，但是许多公司却在期望程序员不用思想就能完成工作——这同样不切实际。

因此，在本文中让我们深入探讨妨碍开发人员“进入工作状态”并提高工作效率的12个注意事项。我会按照影响力从高到低逐个讲解这些因素。欢迎大家在下面发表评论！

如果你犹豫下面这些投资是否值得，那么只需想想开发人员的工资。即便只提高10%的生产力也是可观的收获！

打断与会议

在我看来，打断开发人员是首要的生产力杀手。

开发人员不能轻易地回到他们被打断前的状态。他们需要进入开发的思维模式，然后慢慢回到离开之前的状态。这个过程往往需要半个小时以上。打断越多，他们受到的挫折就越多，工作质量就会越差，bug就会越多，等等。

“在我努力工作的时候，你打断我的次数越多，那么我重新回到努力工作状态的时间就越长。如果一整个早上你不停的打断我，那么抱歉我这一天都没有效率可言。”——Reddit上的开发人员。

那么会议呢？会议和打断唯一的不同是会议是有计划的打断，这会让情况更糟。如果开发人员知道他们在做某个任务的中途会被打断，那么他们根本无法完成这个任务。因此，如果他们知道1-2个小时之内要去开会，那么他们无法取得任何进展，因为大多数的工程任务需要的时间远不止1-2个小时。

正如Paul Graham写的那样，“一次会议会将整个下午分割成了两部分，每部分都太小，所以根本无法做任何事情。”

那么怎样才能避免这种情况呢？这个问题是有据可查的，所以你没有任何借口推脱。你可以一大早或午餐前举行简短的会议，避免在中途进行不必要的打断。

微观管理

在不同类型的经理中，采用微观管理的经理在开发人员的生产力方面带来的影响可能是最糟糕的。首先微观管理人往往会带来很多的会议和意外的打断——但糟糕的远远不止是这些。

他们表现出的缺乏信任，会让你觉得他们在不断侵蚀你的技术力和完成工作的能力。任何很有动力的开发人员在被打断的那一瞬间都会消失殆尽。而且这种影响超出了生产力。微观管理可能是导致开发人员离职的首要原因，或者至少是改变团队的原因。

含糊其辞

含糊其辞的表现方式有很多种。例如，bug报告说：“无法正常工作，请修正！”却没有提供足够的信息让开发人员展开工作。顺便说一下，bug报告模板可以帮忙解决这个问题。

或者对某个功能的规范不明确，在这种情况下，开发人员只能依靠自己的直觉开始实现，等到从经理那里获得更详细的预期行为说明后，又不得不重头开始。

优先次序不明确也属于这个范畴。开发人员犹豫他们是否正在做正确的任务，他们花费的这些时间很容易避免。他们只需问问经理为什么他们需要做这个特定的任务（如果优先次序没有定义的话），但是往往他们在这方面遭遇了很多挫折……

海鸥管理

你听说过这个词吗？ 有的管理人员根本没有参与工作，但是他们会突然闯进来然后一顿乱喷。“这个不对，还有这个，这个太差劲了，”然后就又飞走了。我不得不承认这个比喻很形象，但是不幸的是，这种现象发生的频率比我们想象的还要高。

管理人员的这种行为会让开发人员倍感沮丧，尽管他们几个小时之内不会再来搅和，有时甚至几天都不出现。

将别人的功劳据为己有

你是否有过经理或其他开发人员将你辛苦努力了几周的劳动成果据为己有的经历？开发人员非常重视能力。将别人赢得的信誉据为己有实际上是抢占别人的能力或否认别人的能力。

这种现象对开发人员的生产力破坏极大，因为我觉得这会营造非常紧张的氛围，会在很长一段时间内打击开发人员的生产力。

环境——噪音，动力，办公室的设计等

对于非程序员来说这一点可能有点奇怪，但工作环境对开发人员的工作有重要的影响。例如，有一些白噪声（响亮的交流电，或听汽车和卡车的翻滚）可以帮助他们更好地集中注意力。这就是我们这么多人戴耳机的原因！其实我刚刚发现倾听雨声也非常棒！

同样，如果办公室有太多的动静，那么会导致开发人员无法集中注意力！或者把台式计算机的屏幕放在显眼的地方，让管理人员抬头就能看见，那么会产生额外的压力，甚至还会导致打断的发生频率增高。

范围蔓延

项目管理中的范围蔓延（也称为重心蔓延，需求蔓延，特征蔓延，有时甚至被称为厨房水槽综合症）是指不受项目范围控制的变化。如果项目范围的定义不正确，记录不完整或控制不当时，就会发生这种情况。

范围蔓延会导致相对简单的需求变成极其复杂且耗时的怪物！大多数时候在开发过程中大家都会遇到这样的情况。例如，对于一个很简单的功能：

• 版本1（实施前）：功能是“显示位置的地图”；
• 版本2（版本1几乎完成时）：功能更改为“显示位置的3D地图”；
• 版本3（当版本2几乎完成时）：功能再次更改为“显示可供用户漫游的位置3D地图”。

产品定义的流程

乍一看去这一点似乎很奇怪，但实际上很容易理解。

如果产品团队在定义团队的优先级时，没有通过客户反馈或其他方式验证客户对该功能的反应，而且开发人员发现大多数功能最终都没有被使用，那么他们会觉得他们所做的事情都是无用功，这就会导致他们会失去动力。我们都希望感受到自身的影响力，这对开发人员来说可能更为重要！

缺乏对技术债务的考虑

技术债务是为了快速发布软件，故意采用的非最佳解决方案或编写的非最佳代码。承担一些技术债务是不可避免的，而且还可以在短期内提高软件的开发速度。但是，从长远来看，它会导致系统复杂，从而降低开发人员的速度。非程序员往往会低估生产力的损失，而且总是倾向于前进，这就成了一个问题。

但如果永远不优先考虑重构的话，那么不仅会影响生产力，还会影响产品质量。

工具的多样性和硬件

开发人员每天使用许多工具来编程，推送和合并他们的代码。自动化越多越好。如果你使用“古老”的工具，就会影响你的生产力。同样，拥有一个大屏幕还是一台笔记本电脑也会产生影响。对比一下硬件成本和开发人员的工资，只需提高5％的生产率，就可以获得所有投资！所以还犹豫什么，抓紧提供开发人员团队喜欢的工具和硬件（个人的硬件，还有团队的工具）。

方法论的文档

在学写代码的时候，我们都知道应该尽可能多的写注释。也就是说注释太多总好过太少。不幸的是，许多程序员错误地理解成了，必须对每一行代码加注释，这就是我们经常看到下面这样的代码的原因（来自Jeff Atwood的文章《Coding Without Comments》，地址：https://blog.codinghorror.com/coding-without-comments/）：

r = n / 2; // Set r to n divided by 2
// Loop while r – (n/r) is greater than t
while ( abs( r – (n/r) ) > t ) {
r = 0.5 * ( r + (n/r) ); // Set r to half of r + (n/r)
}

你知道这段代码是干什么的吗？我也不知道。问题是虽然代码中加了很多注释描述了代码正在做什么，但没有一个描述了这样做的原因。如果程序中有bug，而你找到了这段代码，那么你将不知道该从哪里入手。

过于紧迫的截止期限

最后一个与管理者相关的问题是他们要求开发人员提供预估工时，但是他们会鼓动开发人员将这些预估尽可能降低，然后神奇地将这些降到最低的预估当成最后的截止期限！管理人员甚至还会认为，这是开发人员自己“决定”的预估，他们承诺在截止期限之前完成，因此这个截止期限理应有效，可以与高层管理人员共享。

开发人员认为这些截止期限不合理，过于紧迫，这一点也不奇怪。结果就会造成紧张的氛围，让程序员无法集中注意力。

为什么这些注意事项是开发人员特有的？

如果你仔细看看上述十二大注意事项，就会发现实际上对于大多数其他项目的工作来说这些问题也很常见。只是它们对开发人员的影响更为重要，因为开发人员需要精神高度集中，全神贯注到他们的任务中去。

如果你觉得你们公司内部也有上述某些问题，那么与开发人员讨论这些问题可能会很有趣。与他们交谈，然后找出问题的解决方法。无论他们说什么，最重要的是相信他们的反馈和见解。

虽然今天的技术与30年前截然不同，但教训仍然是相同的。在考虑团队生产力的时候，你不能忽视人为因素。与你的团队一起考虑你们的流程，环境和工作习惯，让他们帮助你获取最大的生产力和影响力。

ps：关注公众号：Java架构师日记