关于开发效率的一些思考

我们一直在说要提高开发效率，那么什么才是效率呢？以下是我的一些思考，和大家一起共勉：

思考1

加班：是否在叠加无用的功能？如果是只能说明管理者或者产品已经没有好的点子了，只能把加班当成最有力的竞争力。当然为了有价值的功能那么加班也是有意义的。

效率：不是干的活越多说明效率越高，而应该是做的功是否有价值，如果做了10个功能但是没有一个有价值，那也不能算效率高，也比不过做了一个有价值的功能。所以效率=有用功/总功。那么接下来就是做完这个有效功能所化的时间了，在保证质量的前提下谁做的快那么他的效率就高。

思考2

需要分析哪些因素影响了你的开发效率？是使用的工具？对框架不熟悉？存在了等待？对模块不熟悉？代码质量不过关？设计的过度复杂？设计不够充分？等等，根据你的实际情况进行分析，在对这些问题一一解决。

开发团队提高效率：

1. 解决开发过程中的“锁”：项目中存在多个语言，那么程序员需要去学习，如果需要负责多个模块，那么程序员需要都去了解。
2. 很多公司的测试、运维都是开发的“保姆”，从而导致程序质量不高，经常返工。解决：1、需要招懂需求，注重程序质量，软件维护的程序员；2、不要找人来管理程序员，而应该是程序员自己管好自己；3、组织中不要有支持性工作的人；
3. 通过新的系统来监控老的系统，这种做法只会让你的系统越来越难以维护。要提前做好设计，可以多考虑几个方案，可以简化的尽量简化，不要过度设计，优化，不停的优化，就是CEO来也要优化。
4. 要拒绝业务方说我们先上线，有问题后面在改，再重构，我们要保持高标准，对系统有敬畏之心，要使用成熟的方案来设计。
5. 不合理的分支管理。
6. 会议太多影响开发。
7. 员工能力不够不断的加人。
8. 对于跨团队的合作，如果条件允许可以坐在一起，如果不行，那么尽量做到并行开发，先把自己的功能做好，在等外部团队接口好了之后进行联调。

思考3

多留点时间进行设计，这样可以提高效率，减少代码重构，从长远来看可以让你少写代码。当然不能纸上谈兵，或者过度设计，这样反而得不偿失。

思考4

1. 重构的业务模型必须特别清楚
2. 重构的代码结构也必须清楚
3. 重构一段代码之前要写好其单元测试（重点）