作者：程式設計師小躍

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橫行的時代，尤其是困難的時期，要讓領導對你有更好的印象，效率肯定是靠前的，所以，你還在猶豫什麼，把這個收藏吃灰，偶爾拿出來吹一吹灰，才是你要做的事。

加油加油加油，躍哥一直都在，和你一起奔跑