程式員寫代碼時應該反複問自己的 10 個問題

你想成為一名優秀的程式員嗎？

那麼，現在是時候放下《24小時學會xxx語言v8.3》超級騙子書，相反，你應當養成每天反問自己以下10個問題的習慣。

找尋模式中的可行與不可行将發現其中看似無關的想法或基本原則。要對工作達到深入的了解，你必須養成反問自己“是否有一種模式存在？”的習慣。

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

所謂了解就是要了解模式 — 以賽亞·伯林

開發者經常想得到複雜的和可擴充的解決方案。做一些極為複雜的東西，覺得自己就是自己宇宙的主宰。問題是将來你永遠無法預知産品和業務會如何改變。

“架構”和代碼更像是園藝而不是建築。你必須要有能力去适應不斷變化的環境。越複雜的解決方案越難做。

簡潔是終極的複雜 —  列昂納多·達·芬奇

知道東西像那樣運作和知道為什麼會像那樣運作是兩個完全不同的事。如果你知道事情為什麼會那樣，那麼你就能夠做出更好的決策。

一個偉大的程式員和知道有某種程式設計語言的人來說，差别在于了解為什麼的深度。

同樣的原理也适用于問題修正。“重新開機一下服務。” “你試過重新開機嗎？” 當有問題發生時，我們經常會想到這些話。每次你這樣說時，你就失去了一個學習的黃金機會。

了解為什麼出現這樣的錯誤，将修正根本原因，避免出現治标不治本。最起碼，你以後不要再犯同樣的錯誤。

無論何時，你發現自己發明了一個複雜的算法，你很可能走在了錯誤的軌道上。除非你搜尋到一份别人正好解決了這個問題博士論文。

需要編寫一個向使用者滑鼠旁的item添加标簽的算法？看看voronoi

tesselations. 想要找到卡車送貨的最短路徑？看看dijkstra. 想要找到使用者輸入内容的最接近的标記？應該是找到它的levenschtein distance.

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

我能夠看得更遠，那是因為我站在巨人的肩上 — 艾薩克·牛頓

你認為你知道rest嗎？

你有讀過roy fielding描述rest的論文原文嗎？你真的明白它的最初用意嗎？那種在ide v7工具中比你多用rest api生成向導5分鐘的家夥寫出來的部落格可不算數的。

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

請面對程式設計其實是很難的。

除了很難以外，程式設計還是發展很快的。art架構從2年前的“笨重恐龍”已經發展到今天的标準。為了站到你“遊戲”的頂端，你必須樹立一個終生學習和研究的信念。

如果你不喜歡你所做的，那麼你就沒有跟上其他家夥（喜歡自己所做的）的可能。是以找到讓你激情燃燒的程式設計類型！不要因為市場缺口或者收入不菲而決定成為一名安全專家，不要因為一篇文章說ux是最熱門的職業而決定成為一名ux專家。

再說一次，做你喜歡的。

做你喜歡的，所需的資源将随之而來的 — 彼得·麥克威廉斯

我看到程式員最大的一個限制就是，自己失敗的想象力。

如果我們學習到一個适應于特定環境的東西，或者看到解決某個特定問題的技術時，我們認為這就它唯一适用的地方。這是完全錯誤的。每當學到新東西時，反問自己：“其他地方還可以使用嗎？”

當發現了在圖表上定位節點的新的偉大的方法時，是不是可以将它應用于二維資料集中感興趣資料的定位呢？當發現通過websockets從用戶端發送資料到伺服器端的新方法時，它怎麼才能應用到可擴充的背景服務上呢？有時是錯誤的，但有時也是正确的。

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

邏輯隻能帶你從a到z，想像力去可以帶你到任何地方 — 阿爾伯特·愛因斯坦

增加創收的最簡單方法是降低錯誤的損失。

遊戲開發公司valve和其他幾個公司很認為這個觀點。這同樣适用你成為web開發者的進步過程。如果你害怕失敗，你就不會有大的突破。

勇敢、嘗試、失敗、學習然後再來。

不要害怕錯誤，它能讓你認識失敗，然後重新來過。— 本傑明·富蘭克林

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

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

似乎一切看起來都是不可能，除非你完成它 — 納爾遜曼德拉

永遠不要在一群你在其中是最聰明的人的地方工作。

挑選擁有可以啟發你、激勵你做得更多的同僚的工作和公司。不要與程式設計扯上關系，在文本編輯器和指令行外面還有一個完整的世界存在。從其他領域學習，設法應用到你的工作中。

永遠不要滿足于能勝任現有的工作！