初次讀完這本書，思想裡還是作者的思想，不過這本書還是給了我點教訓，一直覺得自己做開發不合適，就現在
看完這本書的時候，我覺得我錯了，不是自己做開發不合適，而是自己的思想一直這樣去想問題，從未放開去拼搏
一次，真正的去做個實在的東西出來，才是最真的。
有些文字我並沒有理解，不單單是我收錄的這部分，還有很多。其實作者給我的思想我也都領會了，也懂，只是
就一種感覺啊，覺得自己一直以來很可笑，比如說第三章第5節「那我們就開始開發吧」，這個話是我們經常講
的，畢業設計開始了，課題選好了，準備開發了，我們同學都說過這樣的話，「那我們就開始開發吧，我們只有三
個月的時間。。。」看到這個標題，我開始思考這一章節作者要給我們分析的是什麼，要教會我們什麼，我想的是
應該是直接說開發之前的準備工作，需求分析，概要設計等等，但是。。。看完才知道，作者乙個需求未提，乙個
方法未講，我卻領會的更深刻，我想作者的本意就在與此吧！
不想多說了，總之一句話，這本書值得同我經驗不足的程式設計師讀，更值得開發經驗豐富的人去讀。
收錄的章節會在不斷的充實自己之中慢慢的理解，我不求急功近利，只求可以有些許進步。
待續 我的第一次思考：程式 = 演算法 + 結構 + 方法
我對程式的本質的第一次思考其實發生在不久前。那是我在oicq上與soul（王昊）的一次談話。
soul是delphibbs現任的總版主，是我很敬重的一位程式設計師。那時我們正在做delphibbs的乙個「b計畫ii」，也就是出第二本書。他當時在寫一篇有關「物件導向（oop）」的文章，而我正在寫《delphi源**分析》。在這本書的初期版本裡，有「物件導向」這一部分的內容。
這段對話的確很長。如果你不是非常有經驗的程式設計師，那麼不能完整地閱讀和理解這段文字是很正常的。部分讀者甚至可以跳過這段引文，直接閱讀後面的結論。
我們的對話摘要如下。
soul：我在寫書討論「物件導向的侷限性」。
我：嗯。這個倒與我的意見一致。哈哈哈。
「絕對可以用面向過程的方法來實現任意複雜的系統。要知道，太空梭也是在面向過程的時代上的天。但是，為了使一切變得不是那麼複雜，還是出現了『物件導向程式設計』的方法。」
——我那本書裡，在「物件導向」一部分之前的引文中，就是這樣寫的。
soul：現在的程式是按照馮·諾伊曼的第一種方案做的，本來就是順序的，而不是同步的。cpu怎麼說都是一條指令一條指令執行的。
我： 面向過程是對「流程」、「結構」和「程式設計方法」的高度概括。而物件導向本身只解決了「結構」和「程式設計方法」的問題，而並沒有對「流程」加以改造。
soul：確實如此。確實如此。
我：對流程進一步概括的，是「事件驅動」程式模型。但這個模型不是oo（物件導向）提出的，而是windows的訊息系統內建的。所以，現在很多人迷惑於「物件」和「事件」，試圖通過oo來解決一切的想法原本就是很可笑的。
soul：我先停下來，和你討論這個問題，順便補充到書裡去。
我： 如果要了解事件驅動的本質，就應該追溯到windows核心。這樣就涉及到執行緒、程序和窗體訊息系統這些與oo無關的內容。所以，整個的rad（快速應用程式開發）程式設計模型是oo與os（作業系統）一起構建的。現在很多的開發人員只知其oo的外表，而看不到os的核心，所以也就總是難以提高。
soul：oo裡面，我覺得事件的概念是很牽強的，因為真正的物件之間是相互作用，就好像作用力和反作用力，不會有個「順序」的延時。
我：應該留意到，整個的「事件」模型都是以「記錄」和「訊息」的方式來傳遞的。也就是說，事件模型停留在「面向過程」程式設計時代使用的資料結構的層面上。因此，也就不難明白，使用或不使用oo都能寫windows程式。
因為流程還是在「面向過程」時代。
soul：所以所謂的物件導向的事件還是「順序」的。所以我們經常要考慮乙個事件發生後對其他過程的影響，所以物件導向在現在而言還是牽強的。
我： 如果你深入os來看she（結構化異常處理），來看messages（窗體訊息），就知道這些東西原本就不是為了oo而準備的。物件導向封裝了它們，卻無法改造它們的流程和核心。因為oo的抽象層面並不是這個。
事件的連續性並不是某種程式設計方法或者程式邏輯結構所決定的。正如你前面所說的，那是cpu決定的事。
soul：比如條件選擇，其實也可以用一種物件來實現，而事實卻沒有。這個是因為cpu的特性和物件導向太麻煩。
我： 可能，將cpu做成物件導向的可能還是比較難以想象和理解。所以ms才啟動.net framework。我不認為.net在物件導向方法上有什麼超越，也不認為它的fcl庫會有什麼奇特的地方——除非它們足夠龐大。但是我認為，如果有一天os也是用.net framework來編寫的，os一級的訊息系統、異常機制、執行緒機制等都是.net的，都是物件導向的。那麼，在這個基礎上，將「事件驅動」併入oo層面的模型，才有可能。
soul：所以我發覺物件導向的思維第一不可能徹底，第二只能用在總體分析層上。在很多時候，實質上我們只是把乙個順序的流程摺疊成物件。
我：倒也不是不可能徹底。有絕對oo的模型，這樣的模型我見過。哈哈，但說實在的，我覺得小應用用「絕對oo」的方式來編寫，有失「應用」的本意。我們做東西只是要「用」，而不是研究它用的是什麼模型。所以，「hello world」也用oo方式實現，原本就只是出現在教科書中的sample罷了。哈哈。
soul：還有不可能用徹底的物件導向方法來表達世界。 因為這個世界不是物件導向的。是關係網路圖，物件導向只是樹，只能片面地表達世界。所以很多時候物件導向去解決問題會非常痛苦。所以程式設計退到資料結構更合理，哈哈。
我：如果記憶體是「層狀訪問」的，那麼我們的「資料結構」就可以基於多層來形成「多層資料結構」體系。如果記憶體是「樹狀訪問」的，那麼我們當然可以用「樹」的方式來訪問——可惜我們只有順序訪問的記憶體。
程式＝資料＋演算法
——這個是面向過程時代的事。
程式＝資料＋演算法＋方法
——在oo時代，我們看到了事件驅動和模型驅動，所以出現了「方法」問題。
soul：我的經驗是：總體結構→物件導向，關係→資料結構，實現→演算法。
看來我們對物件導向的認識還是比較一致的。
我第一次提到我對程式的理解是「程式=資料+演算法+方法」，就是在這一次與soul的交談之中。在這次的交談中的思考仍有些不成熟的地方，例如我完全忽略了在面向過程時代的「方法」問題。實際上面向過程開發也是有相關的「方法」的。
所謂「面向過程開發」，其實是對「結構化程式設計」在**階段的乙個習慣性的說法。而我忽略了這個階段的「方法」的根本原因，是即使沒有任何「方法」的存在，只需要「單元（unit）」和「模組（module）」的概念，在面向過程時代，一樣可以做出任意大型的程式。在那個時代，「方法」問題並不會像鼻子一樣凸顯在每乙個程式設計師的面前。
在面向過程開發中，「過程（procedure）」是由cpu提供的，「單元（unit）」則是編譯器提供的（機制）。程式設計師無須（至少不是必須）再造就什麼「方法」，就可以進行愚公式的開發工作了。
如果不出現物件導向的話，這樣偉大的工程可能還要再幹一百年……
而與「物件導向」是否出現完全無關的乙個東西，卻因為「過程」和「單元」的出現而出現了。這就是「工程（engineering）」。
【愚公移山記：智叟商晉】
京城初將所學的技法投入到工程中去，提高了工效，公輸一家很開心。端木啟則把粗鐵變成了好馬，進而居奇得利，也很開心。
收錄的章節會在不斷的充實自己之中慢慢的理解，我不求急功近利，只求可以有些許進步。
待續
讀《大道至簡 軟體工程實踐者的思想》有感
第一次讀完這本書時，感覺深深地松了一口氣，因為從頭讀到尾讀懂的地方很少，糊里糊塗，沒能進行好好地思考。前幾天，在電腦上找到這本書又讀了一次，再加上課堂上老師的一些講解，才稍微有點懂了。這本書的作者匠心獨運，語言平實易懂，形象生動。向初學者介紹了什麼是程式設計，向愚公式碼農介紹了什麼是方法，向頭重手亂...
讀《大道至簡》 軟體工程實踐者的思想有感
初聞其名，大道至簡 大多人都會覺得這是一本滿腹人生哲理的書籍，作者洋洋灑灑的談論大道理，其實不然，作者以古典文化為引，以作者的所思所想為線，啟蒙了我作為乙個軟體工程初學者的實踐思想。愚公雖愚，卻向我們展示了如何完成乙個看似龐大的工程，那就是一步一步的分而治之，回想自己大一的學習生活，確實遇到過比較繁...
讀《大道至簡 軟體工程實踐者的思想》有感
大道至簡 這本書篇幅較短，一百多頁，不像那種程式設計大書一樣讀起來很費事。總體來說比較通俗易懂，在說明自己觀點的同時引用了許多古代的例子，並且書中詳細的闡明了作者對軟體工程的看法以及一些獨到的見解，書中也有很多的專業術語我看不懂，但其中的思想值得我學習，尤其是像我這樣學軟體工程的學生更是值得借鑑。大...