|
|
# 25 | 有哪些方法可以提高开发效率？
|
|
|
|
|
|
你好，我是宝玉，今天我想与你讨论一个每个开发人员和项目管理者都关心的话题：如何提高开发效率。
|
|
|
|
|
|
我其实也一直很关注这个话题，收集了很多方法让自己工作变得卓有成效。通过对这些方法的应用，我也可以算得上是一个高效的程序员：曾一个人在很短时间完成了飞信Web版客户端；在DePaul上学之余，帮学校完成了在线教学播放器系统的改造；三个月时间帮公司完成了主站从jQuery到React的迁移。
|
|
|
|
|
|
如果让我对学过的这些方法做个整理和总结，再进一步精选提炼，我觉得对我影响最大的是“积极主动”、“以终为始”和“要事第一”这几条看似简单的工作原则。
|
|
|
|
|
|
## 积极主动，行动起来改变自己
|
|
|
|
|
|
相信你也和我有过相同的经历。成为一个高效程序员，最大的阻力不是来自于不知道方法，而是自己的消极心态。遇到进度延迟、效率低下之类的问题，你就会下意识觉得：
|
|
|
|
|
|
* 时间进度太紧了；
|
|
|
* 我已经尽力了；
|
|
|
* 最近加班太多了没精神；
|
|
|
* 产品经理太不靠谱了，需求没想清楚，害的我瞎忙活。
|
|
|
|
|
|
是的，你也知道这些答案都很消极负面，可是怎么控制自己不这么想呢？首先你要知道，无论这些事情的本质责任在于环境还是个人，抱怨排斥的心态对于实际工作的改进是没有任何帮助的。
|
|
|
|
|
|
当然，很多人也知道抱怨没用，但具体怎样才能做到不抱怨，并且积极主动呢？史蒂芬・柯维写在他的《高效能人士的七个习惯》书中，对这个问题提到了两个行之有效的建议，我们可以结合着软件开发来分析一下。
|
|
|
|
|
|
#### 想想再回应
|
|
|
|
|
|
我还记得第一次有人给我介绍单元测试很好用，能让你效率更高、代码质量更好时，我的第一反应是不可能，这样明明要多写很多代码，怎么可能会高效？
|
|
|
|
|
|
于是我有一段时间是很排斥的，直到后来参与一个已经有单元测试的项目，尤其是在重构代码的时候，我发现修改了大量代码后，程序还是很稳定，当时便觉得应了网友的那句话，“真香”！
|
|
|
|
|
|
每个人对于外界的刺激都会做出反应，本能的或者习惯性的，就像我前面举的例子，遇到事情会本能的觉得都是外部原因。如果一直这样，那就会进入恶性循环，变得更加消极麻木。
|
|
|
|
|
|
但如果在回应之前，给自己一点时间想想，站在积极的方面理性思考一下，就可以去控制你的本能反应。
|
|
|
|
|
|
所以很多次，就在我脱口而出“不可能”或者“不行”的时候，我提醒自己再想想。于是我会改口说：“我试试”、“我再想想”。这样很多次提醒自己以后，会一点点由“不可能”的本能变成“我想想”的习惯。
|
|
|
|
|
|
后来有人跟我说CI（持续集成）很好，我思考过了之后进行了尝试，在Github上建了一个项目，把CI搭起来试了一下，觉得真的是很好。如果我还是秉持着以前的消极心态，不知道又要晚多久才能去尝试。
|
|
|
|
|
|
#### 减少关注圈，扩大影响圈
|
|
|
|
|
|
我关注很多事情，比如编程语言、明星八卦、国家大事，这些都是“关注圈”。而这其中，要区分哪些事，是我可以影响和掌控的，这些事则是“影响圈”。
|
|
|
|
|
|
**不要总盯着自己无法改变的部分，你需要要多花时间精力在影响圈上。**
|
|
|
|
|
|
比如说，我不能改变996，至少我可以利用这时间多学习一点，找机会换一个更好的环境；我不能要求每个人都写单元测试，但是我自己的代码写了单元测试，这样项目质量更好了我也更有价值；我不能决定跟什么样的人一起共事，但是我愿意跟他们分享我的经验，他们成长了我也受益。
|
|
|
|
|
|
工作一段时间后，你也可以尝试去扩大自己的影响圈。
|
|
|
|
|
|
比如说，很多程序员像我一样，有过不少因为产品经理需求没想清楚导致返工的经历，后来我就格外关注产品设计相关的知识，业余时间自己学习了不少，这就相当于扩大了我的影响圈。
|
|
|
|
|
|
所以后来产品经理给我一个需求，我不需要在开发完成后才抱怨他不靠谱，而是在给我需求的时候就去跟他讨论，是不是有可能没想清楚。
|
|
|
|
|
|
当你不仅仅局限于程序员的角色思维，扩大了影响圈之后，你就可以试着向产品经理提出很多有价值的建议，比如：
|
|
|
|
|
|
* 这个布局在文字很长的情况下会有什么变化？
|
|
|
* 如果网络很慢，加载数据的时候应该显示什么？加载失败显示什么？
|
|
|
* 如果数据为空的时候这个列表应该显示什么？
|
|
|
|
|
|
其实“减少关注圈，扩大影响圈”这个道理也很简单：**接受不能改变的，改变能改变的，尽量扩大可改变项的范围。**
|
|
|
|
|
|
## 以终为始，想清楚再开工
|
|
|
|
|
|
如果对比一下我在十几年前作为一个新手程序员，和现在作为一个老手写代码有什么不同的话，我认为在新手阶段，我是拿到需求就开始写，写到一半发现好像不对，马上修改，好像还不太对，就这样反反复复，效率很低下。
|
|
|
|
|
|
而现在拿到一个需求，我会先仔细的分析需求文档，反复和产品经理确认各种细节，然后做个简单的设计，考虑清楚模块怎么设计，他们之间是什么关系，然后再写，写完还要加上测试代码。
|
|
|
|
|
|
你知道最大的区别是什么吗？我现在做一件事之前，会先想清楚“终”，然后才知道怎么“始”。所以我先搞清楚需求这个“终”，然后再设计规划出这个从“始”通向“终”的路线，最后从“始”出发写代码，一气呵成，不仅快，而且质量好。这就是“以终为始”。
|
|
|
|
|
|
要做到“以终为始”，就是在做事情的时候注意三点：**目标、原则和计划。**
|
|
|
|
|
|
#### 经常停下来想想目标
|
|
|
|
|
|
我刚毕业参加工作的时候，要开发一个内容管理系统，其中涉及有数据库访问，这就需要把数据表的字段和类对应起来，觉得太体力活了，于是我开始写数据库生成代码工具。而要想写代码生成工具，我还得学习Winform知识……就这样几个月过去了，关于这个系统的代码还是最开始的几行！
|
|
|
|
|
|
我的目标是写一个内容管理系统，结果却跑去写代码生成工具，这样怎么能做到高效呢？正确的做法应该是手动完成这几个类的生成，其实用不了几分钟，或者用一个现成的工具。如果觉得代码生成工具是个有意义的项目，应该另外立项，而不应该影响当前的项目。
|
|
|
|
|
|
这样的事情在我身上还发生过几次，所以我后来就逼着自己隔一段时间要停下来想想：我的原始目标是什么？我正在做的事是我的目标吗？如果不是，那么马上回到自己的原始目标去。
|
|
|
|
|
|
#### 制定原则
|
|
|
|
|
|
其实大部分很好的编程方法都是需要坚持做才有效果的，比如说自动化测试代码，有时候时间进度一紧，就会来不及写，时间一长，就会欠下技术债务。
|
|
|
|
|
|
所以我给自己定了一个原则：增加一个功能，就要写自动化测试，如果来不及写，就给自己写一条Ticket。
|
|
|
|
|
|
这条原则我坚持得很好，所以我的自动化测试代码得以坚持，从而真正帮助我做到高效开发。
|
|
|
|
|
|
你也可以给自己定一些原则，比如：
|
|
|
|
|
|
* “先运行再优化(Make it Work Make It Right Make It Fast)”——也就是在优化代码之前，先用简单的方法实现，再考虑怎么优化，这样可以保证设计的简单，也可以避免你陷入技术细节中而忽视了原始目标。
|
|
|
* “不复制粘贴代码(Don’t repeat yourself)”——复制粘贴会导致代码臃肿，不便于维护，提取抽象可以保持简洁。
|
|
|
* “每个Pull Request要尽可能小”——这有助于把复杂的任务分解成几个简单的任务，简单的任务更容易高效完成。
|
|
|
|
|
|
有原则了，你才能不忘初心，有始有终。
|
|
|
|
|
|
#### 公开自己的计划
|
|
|
|
|
|
那么有了原则就够了吗？显然不是，有了原则，你还要坚定不移地去执行。如何执行呢？做计划。
|
|
|
|
|
|
刚开始工作时，我是害怕做计划的，怕计划了完不成，问到我工作的时间安排时，我会给一个模凌两可的答复，这其实导致了我在实际开发时，缺少进度压力，从而迷失在细节中导致延误进度。
|
|
|
|
|
|
后来我尝试做出了一些改变，把任务细化，做个简单计划，主动给出一个明确的时间点。有了计划指引和时间点的压力，会倒逼着自己时刻专注于目标是什么，“终”在哪里，还有多少没有完成，这样下来工作效率自然而然就会高起来。
|
|
|
|
|
|
通过在做事时，围绕着目标、原则和计划这三个点，反复地刻意地练习，也可以让你慢慢养成“以终为始”的好习惯。
|
|
|
|
|
|
## 要事第一，把时间用在刀刃上
|
|
|
|
|
|
作为程序员，其实大部分时间并不能专注写程序，总有各种各样的事情打断我们，比如，一会产品经理找你过去开个会确认个需求；一会测试过来找你重现一个Bug；一会还有同事过来请教你一个问题；微信上老朋友找你叙叙旧；突然生产环境出故障了，需要马上去解决。
|
|
|
|
|
|
就这样一天下去，感觉一直在忙忙碌碌，其实并没有多少时间在写程序。这时候怎么办呢，对手头的事情进行优先级管理。
|
|
|
|
|
|
时间四象限也许你不陌生，就是把事情分成重要紧急、重要不紧急、紧急不重要、不紧急不重要四个象限，不同的事情有不同的应对策略。
|
|
|
|
|
|
* **重要紧急的事情马上处理**
|
|
|
|
|
|
比如说，生产环境出故障了，测试环境部署失败了，这些都是重要并且紧急的事情，只能是马上处理。
|
|
|
|
|
|
* **重要不紧急的要事，要花最多的时间在上面**
|
|
|
|
|
|
对代码重构、写自动化测试代码、确认清楚需求文档，这些事情都属于重要不紧急的事情，但是如果不及时处理，就有可能变成重要紧急的事情，比如不偿还技术债务，就可能会变成生产环境故障。
|
|
|
|
|
|
所以这部分事情我会多花时间，重点做。通常我会每段时间只专注做一两件重要的事，其他事情尽可能忽略，比如前一个阶段我主要的工作就是重构前端代码，这个阶段我就在忙排查性能隐患，至于其他事情，就先放一放。
|
|
|
|
|
|
* **紧急不重要的事凑一起集中做**
|
|
|
|
|
|
像微信的消息通知，无关紧要的会议，请教一个不算很急的技术问题，这些都是紧急不重要的问题，然而却会占用我们大量时间。如果时间都用在这些事情上面，必然会占用在重要事情上所需的时间。
|
|
|
|
|
|
所以我有些小技巧也许你可以参考。比如我在专注干活时，会全屏幕、关掉所有消息通知，保证没有消息干扰，忙完一段后再去集中处理。
|
|
|
|
|
|
还有如果有人找我时我正在忙，如果他的事情不是重要紧急的，我会礼貌地告诉他我正好手头有点事情，大约多少时间后我主动去找他。相应的我也会尊重别人的时间，找别人的时候会先问一下：“你什么时候有10分钟左右时间，我想请教你一个问题？”
|
|
|
|
|
|
* **不重要不紧急的事情能不做就不做**
|
|
|
|
|
|
不紧急不重要的事也很多，比如说我的Mac电脑突然提示我要更新系统了。我有点强迫症，以前系统一有要升级，我就迫不及待要升级到最新，结果一升级系统，半天就不能干活了。所以后来这种事情，就放在不重要的时间去做，比如周末、睡觉之前让它慢慢升级。
|
|
|
|
|
|
其实我在做开发的时候，觉得很多很杂的事情也不算太多，真正到后来转型做管理的时候，才真正体会到什么叫事情多而杂。但正是源于开发时期就形成的时间四象限方法的运用，让我可以在繁忙的时候，保证时间用在有价值的事情上。
|
|
|
|
|
|
要事第一，就是要保证你有限的时间用在最有价值的事情上。
|
|
|
|
|
|
## 总结
|
|
|
|
|
|
积极主动、 以终为始和要事第一，这三个原则以及其衍生出来的方法，正是帮助我逐步变成一个高效程序员的关键所在，希望也能对你有所帮助。
|
|
|
|
|
|
如果你已经学习了很多类似的原则或者方法，而觉得没什么效果，那也许只是因为没有尝试把它们变成习惯。你可以像我一样，把认同的好的原则或方法，通过反复的刻意练习，反复地提醒自己，训练成习惯，然后用习惯指导你的日常开发。
|
|
|
|
|
|
当然，这样的改变不会是一天两天就能完成，但也不用着急，因为习惯的养成需要时间的积累，才能变成条件反射。当你把好的原则或方法变成了直觉反应，自然就会成为一个高效的程序员。
|
|
|
|
|
|
## 课后思考
|
|
|
|
|
|
你知道的有哪些提升开发效率的方法？你身边那些高效程序员都是如何做到高效开发的？欢迎在留言区与我分享讨论。
|
|
|
|
|
|
感谢阅读，如果你觉得这篇文章对你有一些启发，也欢迎把它分享给你的朋友。
|
|
|
|