談談技術原則，技術學習方法，代碼閱讀及其它(正文)

這篇文章是前一陣在水木BBS上和別人討論中偶自己發言的摘編，是偶這幾年開發過程完全經驗式的總結。完全個人經驗，供批判。


一、選用技術的原則

比較規范的軟件開發過程要到有限的幾個公司才能學到。偶現在所采用的方法都是圡方法，主程序員，測試驅動，文檔和代碼寫在一起，原型。但基本上堅持幾個原則：

在工作上以實用為主導，哪個實用學哪個，要以最小的努力獲取最大的成效。

偶寫過的第一個實用程序是把一個法律光盤導入到數據庫中，光盤源文件格式需要分析。數據大概幾萬條。一種方法是寫程序直接導入，另一種方法是寫一個界面，手工導入。偶選擇的是后者。程序界面如下：有一個文本框，有一個大按鈕，按鈕有一本書那么大，這樣設計的原則是讓閉著眼睛就能夠點中。讓一個會灌水的哥們，ctrl + c, ctrl + v，不停的灌。文本貼過去，自動解析，放入數據庫。左手alt + tab ctrl + c/v， 右手點鼠標，這樣有節奏的運動。很快，幾個小時就把數據弄完了。最初設計的一個文本框，一個按鈕，很pp，但是老點不中。隨即偶才把那個按鈕做成老大的，就這一個改變，生產力提高了1倍以上。

工作，就要堅持這樣的原則。要能夠分辨出價值，找能夠提高價值的去做。即使這樣違背一般規律，違背技術教條。

學習上以簡單，核心的東東為主。可學可不學的不要學。復雜的東西除非你想要成為這方面的專家，就不要學。偶還是舉自己的一個例子，前一陣做GIS有需求，具體實現偶負責。預算很少。偶就定了開源GIS軟件這條路，本來想用C#的，但沒有好用的開源GIS軟件，偶決定用java寫。偶手下還沒會java的。偶選擇了一個開源lib，讓一個哥們運行一個Demo，然后讓他從那個Demo的main函數畫函數調用圖一直畫到數據庫調用。偶呢，跑去看GIS規范，然后他的圖，結合偶的規范知識，很快就知道這個軟件中間分了多少層，每個層每個接口是干什么用的，怎么調用。這個軟件的優點缺點。然后體系結構，設計就出來了，然后2個java程序員，很快就做出來了。

二、技術學習的技巧

借著上面例子說說學習軟件的技巧

要學一個東西，要學習該東西的兩類知識：結構和細節。

結構性的東東非常重要.學習結構，就可以開始干事了，學習細節，能夠把這件事情干好。結構不清楚，細節再好都不算了解。結構很簡單，就是縱，橫兩條線。縱的來說，就是一個程序的執行，你得知道哪一步在做什么。以ASP.Net來說，就是從收到Request到返回一個頁面，中間的調用過程，這是主線，再進一步，程序的加載->接收Request(->緩存，Session機制）->返回一個Page，這個過程清楚，Asp.Net也就差不多了。縱向一般是通過接口調用的，看源代碼很快就可以搞定。

橫向就是看看重要的接口，重要的抽象類有哪些實現，知道哪個實現用于什么地方，有什么優缺點。那么就算在結構上學好了。剩下的就是細節問題了。細節問題熟練自然很好，不熟練google都能google到，只是要花很多時間。這樣學習我覺得是最有效的學習，不必去跟蹤技術前沿，當一個技術在你眼前你很快就可以看出它的骨架，優點缺點，性能，至少能估計到大致的范圍。這樣慢慢培養對一個技術的悟性，做到舉重若輕，知道什么地方可能有陷阱，什么地方可能有創新。把握住重點和脈絡。

細節上就是不斷實踐，不斷重構。一個有用的軟件，不斷提出更高的要求，不斷重構，用不了幾遍，幾種重要的設計模式就了熟于心了。單為學習模式而去學習模式是不可取的。每個模式都針對一定的問題。深入理解這些問題才是學習的關鍵！技術是多種多樣的，是變化非常快的，但是技術所要解決的問題卻并不多。

從架構級別來說，所面臨的問題主要有：（1）解決復雜性－－如何把復雜變得簡單？這里的觀點就是封裝，OO是一種封裝，還有別的封裝方式。《重構》書中講了很關鍵的一點，就是要使你的類名，方法名能清晰表明它的身份和功能。（2）解決程序演化與擴展的問題－－組合優先繼承，怎么暴露API，怎么寫文檔，總之，讓程序演化與擴展越簡單越好；（3）性能問題－－80/20原則，性能測試怎么測試，怎么評估，不同使用場景中的性能，緩存機制；（4）功能問題－－主要功能總得實現吧，這個和業務有關；（5）易用性；（6）縱向擴展，橫向擴展，并發......（7）自己開發還是采用第三方插件還是外包以及選擇問題。

具體的學習，偶推薦問題導向，案例為基礎的學習，不要拘泥于語言，要學習能學習到的最好的東東。比如，性能的關鍵在調度，這時候可以看看資源調度模式，hibernate算是把資源調度玩到了極致。基于事件的調度（如.net中的web cache），進程調度，線程調度，工作流，這些都算是行為調度，要是把這些東東融會貫通，掌握每一種實現的優點缺點。那么軟件設計中所有和時間、并發、資源相關的東東都不在話下了。行為調度可以看看.net 中的cache實現，找一個工作流軟件看看，找找幾個線程框架看看，看看幾個典型操作系統的進程調度機制。

具體到實現上，所面臨的問題無非是：

（1）對象的創建及銷毀；（2）對象的封裝和繼承體系；（3）對象的粒度和語義劃分；（4）對象的復用；（5）對象的測試；（6）對象的持久化；（7）具體的API暴露；（8）常用Collections；（9）算法問題；（10）性能問題；（11）回調；（12）消滅語義溝；（13）我想要和你一起變懶......；（14）我能采用哪些API（15）對象的管理；（16）異步調用；（17）遠程調用

具體問題不多，每一個問題又有一些使用場景，每一個場景可以采用幾種模式實現，每種模式有哪些變種，模式和變種有哪些優點缺點......要了解這些可不容易拿對象的創建來說吧，有這些情況：

（1）一錘子買賣：直接new就行了

（2）你是我的唯一：單例

（3）千年等一回：對象池，原型，緩存

（4）似曾相識燕歸來：享元

（5）我看過GOF：工廠，抽象工廠

（6）不要問我從哪里來：IOC

具體到實現中，細節也很重要。但所謂的細節，涉及的方面扯過來扯過去就那幾點。再向上一級別的實現，無非就是UI，業務，數據接入這三層，再加入一個集成層也可以。UI無非就是那幾種模式，用的多無非就是以模板為主的和以控制為主的，業務上耷拉耷拉還有一些主要的模式，數據接入主要就是那三種模式。ADO.Net細分下去也有兩種使用模式。數據庫有要錢的有不要錢的有進程外的有進程內的有復雜的有簡單的。文件有普通文件有帶索引的文件有html,xml等有特定格式的文件，碰上這些怎么操作。

三、對MSF的一點心得

軟件過程控制方面主要也是解決一些問題。代碼、Bug，需求，文檔，交流，發布，風險.偶從MSF中學到的唯一的東東是Tradeoff（權衡/取舍）。MSF的最有價值的思想應該就是取舍。要達到什么目的，給定什么，選擇什么，放棄什么。偶兩年前對MSF有過很長一段時間研究，寫過一篇Case（放在網上某庫，看要花錢買，嘿嘿）。以前軟件主要用于工業用途，穩定性很重要，程序老掛可不得了。90年代初軟件應用從工業領域過渡到普通應用領域，功能和可獲得性變得很重要，穩定性大家不看重，Windows脫穎而出。MSF最初版本就是那幾年成型的，從那開始，微軟的Trade-off基本上是進度優先于功能，功能優先于穩定性，安全性。最近微軟的Trade-off變了，穩定性，安全性排的比較靠前。當年背景是微軟開發隊伍變大了，開發管理有些混亂。于是微軟組織了一批高手，總結開發過程中的經驗，形成MSF最初版。隨著時代發展，MSF逐漸演化成現在的版本。當前的MSF被微軟當作一個過程方法，向外界推廣。偶的看法是，MSF首先是微軟自己成功經驗的總結，其次才是一種可參考的過程方法。MSF是教怎么成功的開發軟件產品，而不是怎么達到項目需求。并且，MSF不是普適的。有一本書，叫做《自適應軟件開發》，那本書實際上是MSF的最佳詮釋，只有在什么樣的組織里應用這種方法那本書分析得很透徹。

四、四個方法

歸納起來，大概偶覺得有用的方法就是這四種：

拜師學藝：以案例為主的學習，第一手資料最可靠。多看源碼，多看現有方案。沒事多寫代碼。

左右互博：同樣的問題，多學習多研究幾種解決方案。只學習一種容易障目，不通過比較，不能清楚某種軟件，某種解決方案，某種設計模式的優缺點。在時間可能的情況下，多試一試不同的解決方法。

庖丁解牛：拿到東西就橫豎兩刀，分成橫向的肋骨和縱向的脊椎，剩下的都是皮肉。對于絕大多數OO軟件都實用。不實用不是你的問題，是軟件寫的有問題。對于自己寫的軟件，沒事也可以試一試劈一下，軟件沒嘩啦嘩啦散開證明寫的有問題。

吸星大法：任何軟件都有歷史問題，任何方法都有歷史問題。軟件要兼容呀，公司要宣傳呀，所以很多東東不是它表面的那樣。.net對底層綁定的那么厲害，這些都是歷史遺留問題。所以，學習一個東東，最好向前翻幾個版本，看看在該軟件演化過程中發生了哪些故事，這些故事的背景是什么，每個故事都意味著一些trade-off，從中間可以學習很多軟件設計知識，這樣學習，相當于把別人的實戰經驗據為己有，多爽啊。這樣做的另一個意義是可以培養自己對技術的預測能力，比別人多看一步就是一個很大的優勢。

五、閱讀代碼的技巧

對OO來說,一般一個500~1000個類的庫/軟件,主要的類或接口大概在10~20個左右,一般來說,這些類構成一個層次關系.每一層,這些類或接口會有一大堆子類/實現.大概在數百個左右.剩下的類基本上都是工具類,輔助類,獲取特定資源的類.第一步應該是找到這些主要的類和接口,找出主要的調用過程,清楚這個過程.這樣,差不多就明白這個軟件/庫是怎么工作的了.第二步,是看這些主要類,接口的繼承/實現,這樣可以了解這個軟件/庫可以做什么,怎么擴展.這樣,一個數M代碼量的東東,可以在2~3天的時間里把它弄清楚.

閱讀代碼的主要難度就是代碼量太大,但是OO極大的減低了代碼閱讀的難度,好的OO軟件一看見namespace, 類名,方法名就知道干什么的(在閱讀較多代碼后就能形成這種直覺)就不必要去閱讀具體的代碼了.閱讀的難度通過工具能降低很多:通過逆向工程獲得類圖和主要調用過程的序列圖,通過這兩圖的閱讀,就差不多了.Ndoc，Visio，doxygen，甚至word都是有用的輔助工具。實在不能明白的就看代碼.軟件的骨架大概就是這些,除此之外,每個軟件可能會涉及到一兩種核心的算法或它獨特的數據抽象(數據結構),實現某種規范或者某種已知的算法,這時候看看這些規范或已知的算法,結合代碼很快就理解了.此外,還有一些細節性知識分散在那些輔助類里面,了解骨架后,對這些東東大概有個底了,但不能準確的確定.這時候google,看看大家怎么用的,有什么注意事項.閱讀代碼如果順序不對,第一頭就扎進這些細節,那就完了.對主要流程的掌握和對層次的掌握是第一位的.對設計模式的了解還是其次. 還有很多非OO軟件,采用這種方法,也是很容易讀的.比如,閱讀協議棧代碼,跟著一個包走一圈.在企業中,圍著一個訂單走一圈.這些都是非常有效的處理復雜系統的方法.在OO中嘛,就是跟著方法走一圈.選中一個方法,跟著它走一圈.這個方法選的好的話,這一圈基本上就把這個軟件/庫轉個差不多了.在這個過程中可能要碰到幾十個對象,上百個方法調用,搞懂了,就差不多了.但是,閱讀主線不能亂.

轉載于:https://www.cnblogs.com/svennee/p/4290368.html

總結

以上是生活随笔為你收集整理的谈谈选用技术的原则，技术学习方法技巧，阅读代码的技巧及其它 MSF的一点心得...的全部內容，希望文章能夠幫你解決所遇到的問題。

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