怎样提高开发效率（2018）

开发效率可以从个人开发效率和团队开发效率来谈，抛开自由职业者，但凡在一个公司上班的程序员都必然是在一个团队中工作，所以每个人的个人效率最终都会转化为团队的效率。转化率有多大，取决于团队的凝聚力，每个人的劲是不是在往一处使。

团队效率最重要的是沟通，我经常会碰到这样的情况：

1、每个任务有详细说明文档的，开发人员按部就班的照着文档进行开发，但根本不清楚自己做的东西是做什么的，文档有遗漏或有错误，做出的功能也会有遗漏和错误，这中间开发人员缺乏思考，会造成反复；
2、任务没有详细说明文档的，通过讲解的方式来布置任务，在讲解时每个人都明白了意思，但最终的产出却事与愿违，经常需要返工，效率低下。

我现在的做法：

1、产品的整体思路，想要解决什么问题会集体开会进行讲解，是让每个人都清楚做事的目的；
2、任务分解后会记录在GitLab的Issues中，只填写任务的标题，任务的描述由开发人员来填写；
3、根据开发人员填写的任务描述（需求分析的一个过程），可以知道对功能的理解程度，然后再有针对性的进行沟通。

下面主要介绍下提升个人效率相关的方法

工具

俗话说，工欲善其事必先利其器，使用得心应手的工具必然会提高开发效率，做微软平台开发的肯定离不开VS，就VS本身来说，除了常用功能外一些常用的快捷键一定要能熟练运用，例如下面是我认为比较有用的几个快捷键：

注释： Ctrl + K + C
取消注释： Ctrl + K + U
全屏： Shift + Alt + Ente
设置标签： CTRL + K, CTRL + K
下一个、上一个标签： CTRL + K, CTRL + P 、CTRL + K, CTRL + P
列出成员： Ctrl + J
显示参数信息： Ctrl + Shift + Space
转到定义后返回： Ctrl + –

熟练使用快捷键对于代码编写的速率和跟踪代码的速率会有大大的提高。

现在团队采用前后端分离的开发方式，VS Code也是必不可少的开发工具之一，在VS Code中装上适合你的插件，也会使你事半功倍。

目前在工作中Mac和Windows并行使用，善用工具真的可以节省大量的时间，后面单独开篇来写下我在日常工作中常用的一些工具。

代码质量

代码质量好了，产生的bug就少，和测试的交互也就少了，也就不会因为前面产生的bug而影响后面的进度，效率自然就高了。代码质量可以从两个方面来看：

初级阶段—满足客户需求

代码能够正常运行起来，满足客户的需求，这可以说是一个底限要求了。但即便是这种要求，做起来都不是很容易，常常会面临这样一些问题：

1、改一个问题会引发一连串的其他的问题；
2、程序在少数据量的情况下没什么问题，当数据量增大性能急剧下降；
3、特定情况下出现一些低级问题，比如C#的经典报错：为将对象引用到对象的实例。

解决方法：

1、形成功能的闭环，这是我一直在团队中强调的，意思就是不能只局限在所做的功能点，要按照真实业务的场景去考虑所有关联的影响点。这也是在开发人员自测时一个很重要的依据；
2、高性能的开发得从点滴做起，不放过每一个细节，可能一个小的细节点就是一个性能的瓶颈；
3、勤思考，对犯过的错要经常总结，团队成员互相分享，共同成长提高；
4、多学习一些原理性的知识，知其然还要知其所以然，基础扎实了，一些性能的问题就知道怎么去优化了。

高级阶段—可扩展、可维护

我一直认同一句话：好的代码是重构出来的，这句话的重点是重构，这是一个持续的过程，当我们嗅到代码中有坏味道的时候就需要停下来思考下。我的理解是代码不要过早优化和过度设计，但当需要去做优化和重构时也不能犹豫。

我们经常说：这个代码可以先这样写（应付一时的紧急需求），后面在优化吧，这样的技术债随着工期的临近，人员的变动等各种压力就会越累越多。可以翻翻你们的项目的产品的代码，看看有多少「TODO」还一直沉睡在那里。

这些技术债，可能让你一时满足了要求，但从长远来看却要花费更多的时间和精力去偿还，情况严重的还可能导致项目失败。

解决方法：

1、代码有坏味道需要停下来思考；
2、团队中需要形成Code Review的氛围，最终要形成每个人的自觉意识，开始阶段可以由技术负责人来主导；
3、及时偿还技术债。

业务知识学习

做任何的系统都避免不了有业务背景，熟练的了解业务知识可以使我们更清楚的知道我们是在做什么。很多的开发人员可能只喜欢钻研技术，对业务往往没什么兴趣，代码写完了，可能还不知道做出的模块时做什么用的，这样写出来的代码的质量就可想而知了。

记得工作的第一年，安排做一个特别复杂的表单界面，需求文档写的很清楚，每个按钮，每个文本框都按照要求完成了功能，但由于对业务的不清楚，导致很多地方考虑不足，造成反复修改。

遇到的问题：

1、功能做完发现不是客户想要的；
2、认识上的偏差造成对同样的语言描述会有理解上的偏差；
3、每个人不清楚所做功能的目的，会让团队没有凝聚力，每个人都很盲目。

解决方法：

1、不管是否有详细的功能需求说明书，技术管理者（需求分析）和开发人员之间需要达成最终的对需求理解上的一致，就像TCP的三次握手；
2、对于业务把我不清楚的，可以先出图或事Demo再进一步沟通；
3、当理解不清晰时，开发人员不能想当然的按照自己的思路去弥补这个不清晰，参考第一条，最终达成理解上的一致，再接着往下做；
4、必要的时候可以引导客户，我们的主要目的能以最有效的方式帮客户解决问题，不能盲目的按照客户的要求来，有时客户说需要一双雨鞋，可能一把伞就可以解决问题。同样对于技术管理者提出的需求，开发人员也需要有质疑的精神，集思广益，可能会碰撞出更多的火花，但要避免钻牛角尖。

本文采用署名-非商业性使用-相同方式共享 4.0 国际许可协议，转载请注明出处。