效率翻倍！给开发人员的几点建议

本文转载自公众号“读芯术”(ID：AI_Discovery)。效率

成为一名开发人员是翻倍发人很难，想要成为一名高效的员的议开发人员，更是点建难上加难。你必须得忍受诸多冗长的效率会议(它们会消耗你本可以用来编写代码的时间)，忍受花费大量时间做决定的翻倍发人管理模式，以及模糊不清的员的议验收标准……这些都是在浪费时间，然而我们几乎没有意识到其中最浪费时间的点建居然是自身习惯。

这些习惯可以实现时间浪费最小化，效率工作产出最大化。翻倍发人

每天为自己设定一个具体明了的员的议目标

我经常发现自己一到中午就变懒散。我本该一分钟写很多行代码，点建但过了一会儿，效率却发现自己在看摩托车评论。翻倍发人有一次，员的议我必须在一天内修复一个严重故障，因为它影响到了大量的用户。那一天，源码下载我比以往任何时候工作效率都要高，原因很简单：我有了一个具体明了的目标。

我现在知道，当我应该却没开始创建解决方案时，很可能是由于我不知道自己的目标是什么。当我有了一个可以用一两行字写下来的目标时，我的效率就提高了。

这样做之所以有用，原因之一是蔡格尼克效应，该效应认为人类是“寻求解脱的动物”。换句话说，我们讨厌开始一件事，也讨厌没有完成这件事。当你明确了标准，你就会确切知道下一步是什么。

例如，当我准备创建一个新特征时，我会写下一行简单的目标：

没有时间节点，b2b供应网就没有完成的动力，也就没有进步。

先创建一个MVP，然后把需要做的事情具体化

以前，我总想尽可能地编写出美观漂亮、运行流畅的代码。我每天要花上几个小时的时间在10行代码块上，仅仅因为它没有按照我喜欢的方式运行。这种工作方式带来的结果与我的初衷完全相反。这不仅让我的工作效率变低了，而且还让我的代码中掺杂着许多神秘难解的符号，代码没有解耦，变得更难测试。

我意识到，我所要做的就是交付一些可正常运行的产品——MVP(最简化可实行产品)。当然，你应该交付可正常运行的产品!但在工作中我可能忘了自己应该做一些有助于任务完成的事情。不多做亦不少做，亿华云恰到好处即可。

尤其是作为一名初级开发人员，我在使用一些惊艳同事们的新奇组件和库时，倍感压力。这不仅会让自己想太多，而且会影响你当前的任务，如果在这上面花的时间太多，甚至占用了自我提升的冲刺时间，可能还会影响到你未来的任务。

那么怎样才能知道什么时候应该停止工作呢?当一切都进展顺利的时候。

显然，这里需要满足一些标准：

尽可能在独立分支上工作

图源：unsplash

开发人员承担的任务越复杂，就越有可能引发致命性故障。在你把负责的工作合并到主分支进行全面测试时，这些致命性故障才可能显现出来。

当得到第一个重要开发任务时，我很是兴奋。任务要求重构一个特征以使用MVVM，并用Kotlin语言编写。然而，我自身经验不足，不知道怎样正确测试自己编写的代码，尽管代码还有很多错误，但是我还是把代码发送并合并到主码中。

几天后，团队测试人员非常生气，所以我后面连续两周都要修复大量的故障。我拖了团队的后腿，因为我太懒了，没能正确测试自己的代码，而且因为我所有的更改都被合并了，下一个版本的发布很可能要推迟。

然后我意识到，如果我使用独立特征分支，然后把它交给测试人员，就能为自己和团队节省大量的精力和时间。在全面测试新代码之前，尽可能将其保存在独立分支上。如此一来，你就能更快地修复故障，并从产品构建中分离出致命性故障。

永远不要接手含糊不清的任务

人们无论何时开始新的任务，都会受到惰性的影响。我们都有很多类似的经历。当准备起床时，我们的身体团作一团，没有任何反应。当想要学习新东西时，我们不参加课程。当想要给自己规定饮食时，又纠结于应该吃什么、多久吃一次等细节。

软件开发中，开始创建新特征时的惰性或阻力通常以多种方式呈现出来：必须浏览完冗长的SDK文档，理解了业务需求的确切内容，甚至试图找出所需的依赖项。

我不知道你是否也这样想，但作为一名开发人员，我想做的就是开发。我不想争当产品负责人，不想检查UI副本或元素，不想一遍遍地写验收标准，不想一直不停地询问后端团队关于API的问题……我只想做开发。

所以我只会接手满足下面这些条件的任务：

希望这些能让你的效率大大提升!

最新评论