讓你變成優秀程式設計師的幾個小習慣

本文由碼農網 – 小峰原創翻譯，轉載請看清文末的轉載要求，歡迎參與我們的付費投稿計劃！

作者Jeff Standen，有著21+年經驗的軟體開發者。

首先開發spike解決方案——這是我早期敏捷/極限程式設計所養成的習慣之一。spike解決方案是一次性原型，可以幫助你在投入大量時間和精力之前驗證你是否走對路。

區別就在於原型，因為你遵循這樣一個規則，在你完成研究之後，你最終會扔掉“spike”程式碼。所以允許你偷工減料，迅速行動，因為它不會出現在產品或程式碼審查中。

此方法有助於迅速發現設計的哪些部位尚不明確，而不必過早地嘗試架構或設計決策。

致力於小而連貫程式碼塊的版本控制——通過類似CVS/Subversion，每次提交都直接傳送到伺服器。做部分檔案的提交併不簡單。

隨著Git的出現，只提交較大檔案的若干行程式碼變得很容易，並且可以在push到遠端程式碼倉庫之前先本地rebase/merge提交。

有一次，我在工作於更大功能的時候，採用了小型增量提交，我的工作效率直線上升。這樣做能夠清空我的大腦以便於面對更重要的事情。

經常寫程式碼——最近，我正工作於：一個基於Web的企業協作和自動化平臺（PHP / MySQL），一個基於雲的實時指標聚合器和使用迴圈雜湊（Node.js/ Redis）的API，一個面向iOS app商店（Swift/ SpriteKit）的棋盤遊戲，專門的基於URL的cronjob可替代基於web的SaaS服務（JAVA），等等。

用過大量框架和語言有助於我的抽象和演算法思維。

我從工具，如Eclipse RCP、Tapestry和Hibernate中學到了很多偉大的經驗教訓，並用到我的PHP專案裡。尤其是在2000年初，在有Java特徵的企業生態系統用於PHP存在之前。我從Unity3d/C＃學到了很多關於網路和麵向訊息的架構。

如果我只堅持單一平臺和社群的話，就永遠不會知道這些概念。

編寫簡單的程式碼——我以前習慣於寫複雜的程式碼以作為對自己的挑戰。而現在的挑戰是要編寫優雅且簡單的程式碼——到一種每個人都覺得他們也能做到的地步（即使他們不能）。簡單程式碼通常來自於若干次複雜程式碼的迭代。

引用Antoine de Saint Exupéry的話就是：“不是沒有什麼可新增，而是沒有什麼可消減的時候，才算是達到了完美。”

這也使得我們在長時間休止之後返回專案，以及鼓勵其他人蔘與進來變得容易多了。

最後優化——我們很容易掉入試圖比使用者或計算機更聰明，並且預優化各種邊緣情況的陷阱。關注帕累托法則（80％的效果來自於20％的工作）。寫程式碼，執行程式碼，當必要的時候專注於最大的瓶頸。這也支援保持程式碼庫的簡單。

說“不要首先優化程式碼”並不意味著“編寫粗糙的程式碼”。程式碼總是應該精益和優雅，沒有必要畫蛇添足，不要將一整天的時間用在擠壓剩下的10％，但其實已經能夠工作良好的一些東西上。不但工作效率會下降，而且還會引進更多複雜性，解決方案變得不那麼可歸納，等等。

著眼於“最重要的事情優先”——總是有一些專案領域比其他的更有趣或更具挑戰性。工作於那些有趣的東西總是比工作於那些必要的東西更有誘惑。

在攻克重要部分時，將有趣部分作為一種調劑，也就是說，兩者都做一點也是可以。

因此，光從這一點上說，將大的問題分解成小問題的理念是不言自明的。每個人都懂。所以，我會通過計分若干“quick wins”來開啟我的一天，這能讓我更有衝勁和更專注（“quick wins”可以是任何東西，包括有趣又小型的挑戰），然後我會首先衝向“最重要的事情”。

瞭解全棧——當我剛開始幹這一行的時候，沒有什麼比等別人做完他們那部分東西，然後我才能繼續我那部分工作更糟糕的了（設計師，後端人員，前端人員，資料庫人員，伺服器人員，等等）。

於是，當我2000年創辦自己的軟體開發公司的時候，我做了一個明智的決定，那就是涉獵全棧。我知道我不可能擅長所有東西，也不可能是最後唯一對所有一切負責的人，但我想要做終端到終端的原型，因為我沒有耐心看過程。

每當我需要的東西觸碰到我不懂的領域時，我會研究它。於是乎，我學會了伺服器管理，資料庫管理，設計，前端/後端開發，雲架構等。

通過了解其他領域是做什麼的，我才能寫出包含它們需要的程式碼。

當然，其中的一些要點似乎並不是所謂的“小習慣”，但我向你保證，它們是小變化歷經20年時間導致的結果。重要的行為變化並沒有意義，更多的是關於我是如何頻繁地練習這門技術（在過去10年時間中每年大概4000-5000個小時）。

所以，我的做法更像是去回答這個問題：“什麼樣的小習慣會導致更糟糕的軟體和低效的生產力？”，然後反過來。

作者Ed Prentice，軟體工程師

時間是寶貴的，所以要儘可能地節省時間。儘可能自動化。一旦時間成為一種商品，那麼你可以實現下一個偉大的創新。

使用功能強大的IDE（如vim），並將其配置能為你做盡可能多的事情。力爭單個命令Build/Test/Deploy/Run。

如果你發現自己常做某件事情，那麼可以讓它們在一個按鍵下發生，或者一次點選下發生。或者更好的是，讓它們自動發生。

瞭解鍵盤快捷鍵和UNIX命令列。幾乎所有的IDE都可以讓你執行復雜的編譯命令，甚至任意的終端命令——不但強大，並且可以為你節省大量的時間。

提問題，然後提更多的問題。如果有什麼你不明白的事情發生了，那就問為什麼。然後走開，研究替代方案，並提出來。一直問問題直到你可以詳細地給下一個問為什麼的開發人員解釋。我時常感到奇怪為什麼會有這麼多開發人員不知道為什麼，僅僅是因為覺得“它總是/曾是這樣”。

通過提供更好的替代解決方案挑戰現狀——並且制定步驟實現。如果你的測試不完整，或每天/每週執行一次——那麼成為本地的Continuous Integration大師——目的是為了有利於你的團隊，並實現它。一旦你使用它並且它可以幫助你更好工作的話，那麼讓你的團隊也使用它。

不要只是挑戰別人，挑戰自己。從來沒有寫過web應用程式？那麼寫一個。從未用過Python？用Python劫持無人飛行器。

擁有一些東西。創造一些東西。沒有必是非要做技術專案，可以是一個事件，例如聚會或程式設計馬拉松，也可以是一個遊戲，一個網站，一個部落格。

教一些東西。Java，公開演講，寫作，下棋，vim，網球。

成為一個傑出的人。拿到一個垃圾類/元件？修復好它。編寫程式碼的正確途徑。不在程式碼中走捷徑。做出明智的決策，向你周圍的人說明為什麼你要做這個決定的利弊。總是改善程式碼。制定不需要花費1小時的待辦事項表？Just Do It。

瀏覽你熟悉的Stack Exchange的話題——例如你喜歡的語言。當你發現什麼新的東西的時候，儘快末位淘汰相關知識。知道C語言？什麼是分支預測？這篇文章會告訴你——你要做的就是學習。

瀏覽你不熟悉的Stack Exchange的話題——好好學習，天天向上。

學會溝通。書面文字，呈現展示，解決問題，小卻激烈的小專案，大型團隊，小型團隊。

文件化你的所有過程。你可以回頭查閱你為什麼做這些事情，以及依賴原先的解決方案去解決碰到的相似問題。這還有助於捕捉你可能會忘記的思維過程和關鍵的資訊片段。我經常通過日誌來回顧前幾天的工作。

在你寫之前文件化你的程式碼。使用系統圖，類層次結構，流程圖表，以展示說明你的程式碼將如何工作。如果有人提出建議——是的，他們會提出來的——那麼你可以進行修改，這比已經寫好了程式碼再去修改要容易得多。這是另一個我很少看到有人會做但卻有著最負面影響的事情。

特定化。為新的東西製作圖表，向大家展示。收集儘可能多的細節。確保每個人同意這個圖表。如果有人提出了建議，那就補充/新增更正到圖表。保持圖表更新。

知道潛意思的偏見和男性特權。瞭解你是哪種MBTI和人格型別，並且更重要的是，要知道如何與其他性格型別更好地互動。瞭解情商。每個人都是不一樣的，你需要知道如何與他們進行最有效和最有建設性的互動。

定期為團隊做一些事情。帶餅乾。教魔術。培育一點文化，並鼓勵其他人也這樣做。讚美其他人的貢獻。一支有凝聚力的團隊是很難被擊敗的。

學習如何與人合作。我個人非常喜歡《The Pragmatic Programmer》的“stone snop”。

理解和使用別人的程式碼。如果你正在實現自己的XML解析器或或csv閱讀器或git hook，那麼你就是在重新發明輪子。

一旦你寫了程式碼，並且它是有效的，通過測試的，那麼回過頭去整理一下吧。重新執行測試。再整理。每個類都應該有單一的職責，每個函式都應該只做一件事情。在大多數情況下，函式應該小於20行程式碼的長度。使用自文件的函式名和變數名。花時間整理你的程式碼以後將會10倍地回報給你和你的團隊。

參與其中。承擔責任。如果事情有不對的地方，那就解決它。如果最後期限臨近了又想出了一個解決方案，那讓其他人儘快知道。任何人都可以做到這一點，即使是最初級的開發人員。這要求對專案的藍圖，方向和截止期限有著大局觀的認識——參與進來。儲存好每天的工作內容！

和團隊分享學到的經驗教訓（在適當的時候）。指出Java中finally塊內部丟擲異常的時候發生了什麼？和大家一起分享。