你的代碼中是否有一種模式存在？
找尋模式中的可行與不可行將發現其中看似無關的想法或基本原則。要對工作達到深入的理解，你必須養成反問自己“是否有一種模式存在？”的習慣。
它不僅僅適用於你的代碼。是否有適應各類型商業變化的模式嗎？是否有一種適用於技術發展的模式？你有沒有看到同類型的錯誤如雨後春筍般冒出來？
所謂理解就是要理解模式 — 以賽亞·伯林
怎麼讓代碼變得更簡單？
開發者經常想得到複雜的和可擴展的解決方案。做一些極為複雜的東西，覺得自己就是自己宇宙的主宰。問題是將來你永遠無法預知產品和業務會如何改變。
“架構”和代碼更像是園藝而不是建築。你必須要有能力去適應不斷變化的環境。越複雜的解決方案越難做。
簡潔是終極的複雜 — 列昂納多·達·芬奇
你知道程序為什麼要這樣運行嗎？
知道東西像那樣運作和知道為什麼會像那樣運作是兩個完全不同的事。如果你知道事情為什麼會那樣，那麼你就能夠做出更好的決策。
一個偉大的程序員和知道有某種編程語言的人來說，差別在於理解為什麼的深度。
同樣的原理也適用於問題修正。“重啟一下服務。” “你試過重啟嗎？” 當有問題發生時，我們經常會想到這些話。每次你這樣說時，你就失去了一個學習的黃金機會。
理解為什麼出現這樣的錯誤，將修正根本原因，避免出現治標不治本。最起碼，你以後不要再犯同樣的錯誤。
之前有沒有人寫過這樣的代碼？
無論何時，你發現自己發明了一個複雜的算法，你很可能走在了錯誤的軌道上。除非你搜索到一份別人正好解決了這個問題博士論文。
需要編寫一個向用戶鼠標旁的item添加標籤的算法？看看Voronoi
Tesselations. 想要找到卡車送貨的最短路徑？看看Dijkstra. 想要找到用戶輸入內容的最接近的標記？應該是找到它的Levenschtein distance.
這只是幾個簡單示例，相信我，它們無處不在。
我能夠看得更遠，那是因為我站在巨人的肩上 — 艾薩克·牛頓
你知道這種技術的出處嗎？
你認為你知道REST嗎？
你有讀過Roy Fielding描述REST的論文原文嗎？你真的明白它的最初用意嗎？那種在IDE v7工具中比你多用REST API生成嚮導5分鐘的傢伙寫出來的博客可不算數的。
幫自己一個忙，試圖去讀概念或原理的原始文檔，然後通過各種手段去了解行業領袖的最新發展動態。如果你不知道他們是從哪些開始的，那就緊跟他們的步伐吧？（不知道他們從哪來，就跟著他們到哪去吧！）
我喜歡現在所做的嗎？
面對編程其實是很難的。
除了很難以外，編程還是發展很快的。Art框架從2年前的“笨重恐龍”已經發展到今天的標準。為了站到你“遊戲”的頂端，你必須樹立一個終生學習和研究的信念。
如果你不喜歡你所做的，那麼你就沒有跟上其他傢伙（喜歡自己所做的）的可能。所以找到讓你激情燃燒的編程類型！不要因為市場缺口或者收入不菲而決定成為一名安全專家，不要因為一篇文章說UX是最熱門的職業而決定成為一名UX專家。
再說一次，做你喜歡的。
做你喜歡的，所需的資源將隨之而來的 — 彼得·麥克威廉斯
這些代碼還可以用在其它地方嗎？
我看到程序員最大的一個限制就是，自己失敗的想象力。
如果我們學習到一個適應於特定環境的東西，或者看到解決某個特定問題的技術時，我們認為這就它唯一適用的地方。這是完全錯誤的。每當學到新東西時，反問自己：“其他地方還可以使用嗎？”
當發現了在圖表上定位節點的新的偉大的方法時，是不是可以將它應用於二維數據集中感興趣數據的定位呢？當發現通過websockets從客戶端發送數據到服務器端的新方法時，它怎麼才能應用到可擴展的後臺服務上呢？有時是錯誤的，但有時也是正確的。
這給我們帶來了下一個問題……
邏輯只能帶你從A到Z，想像力去可以帶你到任何地方 — 阿爾伯特·愛因斯坦
今天有什麼做錯的嗎？
增加創收的最簡單方法是降低錯誤的損失。
遊戲開發公司Valve和其他幾個公司很認為這個觀點。這同樣適用你成為web開發者的進步過程。如果你害怕失敗，你就不會有大的突破。
勇敢、嘗試、失敗、學習然後再來。
不要害怕錯誤，它能讓你認識失敗，然後重新來過。— 本傑明·富蘭克林
難道真的沒有辦法嗎？
我們生活在世界上很小的一個地方是不可能的（除了少數例外）。
假設不管你做的什麼事情都是可行的，然後採用向後的方向回推回去。你可能會發現，你想做的暫時是不切實際的，但它足以改變世界，可能變成現實的速度比你想像的還要快。
似乎一切看起來都是不可能，除非你完成它 — 納爾遜曼德拉
我可以向誰學習？
永遠不要在一群你在其中是最聰明的人的地方工作。
永遠不要滿足於能勝任現有的工作！
閱讀更多 千鋒大連 的文章
