一個程序員的讀書筆記：程序設計的反思

剛開始編程的時候是在高中，那個時候計算機課上老師教的是pascal。一種典型的面相過程的語言。那個時候懵懵懂懂的認爲：程序仍是一個蠻神奇的東西，敲幾個英文字符進去，就可以有反饋。即便這個反饋只是很是簡單的輸出了一個「Hello World!」。

而大學開始比較系統的學習計算機這個東西。可是如今回想起來，貌似沒有系統的學過程序設計這個東西啊。即便上了不少叫作《XXX程序設計》的課程以後，對於程序設計這個東西仍是有種霧裏看花的感受。並且學的都是像彙編了，C了這樣的一些比較底層的語言。主要是語法吧，設計層面的東西真的不多。形成很長一段時間內，我對程序設計的認知停留在高中pascal的水平，程序設計就是你輸入個東西，而後設計一系列串行的邏輯，而後等着輸出。

後來上了一個叫作《C++面向對象設計》的課，在上課以前覺得這是一個高大上的課程，結果到最後老師把c++講成了一個好用的c，比c優秀的地方主要就是在加了一些支持面向對象的語法。如今回想一下，那些叫作《XXX程序設計》的課程，基本上都是一些語言課程，貌似和程序「設計」這個東西有點不着邊際。而也未能讓我，對於「面向對象」或者「面相過程」構建起基本的概念。

寫程序的時候，更多仍是停留在pascal那個層次中。串行的邏輯。那個時候的夢想就是可以讀完knuth四卷本的《The Art of program》還有他爲這本書寫的輔導書《基本數學》。由於你們在程序=數據結構+算法的世界觀中，這幾本書如同聖經。最後花了大概四五年吧，只讀了第一卷的300多頁。好吧，貌似我不是一個很虔誠的信徒。

有幸的是，大二開始跟着一個老師給他們當碼農，敲代碼。就這樣稀裏糊塗，斷斷續續的以一個碼農的角色在他們的項目中敲敲打打。那時做爲一個新手，獲得最多的就是「埋汰」。他們看着你寫的c或者c++代碼，說這個太不優雅了。當時，我就想：靠，就是一串代碼，又不是什麼畫，還能用優雅來形容啊。以後，他們開始說一些設計模式了之類如同天書的東西。大三下班學期的時候，有個哥們在搞magic linux的安裝程序的重構。我就聽着他每天在和我白活寫初版安裝程序的是如何如何牛逼哄哄的。模塊劃分的多麼多麼清晰，模塊間通訊居然都是用的xml。設計的可擴展性多麼多麼好，模塊間高耦合地內聚了。。。。當時就以爲，靠，真的很牛逼啊。用如今的一個詞就是：不覺明歷。不過固然，得向牛逼的人學習。因而買了本c++版的《設計模式》，就是最經典的那本。記得那個時候，讀起來，略覺生澀。不少概念都是囫圇吞棗的嚥下去了。在之後的編程中，也能偶爾用用什麼觀察者了，單例了之類的模式。偶爾，可以針對一些問題提出一些看似很是符合設計模式的「設計」。

在接觸到設計模式並可以稍微懂點的時間內，覺得面向對象這個東西的主要內容就是「設計模式」了吧。你看用了設計模式以後，腿也不酸了，要也不疼了，一口氣能上十層樓了。寫代碼也開始有點那種玄乎的「優雅」的感受了。切覺得本身在碼農這個職業上已經算是入門了。直到有一天看了一本叫作《敏捷開發》的書，才猛然間驚醒。他媽的，在設計模式之上還有六大原則：單一職責、里氏替換、開閉原則、迪米特法則、接口隔離原則、依賴倒置原則。原來設計模式被設計出來的時候也是按照必定的指導原則的，那就是六大原則。好吧，如今個人面向對象程序設計的思想庫中又多了一批很是不錯的概念：六大原則。並且驚喜的發現，隨着對這六個原則尤爲是單一職責原則的深刻理解。本身開始，可以慢慢跳出原先那種刻意去使用設計模式的牢籠。開始去關注程序設計自己，或者說具體狀況相關的東西。而不是爲了設計去設計。這個時候，纔開始慢慢的體會到其實程序設計這個東西真的並非簡單的邏輯羅列，而是思想的結晶。是必須通過深思熟慮以後，才能完成的事情。再也不一聽到別人高談闊論高內聚低耦合，就不覺明歷，開始嘗試着去思考他們所謂的高內聚低耦合究竟是個什麼東西，用這個標準來評判一個面相對象的設計是否合適。這個面相過程的遺留品在面向對象的設計範疇內到底可以發揮多大的做用。漸漸的發現，其實高內聚低耦合和單一職責與迪米特法則是那麼的貌離神合。講的都是咱們一段代碼的職責必定要純粹，並且越純粹越好。不要染指其餘代碼的職責。登錄的代碼就負責登錄，不須要管界面上的事情。界面上的代碼就負責展現內容就好，不要負責業務邏輯。當可以清晰的指出系統中每一個模塊，每一個類，甚至是每一個函數那「單純」的職責的時候，那麼整個系統應該說是優雅的了吧。

而這個時候，進行分析與設計的時候老是有種捉襟見肘的感受，一個類的設計，甚至一個方法的定義與實現沒有什麼規矩可言。有些時候從上面說的六大原則和設計模式入手，大概構想出了軟件的模樣。可是到了一些編碼細節上的時候，老是有種力不從心的感受。簡而言之，就是看手氣寫代碼。最終是否可以真實的還原本身的設計，徹底是個靠經驗吃飯的事情。而比較悲劇的是，做爲一個編程經驗沒有十年二十年的人來講，這彷佛有點不太靠譜。做爲一個數學系的學生，那種定理情節油然而生。難道就沒有相似與定理同樣的東西可以幫助我有效的還原設計，定義一個類，定義一個方法。因而又開始了狂看書的路程。

c++之父Bjarne Stroustrup的《The Design and Evolution Of C++》中一句話給了我方向：c++語言在衆多語言的角逐中可以勝出，本質上是一種哲學思想的勝利。乍一看可能認爲是面向對象在實踐中打敗了面相過程開始主導軟件開發語言。可是，當去仔細品味的時候，發現這種哲學思想是一種實用主義的思想。他以目標爲導向，以最終效果爲評判標準。中間所作的一切努力，都是爲了達到最後的目標。就像面向對象誕生的時候，正是軟件規模不斷擴大，軟件複雜性已經超出了人類可控制的範圍。人們急須要一種可以合理的控制整個軟件複雜性的方法，因而就有了面向對象。而複雜性控制這個概念是來自於軟件工程的東西。頓時你就以爲腦海中的不少概念開始高度重合面相對象、軟件工程、複雜性控制、面相過程。。。。。。。定理沒找到，反卻是燉了一鍋佛跳牆。七葷八素裏面什麼都有。

偶然的機會在WIKI上看到了一個詞——工具理性。纔有點開始懵懵懂懂的以爲看到了一點曙光。原來一個Code Monkey廢了半天勁塞進腦瓜裏的全部東西，都是工具而已。編程語言是工具；面向對象設計是工具；敏捷工程是工具。。。。咱們只是合適的使用這些工具來完成目標而已。恍然大悟，其實根本就不必糾結於在編碼的時候用的是面向對象仍是什麼，沒有必要糾結用沒用設計模式，沒有必要糾結開發過程到底敏捷不敏捷。。。只要可以實現最終的目標就行了。只是實現目標的這個過程仍是依舊曲折。如何選擇工具，而且如何有效的使用工具依舊是一個很重要的問題。可是已經有了一個大概的可以指引之後學習方向的思想——瞭解目標、瞭解工具，懂得如何合理並且有效的使用工具，而且Keep it simple。發如今程序設計這個事情上，真正難的不是你寫出了些什麼東西，而是你沒有寫什麼東西。難的不是你進行復雜的設計與編碼，而是儘量少的設計和儘量少的編碼。這有點像國畫中的留白，那些真正簡單的東西纔是最複雜的東西。可以把設計最到最簡纔是真正的功力。一個Redis才幾千行代碼，sqlite也不過3w行左右的代碼。這兩個東西作的事情不可爲不復雜，可是設計的人之功力可見一斑。

最後用一幅畫與你們共勉：