作者：程序員小躍
Slogan：當你的才華還無法撐起你的野心時，那應該靜下心來好好學習
上次的翻譯，引起了很大的反響，大家都想知道自己和高級工程師的差距，看了我的文章，是不是都在默默地做着比較呢？如果你還沒看，請趕緊移步過去看看吧。《知道嗎，你和高級工程師差距巨大》
緊接着就是各種效應來了。有人問我，如何成為高級工程師；有人問我如何入門成為工程師；有人問我，如果做好規划，讓自己做的更好！emm，有部分我已經在《答知友困惑：Java零基礎如何入門，不知道怎么學，迷茫ING》做了解答，還有部分，我想通過今天的這篇文章來補充下。
其實我們在職場中，多多少少都會遇到很多問題，比如在某公司年會，就有員工吐槽過，怎么一天到晚都要開會，寫PPT，大家都成為PPT專家卻丟失了技術；有的同學會未雨綢繆，在項目里過度使用一些模式，試圖讓項目更好（其實是畫蛇添足）；有的呢，有現成的框架不去使用和研究，非要自己寫一套，其實有時候站在巨人的肩膀上，也是一種進步......
那我們今天就來好好聊聊有哪些可惡的習慣無形之中拉低了我們的效率，把我們坑慘了吧。
6個編程習慣使你更低效
注意這些，以便你可以更好地改變自己
作者：Daan
時間：2020.3.23
我們都會有好習慣和壞習慣，編程習慣也不例外。但是一旦你開始意識到自己的不良習慣，你就可以改變，並讓自己更好。如果你要打破此列表中的這些不良習慣之一，它不僅僅能影響你，甚至可能還會影響你身邊的人。
而且由於壞習慣現在比將來更容易消除，因此我們將在此清單中列出六個您的工作效率降低的編程習慣。
1. 參加會議
會議--它可能是生產力第一大殺手。然后，還有大部分開發人員參加太多的會議。談到會議，有兩種類型的開發人員。
第一組將跳過每次會議，花時間在寫代碼上。這個小組認為大多數會議都是浪費時間，最好做些實際工作。
第二組正好相反。這個小組抓住每一個機會參加每一個預定的會議。
如果你發現自己屬於第二組的情況，那是在浪費很多時間，也花了很多時間來編寫代碼和提高生產力。
會議的問題是，大多數會議默認安排在一小時內，即使議程可以在不到半小時內處理。會議的問題是我們可以對很多會議說不。或者在中午之前開始對會議說不，這樣你就能在早上有效率。如果你真的要對會議說“是”，至少要對長時間的會議說“不”。
當你什么都不想做時，開會是必不可少的-- John Kenneth Galbraith
2. 過度工程
過度設計是許多開發人員往往具有的不良習慣之一。當你查看代碼庫的時候，你會經常發現過度設計的代碼段。
過度工程的基本結果是，你使產品的設計比必要的更加健壯或復雜。在代碼庫中引入工程的一種方法是，開發人員已經在添加他認為將來可能有用的代碼。
這部分額外的代碼已添加到代碼庫中，但可能永遠都不會使用。在大多數情況下，建造更多的東西超出了實際需要的原因是基於推測。解釋過度工程的最好方法可能是代碼解決了不存在的問題。
過度工程會導致代碼被設計成非常通用，以至於忽略了最初設計用來執行的主要任務。因此，它不僅很難使用，而且從根本上說是不明智的。
3. 編寫自己的數據結構
編寫自己的數據結構屬於重新造輪子的范疇。這是一個養成極其低效的習慣。你需要的所有數據結構都已經准備好了。大多數情況下，不需要重新創建特定的數據結構。
數據結構並不是開發人員試圖重塑輪子的唯一例子。開發人員常常傾向於重新創建某些代碼。
如果相同的代碼段已經存在並且已知穩定且維護良好只要走那條路線。你的版本沒有添加任何新內容，甚至更糟的是缺少它的特征。它唯一可能引入的東西是bug或約束。
重造輪子也有積極的一面。如果你想對某事有更深的了解，重新發明輪子是非常好的。但是大多數時候，這是不鼓勵的，因為他需要太多的時間。有時時間成本是合理的，有時是沒有辦法證明的。在其他情況下，任務是如此關鍵，以至於弄錯它可能會帶來可怕的后果-這使得重新發明輪子不是您的最佳選擇。
如果你想改掉這個無效的習慣，最好不要把輪子再發明成默認的。
4. 不一致
在軟件開發中，一致性確實是關鍵。不一致的問題來自於不可避免的事實，即時間會破壞軟件。一個軟件存在的時間越長，使用它的人越多，就會出現更多的混亂。
一貫的壞事總比不好的好事好。
很高興知道一致性對代碼庫的可維護性有很大的影響，特別是從長遠來看。如果您決定使用駝峰命名變量，請堅持使用它。想用空格代替制表符嗎？也很棒！在代碼中做什么並不重要，至少要始終如一地做。
5. 不計划
一開始，匆忙進入一個編碼項目可能會讓人興奮。然而，那種興奮可能會讓你失去很多時間。如果你直接跳到編碼部分，你最終會看不到大局。
在開始之前，需要先計划和組織代碼。你怎么能解決這個問題？你將實施什么架構？你的總體目標是什么？
在開始編碼之前，這些都是很好的問題。這些問題可以使你更加意識到以下事實：編寫代碼之前，有很多事情要考慮。
當你沒有計划的時候，你會得到一些不完全是客戶要求的功能。或者更糟：你的解決方案不對。這就導致你不得不在以后回到這段代碼並修復它-這是低效的。
6. 不尋求幫助
每一個開發人員，無論經驗如何，都會時不時地陷入困境。當你遇到這種情況時，保持一個簡短的反饋循環是很重要的。
尋求幫助並不意味着你不稱職。如果你盯着屏幕幾個小時都在為同樣的問題而掙扎，領導會認為你不稱職。
在你尋求幫助之前，確保你已經檢查了所有你知道的事情。不必要地干擾其他開發人員，這並不是你想要做的。
通常情況下，其他一些開發人員都會向正確的方向推動。這樣你就節省了很多時間，因為你可以重新開始做你的任務，而不是一個人去解決它。
幫助只提供給需要幫助的人 -- J.K.Rowling
結語
“喂，你是不是又在給自己列清單對號入座了呀！”說你呢，屏幕前的你，哈哈。看完這篇文章的時候，其實我就是默默地在列清單，感覺很多都在對號入座的樣子么。
我總結了下我感受最深的幾個，如下：
-
無休止的開會，尤其是在需求分析的時候，反復的開會，其實做好了充分的准備，可以減少頻率，一次性就能搞定
-
很多同學一拿到需求就開始火急火燎地動手寫代碼。躍哥在上一篇文章中也提到了過，寫代碼是最后要做的事情，寫之前你需要做好充分的准備，比如流程分析，需求分析，數據結構分析規划等等，准備弄好了，你還怕代碼寫的不好嗎
-
不尋求幫助。這其實是大忌，我在某廠工作的時候，就經常拋出困難給我們的架構師。我老大也經常強調，不要在一個問題上死磕，我們是在做商業的產品，不是練習，講究的是效率，你的停滯就是對效率的拖拉，對項目的不負責。
所以現在知道為什么你一周的工作會渾渾噩噩地過去了，很多時候，你可以做的更好。如果你抓住了機會提升效率，那你在工作上會更得心應手。
在這個KPI橫行的時代，尤其是困難的時期，要讓領導對你有更好的印象，效率肯定是靠前的，所以，你還在猶豫什么，把這個收藏吃灰，偶爾拿出來吹一吹灰，才是你要做的事。
加油加油加油，躍哥一直都在，和你一起奔跑。