讓你變成優秀程序員的幾個小習慣

做者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塊內部拋出異常的時候發生了什麼？和你們一塊兒分享。