老實說，如果你google搜索“程序員的好習慣”這方面的內容，那么就會有很多大同小異的文章映入你的眼簾。但是今天我想從一個略有不同的角度來探討這個主題。不是關于如何更擅長編程，而是如何使程序員更有市場競爭力。

編寫可讀性強的代碼

我將從與人直覺相反的這一方面開始。我已經數不清我碰到過多少人認為編寫一些不可思議的、復雜的代碼可以為他們提供工作的保障。“如果除了我其他人都不知道薪資報告模塊是如何工作的話，上面就肯定不敢炒我魷魚！”

當然，這在理論上可能是對的。雖然企業老板可能不會炒掉你，但他們也不會支付你很多薪水。如果公司不能在薪資報告模塊上失去你，那么自然而然也不會晉升你。它不會把你放到另一個更受人矚目的項目上。這樣做只會讓你牢固地待在當前位置，就像死水一樣波瀾不驚。

而且，不要自欺欺人地以為這也可以測試市場反應。企業總是希望程序員能夠編寫干凈、可維護的代碼。他們需要刷掉不合格的人以滿足業務需求。如果你的簡歷主要特點是“精通尋租行為”，那么你就不會有很多選擇，因為在一次又一次的晉升考驗中，你的老板總是會略過你。

不要走那條錯誤的路。與之相反，你需要編寫能夠使其他人受益的代碼，并讓業務靈活起來，無論是在項目人員配置上還是在對代碼進行更改的時候。

推理不快樂路徑

在編程世界中，所謂的“快樂路徑”提出了一種高度樂觀的情景。沿著快樂路徑行進，沒有出錯的地方，也沒有錯誤發生。

很多時候，程序員在編程中犯錯誤卻反而發現了快樂路徑。比如說，他們實現一個用戶登錄頁面，當用戶鍵入正確的用戶名和密碼時，登錄成功。但是，如果她輸入錯誤的話，app就會崩潰。但如果她有一個沒填的話，那么app就會將其作為管理員登錄。哇哦。

不能說明不快樂路徑的場景是程序員面臨的一個常見陷阱。事實上，之所以會產生這樣的思維是因為我們在軟件開發的過程中嵌入了自己的假設。于是就算是寫代碼的同一個人也無法來測試代碼。

在編寫和測試代碼時，學會廣泛地去推理不快樂路徑的場景。如果作為開發者的你能夠因為在推理不快樂路徑方面一次成功而出名，那么你對細節的注重將為你賺到更多的酬勞。

創建自動測試

也許你一直堅持反對軟件行業自動化測試的安裝驗收。也許你甚至能編寫比那些TDD和ATDD程序員更好的代碼。在某種意義上，兩者之間真的沒有關系。

不要誤會我。我是自動測試的瘋狂支持者，因為它功用巨大并且可以改進代碼庫。我不但自己實踐TDD，還會去教別人這樣去做。

但是，大家對于職業生涯中關于功用是否應該排在錢包后面的討論，各執一詞。抵制者還是支持者是否正確變得無關緊要。企業越來越多地要求這種技能出現在求職者的簡歷上，但卻沒有一家公司的職位說明上會寫“絕不能編寫單元測試”。學會寫自動化測試，然后見證工作前景的蓬勃發展。

證明你的抉擇

為什么你要在這里使用工廠模式？為什么你選擇那個特定的Javascript框架？如果你在回答這類問題時使用“因為這是正確方法”諸如此類的答案，那么就不會給你帶來任何好處。

這個世界在很大程度上依賴于軟件和軟件開發者的傳遞性。我們擁有經常使我們處于權威地位的專業知識，特別是在與非技術人員或不太有經驗的利益相關者打交道的時候。因此，你會發現，你經常采取的是那種大家嘗試的做法，“我說怎么做就怎么做”。

抵制這樣做的沖動。至少，要解釋你的推理。使用類比和其他方式來幫助人們理解，即使他們缺乏你擁有的技術經驗。最重要的是，學習從經驗出發去做案例，同時借鑒研究、實驗數據或專家意見。職業生涯需要在技術的氛圍中才能發展，所以那些學習將編程決策證明也是商業決策的人會發現他們占據了領導地位。

了解你的代碼如何讓別人賺錢

說到業務對你自己的錢包的重要性，那么你能描述你寫的某一行給定代碼是如何幫助業務嗎？你剛添加的用于停止SQL注入的代碼行——是幫助你避免砸自己的招牌嗎？避免被訴訟嗎？如果它實際上并不能提供任何幫助，那怎么辦？

如果有人付錢讓你寫軟件，那么你的輸出結果就應該產出經濟效益。學習并了解這個利益關系。發展向任何人解答這方面內容的能力。

對最新的客戶端技術或在云中進行加速的能力感到興奮的開發人員比比皆是。對這些東西感到興奮，并且了解如何使用這些能力來賺錢的開發者就少見的多了。

如果你能針對產品特征好好培養對業務動機的理解，那么你就能做得更好。你會找到既能節省時間又同樣能實現業務目標的替代方法。或者，當有一個產品特征證明不可能實現時，你可以提出能降低一部分成本的建議。

企業（特別是真正支付薪水的大boss）喜歡這種軟件人的思維。這將意味著你可以晉升，提供咨詢服務以及擔任領導角色。

對職業的思考

正如我前面提到的，擅長編程代表了職業生涯的其中一個方面，并且是一個重要的方面。建議大家多考慮許多其他的方面，并且有目的地去發展和培養那些習慣。在你自己的時間里，你應該通過一切手段，愛上這個職業。當然還要確保你可以為他人和為自己賺到錢。