如何让开发人员能够高效编程

1、打断开发者：对于开发者而言，开发过程中被打断是很糟糕的事情。因为开发是逻辑性很强的事情，一般开发人员完全进入开发的思维模式往往都需要至少半个小时，一旦被打断，就需要重新调整状态进入开发状态。开发者在开发的过程中被打断的越多，那么工作质量就会越差，可能出现的bug也就会越多，等等。

2、上班中途的会议：跟上边的打断一样，虽然会议是有计划的，而且这个比打断还要严重。一般会议时间都是1到2个小时，如果开发者知道需要在工作途中开会，那么他们需要在开会前一段时间就无法正常工作了，他们要先对之前的工作做个小的完结，还要做会议的准备。而会议结束之后，他们又有可能需要对会议做总结，做一些会后工作。即使跟他们关系不大，也仍然需要一定时间去重新进入状态，继续原来的开发工作。这样算下来，这个半天基本就算废了。建议会议可以在刚上班或者快下班的时候进行，避免打断开发者。

3、含糊其词，表述不清：如一般的开发过程中遇到的bug报告中“无法正常运行，请修复！”，但是敛财醣沁并没有提供足够的信息给开发人员参考。亦或者在需求文档中某些表述不清，细节描述不到位，以换纪藿钒至于开发人员要按照自己的直觉去实现。找他们理论，他们也会说“脑子是个好东西，自己想想嘛”，但毕竟每个人的经历不同，想法也不同，必须是需要有所规范的。如此，肯定就会出现开发实现与需求人员想要的不一致的情况出现，那么返工就不可避免了。

4、将别人的功劳据为己有：技术开发人员非常重视自己的能力被认可的，但是往往会有些管理者会将别人辛辛苦苦努力了好几周的劳动成果据为己有。这种现象对技术开发人员的打击是很大的，会在很长一段时间内影响开发者的生产力。

5、环境噪音：工作环境对技术开发人员的工作有非常重要的影响，如果办公室有过多的动静，那么将会导致开发人员无法集中注意力。

6、需求延伸：大多数开发者在开发过程中都会遇到这种情况，如在项目开发初期的功能是“定位的地图”，然后几乎快完成时，需求改为了需要显示定位的3d地图，然后等新的功能块完成的时候，这个功能又进行的新的调整。。。等等等等，这将会使本来相对简单的需求变的及其复杂而且耗时厉害。

7、产品定义的流程：如果产品团队在定义团队的优先级时，没有通过客户反馈或者其他方式来验证客户对相关功能的反应，而且开发人员发现好多功能最后并没有被使用，那么他们会觉的自己所做的工作毫无意义。这就会使开发人员失去动力。

8、缺乏对“技术债务”的考虑：何为技术债务，就是前期为了快速的发布项目，所以采用非最佳解决方案或非最佳编码来进行快速迭代。虽然这种方式可以在短期内提高项目的开发进度，但是，从长远来看，它会导致系统变的复杂，从而降低开发人员后期的开发效率。如果永远不优先考虑重构的话，那么不仅会影响生产力，还会影响到产品的质量。

9、注释要恰到好处：对于开发人员来说，注释是必不可少的。不但是团队协作开发需要，就是自己单独开发的时候也需要留给以后自己看。合理的注释有利于快速的梳理代码结构，快速定位问题。但这并不是说注释越多越好，再多的注释，如果不能很好的对代码进行说明，那不如不写。

10、硬件设备：从长远来看，对于开发人员，提供开发人员团队喜欢的工具和硬件设备能提高的生产力远远大于对设备成本的增加。有不少公司为了省事直接配台笔记本电脑，虽然笔记本电脑携带方便，但毕竟屏幕优先，对于技术开发人员来说，还是影响开发效率的，尤其是前端开发，他们要看设计稿，要预览前端界面，要编码，同时还得去查资料，一个屏幕切来切去，着实不方便。

11、太紧的工期：记得之前待过的一个公司周五出了一个需求，开了个评审会，然后就说下周五上线，结果各种加班，各种赶进度，最后还是做了两个礼拜才上线。这种是公司层面直接定工期，另一种比坂叹蝠咪较常见的就是管理者要求开发者提供预估工时，然后会鼓动开发人员尽可能的将工期压低，然后神奇的将这些降到最低的预估当成最后的截止日期！甚至有不少管理者还会认为，这个工期是开发者“自己决定”的预估，是开发者必须准守的开发工期。结果就导致开发人员过于紧张而无法集中注意力，以至于工作效率大大降低