前言
回顧大約7年的程序員生涯，從一開始的小白，到如今成長爲一個能夠去幫助他人的程序員，雖然離大牛還差得遠，但仍是有些東西想寫一寫，就當思緒的偶爾停留。若是能對他人有所啓發，就是意外的收穫了。 這裏不寫具體的編程語言、技術內幕，而是寫一些廣泛適用的，甚至不止適用於編程領域的內容。這些所謂「進階思惟」，有些是我在成爲程序員以前就具有的，有些是我後來慢慢學會的。按照慣例，先整體羅列出來：程序員
- 並行思惟
- 併發思惟
- DRY (Don't Repeat Yourself)
- 可維護性 >= 性能
- 防護式編程
下面我將逐一闡述。編程
正文
並行思惟
提到並行，就不得不提「串行」。併發
咱們常常去銀行辦理業務，有些銀行中午也上班，但會關閉一些窗口，若是隻留一個開放窗口，客戶只能依次辦理業務，這種情形就是串行。編程語言
中午事後，工做人員陸續回來了，其它窗口陸續開放，客戶能夠同時辦理業務了，這種情形就是並行。佈局
很明顯，開放的窗口越多，銀行接待客戶的效率越高，客戶等待的時間越短。用一個專業詞語來講，開放窗口越多，並行度越高。性能
有些大型超市，在購物高峯期會增長收銀通道，這也是提升並行度的例子。測試
以上是生活中的場景，跟寫程序無關，如今假定你須要處理1000萬條數據，通過初步測試，從頭開始逐條處理，預計須要10個小時能處理完。實際狀況須要你想辦法在1個小時內處理完，此時你應該能從銀行或超市獲得啓發。進程
逐條處理，至關於只開了一個窗口（程序），若是開10個窗口（程序），速度就能夠乘以10倍。資源
這裏是按數據ID的維度並行處理，是否還有其它的維度呢？文檔
併發思惟
故事仍是發生在銀行，時間到了中午，客戶依然在排隊，開放窗口只剩下一個了。這時有一些不守規矩的客戶，又排了一個隊出來，一個窗口，兩個隊伍，工做人員很爲難。
大堂經理看到狀況不妙，過來勸說，讓這一波不守規矩的人排在原有隊伍的後面，成功解圍。
一個窗口，兩個隊伍，對於窗口來講，這種情形就是併發。
從程序的角度看，典型的場景是多個進程同時去修改同一個資源，例如多個進程同時去修改一個計數器。假定業務實例編號的自動生成規則，新編號爲已有的最大編號加1，這是否存在併發問題？
簡單的想一下，當前最大編號爲100，兩個用戶同時建立實例，若是不考慮併發，兩個用戶獲得的編號都是101，這顯然是一個bug。
如何判斷代碼是否存在併發問題，只須要判斷：兩個進程同時執行這段代碼，是否會出問題。
如何處理併發問題？大堂經理的作法能夠帶來一些啓發。
DRY (Don't Repeat Yourself)
此次的故事發生在銀行大堂經理身上。最近銀行作了一次裝修，櫃檯佈局有些變化，常常有客戶問xx業務在哪辦理。經理在回答了10多遍以後，在銀行入口處貼了一張告示：xx業務辦理，左轉倒數第二個櫃檯。
大堂經理這麼作，是由於他不想重複回答同一個問題。
聯想到寫代碼，DRY的通俗表達就是「封裝」。有些「懶」的程序員，一樣的代碼寫3遍就去封裝了，有些人則比較「勤快」，不厭其煩地寫着一樣的代碼。
看來，懶並非一個貶義詞，程序員應該懶一點。
DRY帶來的另外一個好處：減小代碼冗餘。重複10遍的代碼，修改起來也須要10次；若是封裝起來，修改只須要一次，維護成本急劇降低。
再聯想到平常的工做溝通，若是發現本身老是在重複回答一些問題，不妨寫一篇QA文檔，若是再有人問，直接讓他/她去看文檔便可。
可維護性 >= 性能
有一句不知出處的話：代碼首先是寫給人的，其次纔是寫給機器的。
軟件代碼老是被不斷維護、重構，這些都是人的工做，因此代碼首先是寫給人的。
若是一段代碼沒人維護，只有兩種可能：沒用的，或沒法維護的。
一段代碼沒人能讀懂，或者讀懂代碼太花時間，還不如重寫，即便它的性能很好，也是無用的垃圾。
顯然，代碼量越少，相應的維護成本就越低，這也是DRY原則提倡的。舉個例子，一個方法原本有100行，重構後增長200行，性能提高10%，這時就須要在可維護性與性能之間做出取捨了。
100行的代碼清晰易讀，性能略差；300行的代碼晦澀難懂，性能較好。你選哪個？
防護式編程
你們都有乘車的經歷，前段時間去千島湖，我乘坐的大巴，老是緊跟着前車行駛，駕駛員假定前面的車不會急剎。
防護式駕駛，是假定他人的駕駛是不可靠的，行人是不可靠的，自身主動去規避風險。爲了不前車急剎致使追尾，須要保持車距。
引伸到編程，防護式編程就是自身主動去規避他人的代碼錯誤，例如參數傳遞錯誤，返回值錯誤等。
對於PHP這種弱類型語言，一個方法接受array類型的參數，若是在一開始就檢查參數類型，就屬於防護式編程。調用他人的API，拿到返回結果的第一時間就去校驗是否符合預期，這也是防護式編程。
歸納成一句話：防護式編程是自身主動去規避風險，避免他人的錯誤致使自身程序崩潰。
後記
這篇文章斷斷續續寫了一週，還有一些想法之後繼續寫。
歡迎批評指正。