低效率开发人员的4种坏习惯

这是一篇翻译自Medium的文章，原文标题：4 Habits That Make You an Inefficient Developer，点击文末的阅读原文，可以跳转到英文原文。

我们都有不好的习惯，地球上没有一个人是完美的。

作为开发人员，不良习惯会严重影响您的效率，也会影响您周围的人。

Jack Canfield说：“习惯将决定您的未来”。想要成长为一名开发人员，就必须改掉不良习惯。如果您可以做到，效率将大大提高。

让我们看看您应该尽快改掉的坏习惯。

---

永远说“是”

首先声明一点，对所有事情都说是谦虚且无私的，这意味着您愿意（可能需要付出一些代价）帮助他人。

但是对所有事情说是是一个巨大的生产力杀手。最终，您还是得自己交付一些代码。

我并不是说您不应该帮助其他开发人员，只是说这不应该损害您的生产力。一些开发人员往往会提出很多问题-每件小事都来到您的办公桌前寻求帮助。

Paulo Coelho这样说道：

当您对他人说是时，请确保您没有对自己说不。

如果您发现自己很难拒绝他人，则仅在特定时间让别人来到您的办公桌前，这可能会对您有所帮助-给自己一些专注时间，让您可以完成一些工作。

这也迫使其他人在盲目地走向您的办公桌之前，开始自己寻找解决方案。如果他们真的无法提出解决方案，则可以将问题写下来。最终，它们会在您的办公桌旁显示问题列表。这样可以节省大量时间，因为您只会被打扰一次，而不会被列表中的每个问题一一打扰。

您字典里的“完成”一词可能不是真的“完成”

对于开发人员和其他人，对完成一词的理解不同的原因，可能是他们还有10,000件事要做。例如，在敏捷团队中工作时，开发人员希望完成冲刺。这有严格的时间限制，开发人员觉得他们没有时间浪费。

尽管完成一词的定义有所不同，但它可能不仅仅包括为一个很棒的功能编写一段代码。每当您认为自己已完成时，至少应考虑以下几点。

您重构了代码吗？而且，如果对代码审视时，您是否认为其他开发人员也理解它？如果以上问题之一的答案为否，请修复它！

那文档呢？此功能是否需要？您是否让测试人员知道如何测试功能？测试人员是否需要了解任何先决条件？

告诉测试人员应该如何测试功能，可以为你们两个人节省大量时间。

您知道吗？据加州大学研究数字干扰技术的Gloria Mark所说，打扰后平均需要23分钟才能恢复到原来的工作状态。

最后但并非最不重要的一点：您是否测试过您的作品？通过测试，我不仅指理想的路径场景。说到测试，接下来我们谈谈下一个坏习惯。

不测试您自己的代码

成为开发人员最喜欢的绝对不是测试。对于测试自己的代码，大多数开发人员甚至有些懒惰。按理想路径走一遍可能就是大多数开发人员所能提供的。

这个坏习惯将导致花费更多的时间来提供正确的功能。如果您不测试代码，那么测试人员可能会在一分钟内发现一个错误，如果您测试过代码，则很容易避免这种简单错误。

当测试人员报告错误时，您必须再次阅读代码。此外，修复错误后，测试人员需要再次测试功能。这不是很节省时间。

但是测试会增加开发时间。

不，不是。这是一个普遍的误解。当您刚开始学习如何正确测试时，测试只会增加最初的开发时间。您应该坚持并使其成为开发过程的一部分，成为一种好习惯。测试将为您节省很多时间和将来的麻烦。

一次提交太多

一种非常低效的习惯是提交太大。较大的提交导致只见树木不见森林。由于一次提交中有很多修改，因此看不清楚实际做了哪些修改。

除此之外，当您必须查看具有超过一百个已更改文件的提交时，您会有什么感觉？您可能会骂人。您可能会没有动力去彻底检查提交。

小提交是您的朋友，开发人员可以提供描述性的提交消息。抱歉，已解决一些问题并不是描述性的提交信息。

使用少量提交，代码审查变得更容易。它们使您可以一次查看一个更改，从而使代码审核人员有机会了解开发人员的思维过程。

进行小的提交也使调试变得更容易。回滚到某个提交以测试那里是否还存在错误很容易。一旦发现错误所在，一旦提交量很小，就不会有很多代码可以引入该错误。

这将使您效率更高，而无需付出很多努力。