編程低效率聯盟入會指南……

全文共1924字，預計學習時長6分鐘

編程拖延症協會宣：

正所謂DDL是第一生產力，對於編程來說也不例外。來吧！熬最晚的夜，用最貴的生髮水，頂著最重的黑眼圈，敲最厲害的代碼。如何降低編程效率，具體做法請參考入會指南。下面這六個習慣，每擁有一個，你就離入會近一點。一起拖延吧~

（清醒點呀，退會要趁早！）

一、出席會議

當你什麼都不想做的時候，會議就變得必不可少了。——約翰·肯尼思·加爾布

會議可能是生產力的第一殺手，大多數開發人員仍然在過多地參加會議，可以分為兩種類型。

第一類會直接跳過每次會議，而花時間在敲鍵盤上。這些開發人員認為大多數會議都是浪費時間，不如做些實際工作。第二類正好相反，他們會抓住每一個機會參加每一個預定的會議。

第二類開發人員會浪費很多時間，他們本可以將時間花在寫代碼和提高效率上的。

幾乎所有會議都存在這樣的問題，半個小時能說完的事兒能拖到一個小時或者更長。開發人員其實可以拒絕出席很多會議，或者至少拒絕出席中午之前的會議，這樣就能提高上午的工作效率。如果真的要出席，至少要拒絕時間過長的會議。

二、編寫自己的數據結構

編寫自己的數據結構其實就是浪費時間做無用功，這是一個極其低效的習慣。所有需要的數據結構都已經存在，隨時可以使用，通常情況下你不需要重新建構特定的數據結構。

這並不是做無用功的唯一例子，他們還經常重新編寫某些代碼片段。

如果同一段代碼已經存在，並且已知是穩定的、維護良好的，那麼直接使用就可以。自己編寫代碼並不會有什麼新花樣，甚至還會缺少一些功能，變得更糟。它唯一可能引入的新東西就是bug或者一些限制。

不過做這些無用功也有好處，如果開發人員想對某些東西有更深入的了解，那麼這樣做是完全可以的。但大多數情況下，這種行為還是應該避免，因為它會浪費太多時間。有時付出時間成本是合理的，但有時卻是純粹的浪費。

還有一些時候，任務非常關鍵，犯錯可能會產生可怕的後果——那麼做無用功就不是最佳選擇了。

三、過度工程化

過度工程化是許多開發人員的壞習慣之一。在查看代碼庫時，開發人員常常會發現過度工程化的代碼片段。

過度工程化通常會使產品設計太過穩健或複雜，開發人員有時會添加一些他認為將來可能有用的代碼，其實並不必要。

這些代碼可能永遠不會被使用。大多數情況下，代碼建構了很多實際不需要的東西，都是基於開發人員的猜測。也許過度工程化最好的解釋是——代碼正是在幫人們解決實際不存在的問題。

過度工程化會導致代碼設計得過於通用，以至於忽略了最初設定好的需要執行的任務。因此，這樣的代碼不僅難以使用，而且從根本上來說並不明智。

四、沒有計劃

迅速開始著手一個編碼項目可能會讓人興奮，但這種興奮可能會浪費很多時間。如果開發人員直接開始著手編碼，最終會失去對大局的掌控。

開始編碼前，開發人員需要進行規劃和組織。如何解決這個問題？實施什麼結構？總體目標是什麼？

在開始編碼之前，這些都是很好的問題，可以讓開發人員更清楚地意識到，其實在編寫代碼之前有很多事情要考慮。

如果沒有計劃，最後產出的功能可能與客戶的要求有偏差，甚至導致採用錯誤的解決方式，這將會更糟。這就導致開發人員不得不重新檢查代碼，進行修改，而這樣非常低效。

五、非一致性

一直壞，總好於偶爾好偶爾壞。

對於軟體開發來說，一致性確實是關鍵。不一致的問題在於時間會破壞軟體——這是不可避免的事實。一個軟體存在的時間越長，使用的人越多，就會越來越混亂。

一致性對於代碼庫的可維護性很重要，尤其是長遠看來，這是個好消息。如果開發人員決定將駝峰式大小寫風格用於變量，那麼就不要再變化。想用spaces代替tabs？可以！代碼里怎麼設置並不重要，重要的是保持一致性。

六、不尋求幫助

只有伸手的人才會得到幫助——J.K.羅琳

無論多麼資深的開發者，都難免陷入困境。遇到這種情況時，保持一個簡單的反饋循環系統是非常重要的。

尋求幫助並不意味著無能。而幾個小時盯著螢幕，為了同樣的問題苦苦掙扎，才會被認為無能。在尋求幫助之前，開發人員應該確保自己已經檢查了所有能力範圍內的事情。為了不必要的事情打擾其他開發人員並不可取。

通常情況下，其他的開發人員都會給出正確的方向，這樣會節省很多時間，以便繼續完成任務，而不是單憑自己的力量解決。

每天改變一點點，和低效率說再見，趕快行動起來吧！

留言點贊關注

我們一起分享AI學習與發展的乾貨

如轉載，請後台留言，遵守轉載規範