全文共1924字，预计学习时长6分钟
图源：unsplash
编程拖延症商会宣：
正所谓DDL是第一生产力，对于编程来说也不例外。来吧！熬最晚的夜，用最贵的生发水，顶着最重的黑眼袋，敲最厉害的代码。怎么增加编程效率，具体做法请参考入会手册。下边这六个习惯，每拥有一个，你就离入会近一点。一起拖延吧~
（清醒点呀，退会要趁早！）
一、出席大会
当你哪些都不想做的时侯，大会就显得必不可少了。——约翰·肯尼思·加尔布
大会可能是生产力的第一杀手，大多数开发人员一直在过多地出席大会，可以分为两种类型。
图源：unsplash
第一类会直接跳过每次大会，而花时间在敲按键上。这种开发人员觉得大多数大会都是浪费时间，不如做些实际工作。第二类恰好相反，她们会捉住每一个机会出席每一个预定的大会。
第二类开发人员会浪费好多时间，她们本可以将时间花在写代码和提升效率上的。
几乎所有大会都存在这样的问题，半个小时能说完的事儿能拖到一个小时或则更长。开发人员似乎可以拒绝参加好多大会，或则起码拒绝参加傍晚之前的大会，这样能够提升早上的工作效率。假如真的要参加，起码要拒绝时间过长的例会。
二、编写自己的数据结构
编撰自己的数据结构似乎就是浪费时间做无用功，这是一个非常低效的习惯。所有须要的数据结构都早已存在，随时可以使用，一般情况下你不须要重新建构特定的数据结构。
这并不是做无用功的惟一事例，她们还常常重新编撰个别代码片断。
假如同一段代码早已存在可编程片上系统psoc设计指南，但是已知是稳定的、维护良好的，这么直接使用就可以。自己编撰代码并不会有哪些新花样，甚至就会缺乏一些功能，显得更糟。它惟一可能引入的新东西就是bug或则一些限制。
图源：unsplash
不过做那些无用功也有用处，假如开发人员想对个别东西有更深入的了解，这么这样做是完全可以的。但大多数情况下，这些行为还是应当避开，由于它会浪费太多时间。有时付出时间成本是合理的可编程片上系统psoc设计指南，但有时却是纯粹的浪费。
还有一些时侯，任务十分关键，错事可能会形成可怕的后果——那么做无用功就不是最佳选择了。
三、过度工程化
过度工程化是许多开发人员的坏习惯之一。在查看代码库时，开发人员往往会发觉过度工程化的代码片断。
过度工程化一般会使产品设计太过稳健或复杂，开发人员有时会添加一些他觉得将来可能有用的代码，当然并毋须要。
这种代码可能永远不会被使用。大多数情况下，代码建构了好多实际不须要的东西，都是基于开发人员的推测。似乎过度工程化最好的解释是——代码正是在帮人们解决实际不存在的问题。
过度工程化会造成代码设计得过分通用，以至于忽视了最初设定好的须要执行的任务。因而，这样的代码除了无法使用，但是从根本上来说并不明智。
四、没有计划
图源：unsplash
迅速开始着手一个编码项目可能会让人激动，但这些激动可能会浪费好多时间。假如开发人员直接开始着手编码，最终会丧失对大局的掌控。
开始编码前，开发人员须要进行规划和组织。怎么解决这个问题？施行哪些结构？总体目标是哪些？
在开始编码之前，这种都是挺好的问题，可以让开发人员更清楚地意识到，虽然在编撰代码之前有好多事情要考虑。
假如没有计划，最后产出的功能可能与顾客的要求有误差，甚至造成采用错误的解决方法，这将会更糟。这就造成开发人员不得不重新检测代码，进行更改，而这样特别低效。
五、非一致性
仍然坏，总好于时常好时常坏。
对于软件开发来说，一致性确实是关键。不一致的问题在于时间会破坏软件——这是不可防止的事实。一个软件存在的时间越长，使用的人越多，还会越来越混乱。
图源：unsplash
一致性对于代码库的可维护性很重要，尤其是长远看来，这是个好消息。假如开发人员决定将驼峰式大小写风格用于变量，这么就不要再变化。想用spaces取代tabs？可以！代码里如何设置并不重要，重要的是保持一致性。
六、不寻求帮助
只有伸手的人就会得到帮助——J.K.罗琳
图源：unsplash
无论多么资深的开发者，都难免深陷窘境。遇见这些情况时，保持一个简单的反馈循环系统是十分重要的。
寻求帮助并不意味着无能。而几个小时盯住屏幕，为了同样的问题苦苦挣扎，才能被觉得无能。在寻求帮助之前，开发人员应当确保自己早已检测了所有能力范围内的事情。为了毋须要的事情打搅其他开发人员并不可取。
一般情况下，其他的开发人员就会给出正确的方向，这样会节约好多时间，便于继续完成任务，而不是单凭自己的力量解决。
每晚改变一点点，和低效率说再会，赶紧行动上去吧！
