Photo by James Pond on Unsplash
我们都有好坏习惯。 编程习惯也不例外。 但是,一旦您开始意识到自己的不良习惯,就可以使自己变得更好。 如果您要打破此列表中的这些不良习惯之一,您不仅会影响自己。 最有可能还会影响您周围的人。
而且,由于今天比明天更容易摆脱不良习惯,因此我们将介绍这六种编程习惯,这些习惯会使您效率下降。
会议-它们可能是第一大生产力杀手。 但是,大多数开发人员仍然参加太多的会议。 会议涉及两种类型的开发人员。
第一组将跳过每次会议,以花时间在他们的键盘后面。 该小组认为大多数会议都是浪费时间,最好做一些实际的工作。
第二组则相反。 该小组抓住一切机会参加预定的每个会议。
如果您发现自己属于第二类,那是在浪费很多时间,这些时间本来可以花在编写代码和提高生产力上。
会议的事情是,即使可以在不到半小时的时间内处理议程,大多数会议默认都安排为一个小时。 会议的意义是我们可以拒绝很多会议。 或者,也许在中午之前开始对会议拒绝发言,这样您便可以在早晨提高工作效率。 而且,如果您真的必须对会议说"是",那么至少要对长时间的会议说"不"。
当您不想做任何事情时,会议都是必不可少的-John Kenneth Galbraith
过度设计是许多开发人员往往具有的不良习惯之一。 查看代码库时,您经常会发现过度设计的代码段。
过度设计的根本原因在于,您会使产品的设计变得比所需的更坚固或更复杂。 将过度工程引入代码库的一种方法是,开发人员已经添加了他认为将来可能会有用的代码。
这段额外的代码已添加到代码库中,但可能永远不会使用。 在大多数情况下,构建比实际需要更多的东西的原因是基于推测。 解释过度工程的最好方法也许是,代码可以解决不存在的问题。
过度设计可能会导致代码被设计得过于通用,以致于忽视了最初设计要执行的主要任务。 因此,它不仅变得难以使用,而且从根本上变得不智能。
编写自己的数据结构属于重新发明轮子的范畴。 养成一个极其低效的习惯。 您需要的所有数据结构已经准备就绪,可以使用了。 在大多数情况下,无需重新创建特定的数据结构。
而且,数据结构并不是开发人员试图彻底改变局面的唯一示例。 开发人员常常倾向于重新创建某些代码。
如果相同的代码段已经存在并且已知是稳定且维护得很好的,那就选择该路线。 您的版本没有添加任何新内容,甚至更糟的是缺少功能。 它可能引入的唯一新事物是错误或约束。
重塑车轮也有积极的一面。 如果您想对某些事物有更深入的了解,最好重新发明轮子。 但是大多数情况下不建议这样做,因为这会花费太多时间。 有时可以证明时间成本是合理的,而有时则无法证明它是合理的。 在其他情况下,这项任务非常关键,以至于弄错它会带来可怕的后果-这使得重新发明轮子不是您的最佳选择。
如果您想改掉这种无效的习惯,最好不要重新设计轮子作为默认设置。
在软件开发中,一致性确实是关键。 不一致的问题来自时间毁灭软件的不可避免的事实。 一个软件存在的时间越长,使用该软件的人越多,混乱就越多。
始终如一的好于始终如一的好
很高兴知道一致性对代码库的可维护性有很大影响,尤其是从长期来看。 如果您决定对变量使用驼峰式大小写,请坚持使用。 是否要使用空格而不是制表符? 大! 不管您在代码中做什么,至少要始终如一。
一开始,进入编码项目可能看起来很令人兴奋。 但是,这种兴奋可能会浪费您很多时间。 如果您直接进入编码部分,最终将看不到大局。
在开始之前,需要先计划和组织代码。 您如何解决这个特定问题? 您将实现什么结构? 您实施的总体目标是什么?
在开始编码之前,这些都是很好的问题。 这些问题可以使您更加意识到以下事实:编写代码之前,有很多事情要考虑。
当您无法规划时,您将获得某些并非客户要求的功能。 甚至更糟:您的解决方案不正确。 这导致您稍后必须返回该代码段并进行修复-这效率低下。
每个开发人员,无论经验如何,都将不时卡住。 在这种情况下,保持简短的反馈循环很重要。
寻求帮助并不意味着您没有能力。 如果您盯着屏幕挣扎数小时而又遇到同样的问题,人们会认为您不称职。
在寻求帮助之前,请确保已经检查了所有已知的事项。 不必要地干扰其他开发人员不是您想要完成的任务。
通常,其他一些开发人员可以为您提供正确方向的推动。 这样,您可以节省大量时间,因为您可以重新开始处理任务,而不必自己搞定。
帮助只提供给需要帮助的人-J.K. 罗琳
(本文翻译自Daan的文章《6 Programming Habits That Make You an Ineffective Programmer》,参考:https://levelup.gitconnected.com/6-programming-habits-that-make-you-an-ineffective-programmer-aa4aac64fc4e)