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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

比如有人說，Linus炮轟面向對象，是因為他和應用程序員面對的領域不同。這話很惡心。

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

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

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

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

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

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

總結

以上是生活随笔為你收集整理的关于程序组织和组织技巧的学习的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。