《程序員修鍊之道》筆記

*續 第五章彎曲，或折斷

4 它只是試圖

a) 以一個電子表格應用舉例，除了顯示錶格，還要能把數值顯示為柱狀圖，還有總計功能。實現的大概過程為：首先創建一個模型（數據自身），以及用於對其操縱的常用操作；然後創建不同的視圖，以不同方式顯示數據，作為表格、柱狀圖、總計框，每個視圖都有自己的控制器。

b) 讓視圖與模型分離，可以用低廉的代價為自己換來許多靈活性，MVC是最為重要的維護可撤銷性的途徑之一。

c) MVC

模型，表示目標對象的抽象數據模型。模型對任何視圖或控制器都沒有直接的了解

視圖。解釋模型的方式。它訂閱模型中的變化和來自控制器的邏輯事件。

控制器。控制視圖、並向模型提供新數據的途徑。它既向模型、也向視圖發布事件。

（但MVC在Web應用中，受限於HTTP連接的特性，控制器無法向視圖發布事件。）

d) 除了一般意義上的MVC，我們還可以超越GUI，組成模型-查看器網路。查看器對象可以是更高級對象的模型，而後者自己可能又是不同的格式化查看器的模型。

5 黑板

a) 關於黑板方法，可以用偵探的工作來舉例。每個偵探都隨時可以在黑板上增加各種事實、證人陳述等，以促成發現某些關聯，最終破案。黑板方法有一些關鍵特性：

沒有偵探需要知道其他任何偵探的存在

偵探可能接受過不同的訓練，具有不同程度的教育背景和專業經驗。但他們都渴望破案，這就是全部的共同點。

在這個過程中，不同偵探可能來來去去，並且工作班次也可能不同。

對放在黑板上的內容沒有什麼限制，可以是圖片、判斷、物證等。

基於計算機的黑板系統最初是為在人工智慧中的應用而發明的，解決的問題大而複雜，如語言識別、推理系統等。現代的分散式類黑板（blackboard-like）系統有JavaSpaces和T Spaces等。

第六章 當你編碼時

傳統看法認為，項目一旦進入編碼階段，工作主要就是機械地把設計轉換為可執行語句。但作者認為，這種態度是許多程序醜陋、低效、結構糟糕、不可維護和完全錯誤的最大原因。

編程不是機械工作。相反，編程時每一分鐘都需要作出決策，如果要讓程序享有長久、無誤和富有生產力的「一生」，就必須對這些決策進行仔細地思考和判斷。

不主動思考他們的代碼的開發者是在靠巧合編程。

1. 靠巧合編程

a) 士兵起初沒有探測到地雷，但這不過是僥倖，但他由此得出了錯誤的結論，認為這裡沒有地雷，最終導致了災難性的結果。作為開發者，我們也工作在雷區中，應該保持警惕，不要得出錯誤的結論。我們應該避免靠巧合編程——依靠運氣和偶然的成功——而要深思熟慮地編程。

b) 實現的偶然。實現的偶然是那些只是因為代碼現在的編寫方式才得以發生的事情，你最後會依靠沒有計入文檔的錯誤或是邊界條件。

雖然靠巧合編程，但代碼已經能工作，但這種做法很危險。因為它也許不是真的能工作，只是看起來能工作；而且我們依靠的邊界條件也許只是一個偶然。在不同的情形下（比如不同的屏幕解析度），它的表現可能就會不同；此外沒有計入文檔的行為可能會隨著庫的下一次發布而變化；而多餘的和不必要的調用也會使你的代碼變慢；多餘的調用還會有引入新bug的風險。

對於你編寫給別人調用的代碼，要進行良好的模塊化以及把實現隱藏在撰寫了良好文檔的小介面之後。

對於你調用的常式，要只依靠計入了文檔的行為。

c) 語境的偶然。比如GUI，是否在依靠說英語的用戶、有文化的用戶，或者別的什麼沒有保證的東西。

d) 項目可以在所有層面上讓人誤入歧途，從生成需求直到測試。人們常常在頭腦中帶著許多假定，但這些假定很少被計入文檔，而且在不同的開發者之間常常是衝突的。所以最好不要假定，而是要證明。

e) 怎樣深思熟慮地編程

總是意識到你在做什麼，不要做溫水中的青蛙。

不要盲目地編程，試圖構建你不完全理解的應用，或是使用你不熟悉的技術，就是希望自己被巧合誤導。

一定要按照計劃行事。

依靠可靠的事物，而不是巧合或假定。如果你不得不依靠假定，就依靠最壞的假定。

為你的假定建立文檔。這有助於你澄清頭腦中的假定，並把它們傳達給別人。

不要只是測試你的代碼，還要測試你的假定。不要猜測，要實際嘗試它。編寫斷言測試你的假定。

為你的工作劃分優先順序，把時間花在重要的方面。

不要做歷史的奴隸，不要讓已有的代碼支配將來的代碼，隨時準備好就進行重構。

下次如果有什麼東西看起來能工作，而你卻不知道為什麼時，要確定它不是巧合。