前幾天一個朋友提到我的部落格中空空如也。確實，到園子裡也有段日子了。確實也該放點東西了。要不也太對不起DUDU了。這幾天又比較清閑,將讀書筆記及自己的心得記錄下來
McConnell 大俠說如果設計能實現如下目標，那麼就是非常好的設計了。
一:
最少的複雜度
簡單來說，就是要易於理解。McConnell特別還指出了要避免“聰明的”設計。 另外我們在設計某處的時候要能夠安全的忽視其它部分
才算合格。
二:
易於維護
這點主要是為做維護工作的程式員著想的，不過我們寫的代碼，大多數時候做維護的還是自己吧。如果你能一看函數名或代碼就能瞭解它們的作用的話也就OK了。
三：
松耦合
作為軟體設計的軍規之一。各部分的關聯越少意味著你在測試，整合，維護的時候可以輕鬆不止一點點。
四：
可擴充
套用句"古話":做軟體唯一就是變化。如果你的作品是不可適用變化的話，基本上就可以貼上不合格的標籤了。也許你會說我改代碼就可以了。當然可能要修改代碼，但物件導向的設計原則裡有條，類是可擴充還不可以修改的。擴充一般是通過繼承來是想的。而修改特別是介面往往會引起許多莫名其妙的問題的。總之：你在給自己軟體加功能的時候不要對底層甚至架構大動幹戈就對了。
五：
高扇入
扇入？扇入是什麼東東？我以前還真不知道（我專業是物理學，半路出家寫代碼的！）仔細一看原來就是指被其它類或方法引用。那高扇入也就是說你這個類/方法...被很多其它類引用了。也就是利用率很高了。按照我的想法如果段代碼我連寫了三次,我就會把它單獨作為一個方法或類
六:
低扇出
扇出自然就是引用其它類或方法了.按Bob大叔的說法，扇出越高，類就越不穩定，因為任何一個引用對象出問題了，這個類也就會出問題。另外McConnell 說了：引用超過約七個就算高扇出了.
七：
可移植
這點我覺得大家設計的時候還是得MVC啊。要不哪天客戶要求你從B/S轉為C/S你就有的忙了。這點我覺得喜歡在頁面寫邏輯的兄弟得特別注意了。雖然看起來沒有雙擊就寫代碼那麼爽，可實際還是能省不少事的。
八：
精簡性
能少不多，你不能覺得原廠模式爽，就有事沒事都加上，這是不對的。另外寫《移山之道》的鄒欣也說過,程式員不能覺某個功能可能有用你就加上.因為這會增加測試等方面的任務,而且程式員認為使用者會喜歡的往往使用者偏不喜歡
九：
層次性
層次性，最常見的就是大家說的三層架構了。好處有幾個，你換了資料庫而不必管上層。另還有一個就是更好的分工。經驗不足的小夥子寫的初級代碼可以禁閉起來。以後想重構就重構，想換掉就換掉。也就減少了複雜度了。
十：
使用標準技術
這樣會給大家熟悉的感覺.如使用相同的架構,代碼風格應該使用相同的標準，可以套用設計模式的就套用一下咯，不要自己整個新的花樣出來，畢竟看熟悉的東西容易理解。
代碼大全上就這麼十點，我覺得還可以加上一點，
十一：
高內聚
也就是說一個類特別是一個方法應該專註於一件事。比如你的
I男朋友可以有
陪女朋友()方法，但就不可以有
寫代碼()方法。因為
寫代碼()方法是
I程式員介面才有的.
而在
陪女朋友()方法中你不可以順便就將
花錢這個操作加在裡面,因為偶爾有一次陪女友是陪她在家
看電視的,自然也就不需
花錢了.
