十年碼農建議：寫代碼時應該反覆問本身8個問題

想成爲一名優秀的程序員嗎？

那麼，如今是時候放下《24小時學會xxx語言》，十年碼農告訴你：優秀的程序員應當養成天天反問本身如下8個問題的習慣。

你的代碼中是否有一種模式存在？

找尋模式中的可行與不可行將發現其中看似無關的想法或基本原則。要對工做達到深刻的理解，你必須養成反問本身「是否有一種模式存在？」的習慣。

它不只僅適用於你的代碼。是否有適應各種型商業變化的模式嗎？是否有一種適用於技術發展的模式？你有沒有看到同類型的錯誤如雨後春筍般冒出來？

怎麼讓代碼變得更簡單？

開發者常常想獲得複雜的和可擴展的解決方案。作一些極爲複雜的東西，以爲本身就是本身宇宙的主宰。問題是未來你永遠沒法預知產品和業務會如何改變。

「架構」和代碼更像是園藝而不是建築。你必需要有能力去適應不斷變化的環境。越複雜的解決方案越難作。

你知道程序爲何要這樣運行嗎？

知道東西像那樣運做和知道爲何會像那樣運做是兩個徹底不一樣的事。若是你知道事情爲何會那樣，那麼你就可以作出更好的決策。

一個偉大的程序員和知道有某種編程語言的人來講，差異在於理解爲何的深度。

一樣的原理也適用於問題修正。

「重啓一下服務。」

「你試太重啓嗎？」

當有問題發生時，咱們常常會想到這些話。每次你這樣說時，你就失去了一個學習的黃金機會。

理解爲何出現這樣的錯誤，將修正根本緣由，避免出現治標不治本。最起碼，你之後不要再犯一樣的錯誤。

以前有沒有人寫過這樣的代碼？

不管什麼時候，你發現本身發明了一個複雜的算法，你極可能走在了錯誤的軌道上。除非你搜索到一份別人正好解決了這個問題博士論文。

須要編寫一個向用戶鼠標旁的item添加標籤的算法？看看Voronoi

Tesselations. 想要找到卡車送貨的最短路徑？看看Dijkstra. 想要找到用戶輸入內容的最接近的標記？應該是找到它的Levenschtein distance.

這只是幾個簡單示例，相信我，它們無處不在。

你知道這種技術的出處嗎？

你認爲你知道REST嗎？

你有讀過Roy Fielding描述REST的論文原文嗎？你真的明白它的最初用意嗎？那種在IDE v7工具中比你多用REST API生成嚮導5分鐘的傢伙寫出來的博客可不算數的。

幫本身一個忙，試圖去讀概念或原理的原始文檔，而後經過各類手段去了解行業領袖的最新發展動態。若是你不知道他們是從哪些開始的，那就緊跟他們的步伐吧？（不知道他們從哪來，就跟着他們到哪去吧！）

我喜歡如今所作的嗎？

請面對編程實際上是很難的。

除了很難之外，編程仍是發展很快的。Art框架從2年前的「笨重恐龍」已經發展到今天的標準。爲了站到你「遊戲」的頂端，你必須樹立一個終生學習和研究的信念。

若是你不喜歡你所作的，那麼你就沒有跟上其餘傢伙（喜歡本身所作的）的可能。因此找到讓你激情燃燒的編程類型！不要由於市場缺口或者收入不菲而決定成爲一名安全專家，不要由於一篇文章說UX是最熱門的職業而決定成爲一名UX專家。

再說一次，作你喜歡的。

作你喜歡的，所需的資源將隨之而來的 ——彼得·麥克威廉斯

這些代碼還能夠用在其它地方嗎？

程序員最大的一個限制就是，本身失敗的想象力。

若是咱們學習到一個適應於特定環境的東西，或者看到解決某個特定問題的技術時，咱們認爲這就它惟一適用的地方。這是徹底錯誤的。每當學到新東西時，反問本身：「其餘地方還可使用嗎？」

當發現了在圖表上定位節點的新的偉大的方法時，是否是能夠將它應用於二維數據集中感興趣數據的定位呢？

當發現經過websockets從客戶端發送數據到服務器端的新方法時，它怎麼才能應用到可擴展的後臺服務上呢？有時是錯誤的，但有時也是正確的。

這給咱們帶來了下一個問題……

難道真的沒有辦法嗎？

咱們生活在世界上很小的一個地方是不可能的（除了少數例外）。

假設無論你作的什麼事情都是可行的，而後採用向後的方向回推回去。你可能會發現，你想作的暫時是不切實際的，但它足以改變世界，可能變成現實的速度比你想像的還要快。

得程招聘，千萬程序員求職新選擇！本文由得程撰寫。