關於程式組織和組織技巧的學習

來部落格園有不少日子了，園子一個不變的主題就是捯飭這些。說點我的看法。

本來想正經寫文發到首頁的。不過算了，目前害怕在這類問題上交流討論。且我不看好這個討論對我自己和其他人的價值。

實際上如何組織程式應該從需求出發，而根本不像那些設計指南裡說的應該這樣應該那樣，而不顧前提。這個前提的關鍵在於你的使用者是誰。對於組織這項工作及其結果來說，有倆，一個是咱們自己，一個是其它程式員。

而在應用開發這個水平上，真正為別人設計的時候並不多，而且不具有商業中介軟體那麼重要的意義。

無論是沉浸在物件導向，還是一個非常樸素的程式員，只要我們認真負責，總能設計出不錯的介面甚至架構。麵條式代碼的錯誤不在於不熟悉某某具體的原則，在於一個人的責任心，這是很多人沒有明白的事情。

我逐漸知道，即便一些表現的很熱情的學習者，也不過是認為懂得物件導向能更好的找工作（或者是類似潛意識的驅動）。所以我對討論這些話題，逐漸的從積极參与變成了一個沉默者。因為最終這種討論變得不擊中實質，沒有任何指導意義。

劃定使用者，從需求出發，經過一兩個回合的實踐，總能找到*目前*較好的一個設計（而不必學習思考太多預備知識）。這無需由任何方法論支撐，它們也無力承受。至於具體的工具（語言或架構），僅僅是為了加快工作速度用的。

不同的設施會有不同的加速指數，所以對工具的廣泛瞭解還是需要的；但必須僅僅從實在方便性上而不是陽春白雪上看這些問題。

我也不贊成通過成熟架構來肯定自己的學習並得出結論的做法。尤其是對於有些程式員，他面臨的情景和作者相差太多。

比如ASP.NET這類樣的架構和帶有的庫，有很多設計上的缺點，水平不夠的學習者將會很長時間的東施效顰。即便是很多好的決定，僅僅是設計者考慮他認為的最大一部分使用者共同的需求才導致的。

不瞭解這些瞎印證，有不少得出錯誤結論的幾率。而哪怕只有1%的錯誤，也會影響我們未來的判斷。更何況即便找對了路子又能怎樣呢？馬後炮的人總是馬後炮，因為他已經習慣了這個模式；解釋正確並不意味著學到了真功夫。

關於對架構的學習，我倒是有一個看法，不妨常常問問自己一些問題。比如“把ASP.NET放到Python的世界，會有人用嗎？”

當一個人的選擇有限，他就希望這個選擇是合理的；那些明顯認為不好的，也感覺“無傷大雅”或者認為是Trade Off。當我們跳開這個圈子，看看其它人的選擇，最終也許我們就會基於比如Handler自己開發一個東西來用。

就ASP.NET這個例子，雖然沒法發放調查問卷，但無論是WebForm還是當前的MVC，恐怕都有不小的幾率得到反對的答案。接下來問問為什麼、會和不會的都是哪些使用者；於是就知道這個東西不好在哪裡，或者好在哪裡。

有了這些素材，就可以判斷自己是不是某個東西的目標使用者；如果在很大程度上你和不選擇它的那些人有共鳴，它就不適合你了。這時候很多特性，到底應該怎麼評價也就變得客觀；而不是在很小的一畝三分地上，“哦，這個設計應該是那麼考慮的”。

所以你看，這些問題的答案，最終都會和使用者是誰，他們（包括我們自己）想要怎麼樣相關的。

回頭說說大多數人所謂的設計，也就是怎麼組織程式。有了上面的討論，不難看出很多看似有價值的文章說的都是廢話。我們總能找出不錯的理由支援這樣或者那樣的設計（當然如果這個設計還能被肯定或部分肯定，這也說明它的作者是有一定責任心的）。

但我認為，過了初學者的階段，當我們碰到真正複雜的問題時，這種學習就變得沒有意義甚至拖後腿了。你不能假象你在設計ASP.NET，因為你確實不是。基於其作者的視角和理由去設計自己的東西，最終只能是繡花枕頭。畢竟，使用者群和問題規模根本就不一樣。

每件多餘的東西都會付出代價，請注意這一點。奧卡姆剃刀不僅僅用在物件導向內部，對是不是採用某理念照樣適用。大家都很希望自己是個了不起的設計師，但什麼時候也不能依賴於遐想。象“某牛那樣做決定”這是好的，但是往往我們沒有看到“某牛在我們這個位置上會怎麼決定”。

問問自己，我現在掌握了這麼多，我能設計出ASP.NET嗎？如果不能，問問自己為什麼。我個人的一個答案是，這往往是因為我們沒學會正確的方法：即僅通過需求做決定，而不是無謂的琢磨先驗知識。

不想當將軍計程車兵不是好士兵；但是不根據形勢而根據內心期許做眼前決定的一定不能當將軍。

最後從應用和底層的關係再來看看相同的問題。

想作為一個純粹的程式員變得更強，就必須認識到真實狀況。實際上底層程式員和應用程式員面對的複雜度不是一個層級的。這一點上不能自己騙自己，因為使用者群及需要考慮的各方面需求及其數量級都是不同的。

當然，你可以拿一個好的應用程式員去鄙視一個差的底層程式員，但這種自我（群體）肯定，是不講健康的。當我們認為我們和底層程式員一樣棒，甚至和Linus一樣棒，我們就會忽略這類大牛不在乎的東西；並以“純粹的程式員”自豪。

可事實上，很多底層程式員關心的東西我們卻也沒關心（根本沒機會），最終只好搞些徒耗精力的學問求一個充實感。

就我看，作為一個應用程式員，如果說和底層程式員不分高下的話，我們就應該關心很多其它的事情。這些事情是什麼，是和你的工作角色相關的。也許是業務也許是其它的，總之你得去挖掘下遊的需求（又回到這上面來了）。

甚至我們就不能把自己當作程式員，而是作為一個領域專家，熟悉業務以及業務如何多快好省的實現就夠了。

這兩個領域的差別帶來的區別，也有很多值得玩味的內容。

比如有人說，Linus炮轟物件導向，是因為他和應用程式員面對的領域不同。這話很噁心。

如果一個程式員看不出不同層次不同領域的共性，他也沒有真正理解物件導向。但看出來了會如何選擇呢？事實上之所以很多方法又漂亮又好使，不過是因為這些方法絕大多數時候只能運用在簡單的問題上罷了。

任何方法運用在簡單問題上都能找出漂亮的方案。也很容易觀察到，除了少數領域，方法論鬧得最凶的都是題目相對簡單（也許很“進階”）的應用或中介軟體社區；而大多數熱火朝天的學習、實踐者又偏偏都不是幹少數領域的。

為什嗎？因為方法論好的一面容易表現出來，自然就吸引人。可最終因為簡單，所以其它方法也行得通；這樣這些方法論卻又不能一統天下。這樣它們在福士社區裡就表現出一種尷尬：你可以在那津津有味的探討擴充、重用及其背後的原則，可是難題還是難題，容易的還是容易的。

這就說明，我們每個人碰到的問題，解決之道根本不在我們到底掌握了什麼沒掌握什麼。這不是說某方法論就不能使了，給自己的工具箱添加一些新東西是必要的；只是我們必須避免增加不必要的冗餘。

要做到這一點就必須“惰性”一點，只有明顯感覺到優勢時才使用更多的工具。這樣，我們就在多了一種工具的同時，避免了背上Linus所說的“精神包袱”。也許我們應該有一張表，這張表是通過“需求->實踐->經驗->帶有條件的結論”得到的。它記錄了工具和情境的一些聯絡。

而過多的討論和研習，就相當於：沒有正確的、*真正*問題前，我們就回答了它。