编程低效率联盟入会指南……

全文共1924字，预计学习时长6分钟

图源：unsplash

编程拖延症协会宣：

正所谓DDL是第一生产力，对于编程来说也不例外。来吧！熬最晚的夜，用最贵的生发水，顶着最重的黑眼圈，敲最厉害的代码。如何降低编程效率，具体做法请参考入会指南。下面这六个习惯，每拥有一个，你就离入会近一点。一起拖延吧~

（清醒点呀，退会要趁早！）

一、出席会议

当你什么都不想做的时候，会议就变得必不可少了。——约翰·肯尼思·加尔布

会议可能是生产力的第一杀手，大多数开发人员仍然在过多地参加会议，可以分为两种类型。

图源：unsplash

第一类会直接跳过每次会议，而花时间在敲键盘上。这些开发人员认为大多数会议都是浪费时间，不如做些实际工作。第二类正好相反，他们会抓住每一个机会参加每一个预定的会议。

第二类开发人员会浪费很多时间，他们本可以将时间花在写代码和提高效率上的。

几乎所有会议都存在这样的问题，半个小时能说完的事儿能拖到一个小时或者更长。开发人员其实可以拒绝出席很多会议，或者至少拒绝出席中午之前的会议，这样就能提高上午的工作效率。如果真的要出席，至少要拒绝时间过长的会议。

二、编写自己的数据结构

编写自己的数据结构其实就是浪费时间做无用功，这是一个极其低效的习惯。所有需要的数据结构都已经存在，随时可以使用，通常情况下你不需要重新建构特定的数据结构。

这并不是做无用功的唯一例子，他们还经常重新编写某些代码片段。

如果同一段代码已经存在，并且已知是稳定的、维护良好的，那么直接使用就可以。自己编写代码并不会有什么新花样，甚至还会缺少一些功能，变得更糟。它唯一可能引入的新东西就是bug或者一些限制。

图源：unsplash

不过做这些无用功也有好处，如果开发人员想对某些东西有更深入的了解，那么这样做是完全可以的。但大多数情况下，这种行为还是应该避免，因为它会浪费太多时间。有时付出时间成本是合理的，但有时却是纯粹的浪费。

还有一些时候，任务非常关键，犯错可能会产生可怕的后果——那么做无用功就不是最佳选择了。

三、过度工程化

过度工程化是许多开发人员的坏习惯之一。在查看代码库时，开发人员常常会发现过度工程化的代码片段。

过度工程化通常会使产品设计太过稳健或复杂，开发人员有时会添加一些他认为将来可能有用的代码，其实并不必要。

这些代码可能永远不会被使用。大多数情况下，代码建构了很多实际不需要的东西，都是基于开发人员的猜测。也许过度工程化最好的解释是——代码正是在帮人们解决实际不存在的问题。

过度工程化会导致代码设计得过于通用，以至于忽略了最初设定好的需要执行的任务。因此，这样的代码不仅难以使用，而且从根本上来说并不明智。

四、没有计划

图源：unsplash

迅速开始着手一个编码项目可能会让人兴奋，但这种兴奋可能会浪费很多时间。如果开发人员直接开始着手编码，最终会失去对大局的掌控。

开始编码前，开发人员需要进行规划和组织。如何解决这个问题？实施什么结构？总体目标是什么？

在开始编码之前，这些都是很好的问题，可以让开发人员更清楚地意识到，其实在编写代码之前有很多事情要考虑。

如果没有计划，最后产出的功能可能与客户的要求有偏差，甚至导致采用错误的解决方式，这将会更糟。这就导致开发人员不得不重新检查代码，进行修改，而这样非常低效。

五、非一致性

一直坏，总好于偶尔好偶尔坏。

对于软件开发来说，一致性确实是关键。不一致的问题在于时间会破坏软件——这是不可避免的事实。一个软件存在的时间越长，使用的人越多，就会越来越混乱。

图源：unsplash

一致性对于代码库的可维护性很重要，尤其是长远看来，这是个好消息。如果开发人员决定将驼峰式大小写风格用于变量，那么就不要再变化。想用spaces代替tabs？可以！代码里怎么设置并不重要，重要的是保持一致性。

六、不寻求帮助

只有伸手的人才会得到帮助——J.K.罗琳

图源：unsplash

无论多么资深的开发者，都难免陷入困境。遇到这种情况时，保持一个简单的反馈循环系统是非常重要的。

寻求帮助并不意味着无能。而几个小时盯着屏幕，为了同样的问题苦苦挣扎，才会被认为无能。在寻求帮助之前，开发人员应该确保自己已经检查了所有能力范围内的事情。为了不必要的事情打扰其他开发人员并不可取。

通常情况下，其他的开发人员都会给出正确的方向，这样会节省很多时间，以便继续完成任务，而不是单凭自己的力量解决。

每天改变一点点，和低效率说再见，赶快行动起来吧！

推荐阅读专题

留言点赞发个朋友圈

我们一起分享AI学习与发展的干货

编译组：莫菲菲、杨月