作者：程序员小跃
Slogan：当你的才华还无法撑起你的野心时，那应该静下心来好好学习
上次的翻译，引起了很大的反响，大家都想知道自己和高级工程师的差距，看了我的文章，是不是都在默默地做着比较呢？如果你还没看，请赶紧移步过去看看吧。《知道吗，你和高级工程师差距巨大》
紧接着就是各种效应来了。有人问我，如何成为高级工程师；有人问我如何入门成为工程师；有人问我，如果做好规划，让自己做的更好！emm，有部分我已经在《答知友困惑：Java零基础如何入门，不知道怎么学，迷茫ING》做了解答，还有部分，我想通过今天的这篇文章来补充下。
其实我们在职场中，多多少少都会遇到很多问题，比如在某公司年会，就有员工吐槽过，怎么一天到晚都要开会，写PPT，大家都成为PPT专家却丢失了技术；有的同学会未雨绸缪，在项目里过度使用一些模式，试图让项目更好（其实是画蛇添足）；有的呢，有现成的框架不去使用和研究，非要自己写一套，其实有时候站在巨人的肩膀上，也是一种进步......
那我们今天就来好好聊聊有哪些可恶的习惯无形之中拉低了我们的效率，把我们坑惨了吧。
注意这些，以便你可以更好地改变自己
作者：Daan
时间：2020.3.23
我们都会有好习惯和坏习惯，编程习惯也不例外。但是一旦你开始意识到自己的不良习惯，你就可以改变，并让自己更好。如果你要打破此列表中的这些不良习惯之一，它不仅仅能影响你，甚至可能还会影响你身边的人。
而且由于坏习惯现在比将来更容易消除，因此我们将在此清单中列出六个您的工作效率降低的编程习惯。
会议--它可能是生产力第一大杀手。然后，还有大部分开发人员参加太多的会议。谈到会议，有两种类型的开发人员。
第一组将跳过每次会议，花时间在写代码上。这个小组认为大多数会议都是浪费时间，最好做些实际工作。
第二组正好相反。这个小组抓住每一个机会参加每一个预定的会议。
如果你发现自己属于第二组的情况，那是在浪费很多时间，也花了很多时间来编写代码和提高生产力。
会议的问题是，大多数会议默认安排在一小时内，即使议程可以在不到半小时内处理。会议的问题是我们可以对很多会议说不。或者在中午之前开始对会议说不，这样你就能在早上有效率。如果你真的要对会议说“是”，至少要对长时间的会议说“不”。
当你什么都不想做时，开会是必不可少的-- John Kenneth Galbraith
过度设计是许多开发人员往往具有的不良习惯之一。当你查看代码库的时候，你会经常发现过度设计的代码段。
过度工程的基本结果是，你使产品的设计比必要的更加健壮或复杂。在代码库中引入工程的一种方法是，开发人员已经在添加他认为将来可能有用的代码。
这部分额外的代码已添加到代码库中，但可能永远都不会使用。在大多数情况下，建造更多的东西超出了实际需要的原因是基于推测。解释过度工程的最好方法可能是代码解决了不存在的问题。
过度工程会导致代码被设计成非常通用，以至于忽略了最初设计用来执行的主要任务。因此，它不仅很难使用，而且从根本上说是不明智的。
编写自己的数据结构属于重新造轮子的范畴。这是一个养成极其低效的习惯。你需要的所有数据结构都已经准备好了。大多数情况下，不需要重新创建特定的数据结构。
数据结构并不是开发人员试图重塑轮子的唯一例子。开发人员常常倾向于重新创建某些代码。
如果相同的代码段已经存在并且已知稳定且维护良好只要走那条路线。你的版本没有添加任何新内容，甚至更糟的是缺少它的特征。它唯一可能引入的东西是bug或约束。
重造轮子也有积极的一面。如果你想对某事有更深的了解，重新发明轮子是非常好的。但是大多数时候，这是不鼓励的，因为他需要太多的时间。有时时间成本是合理的，有时是没有办法证明的。在其他情况下，任务是如此关键，以至于弄错它可能会带来可怕的后果-这使得重新发明轮子不是您的最佳选择。
如果你想改掉这个无效的习惯，最好不要把轮子再发明成默认的。
在软件开发中，一致性确实是关键。不一致的问题来自于不可避免的事实，即时间会破坏软件。一个软件存在的时间越长，使用它的人越多，就会出现更多的混乱。
一贯的坏事总比不好的好事好。
很高兴知道一致性对代码库的可维护性有很大的影响，特别是从长远来看。如果您决定使用驼峰命名变量，请坚持使用它。想用空格代替制表符吗？也很棒！在代码中做什么并不重要，至少要始终如一地做。
一开始，匆忙进入一个编码项目可能会让人兴奋。然而，那种兴奋可能会让你失去很多时间。如果你直接跳到编码部分，你最终会看不到大局。
在开始之前，需要先计划和组织代码。你怎么能解决这个问题？你将实施什么架构？你的总体目标是什么？
在开始编码之前，这些都是很好的问题。这些问题可以使你更加意识到以下事实：编写代码之前，有很多事情要考虑。
当你没有计划的时候，你会得到一些不完全是客户要求的功能。或者更糟：你的解决方案不对。这就导致你不得不在以后回到这段代码并修复它-这是低效的。
每一个开发人员，无论经验如何，都会时不时地陷入困境。当你遇到这种情况时，保持一个简短的反馈循环是很重要的。
寻求帮助并不意味着你不称职。如果你盯着屏幕几个小时都在为同样的问题而挣扎，领导会认为你不称职。
在你寻求帮助之前，确保你已经检查了所有你知道的事情。不必要地干扰其他开发人员，这并不是你想要做的。
通常情况下，其他一些开发人员都会向正确的方向推动。这样你就节省了很多时间，因为你可以重新开始做你的任务，而不是一个人去解决它。
帮助只提供给需要帮助的人 -- J.K.Rowling
“喂，你是不是又在给自己列清单对号入座了呀！”说你呢，屏幕前的你，哈哈。看完这篇文章的时候，其实我就是默默地在列清单，感觉很多都在对号入座的样子么。
我总结了下我感受最深的几个，如下：
无休止的开会，尤其是在需求分析的时候，反复的开会，其实做好了充分的准备，可以减少频率，一次性就能搞定
很多同学一拿到需求就开始火急火燎地动手写代码。跃哥在上一篇文章中也提到了过，写代码是最后要做的事情，写之前你需要做好充分的准备，比如流程分析，需求分析，数据结构分析规划等等，准备弄好了，你还怕代码写的不好吗
不寻求帮助。这其实是大忌，我在某厂工作的时候，就经常抛出困难给我们的架构师。我老大也经常强调，不要在一个问题上死磕，我们是在做商业的产品，不是练习，讲究的是效率，你的停滞就是对效率的拖拉，对项目的不负责。
所以现在知道为什么你一周的工作会浑浑噩噩地过去了，很多时候，你可以做的更好。如果你抓住了机会提升效率，那你在工作上会更得心应手。
在这个KPI横行的时代，尤其是困难的时期，要让领导对你有更好的印象，效率肯定是靠前的，所以，你还在犹豫什么，把这个收藏吃灰，偶尔拿出来吹一吹灰，才是你要做的事。
加油加油加油，跃哥一直都在，和你一起奔跑。
原文地址：https://www.cnblogs.com/dimple91/p/12744451.html
