|
級別: 初級
林星, 項目經(jīng)理
2003 年 12 月 01 日
面向?qū)ο蟀l(fā)展到今天，已經(jīng)出現(xiàn)了許許多多優(yōu)秀的實踐、方法和技術(shù)。很多的技術(shù)都能夠有效的提高軟件質(zhì)量，而要用好這些技術(shù)，我們需要從過程和管理的角度來看待它們，而不是為了使用技術(shù)而使用技術(shù)。此系列文章包括：代碼是核心、 案例實戰(zhàn)（上）、 案例實戰(zhàn)（下）、 重用、 優(yōu)化代碼的組織、 針對契約設(shè)計、 業(yè)務(wù)建模。
在一個有效的組織中，必定擁有杰出的一線人才。軟件設(shè)計也是一樣的，一線人才的素質(zhì)決定了軟件的質(zhì)量。從敏捷的觀點來看，代碼是檢驗軟件過程是否有效的最終標(biāo)準(zhǔn)。目前為止，以及在短時間的未來，我們都不太可能完全脫離代碼進(jìn)行軟件設(shè)計。所以，軟件過程中的任何一個活動都是為了能夠產(chǎn)出優(yōu)秀的代碼。所以，代碼才是核心。
1. 代碼是軟件開發(fā)的基礎(chǔ)
編碼是軟件開發(fā)過程中最基本、最底層的技藝，然而也是最重要的技藝。任何一個領(lǐng)域的專家都需要花費大量的時間來進(jìn)行基本技藝的鍛煉，木匠需要花費大量的時間來鍛煉他們對各種工具的掌握，廚師則需要練習(xí)刀工和火候。程序員也是一樣的，對我們來說，語言的各種特性必須要了然于胸。而對軟件的管理也需要從代碼做起。
從2000年到現(xiàn)在，國內(nèi)興起了一股軟件工程熱，需求管理、配置管理、甚至CMM。面對紛至沓來的各種方法學(xué)、UML、OOA，大家似乎已經(jīng)熱衷于這些概念本身了，卻往往忽略了軟件開發(fā)中最基本的元素－代碼。在和很多軟件組織的接觸過程中，我們認(rèn)為大多數(shù)組織急切需要的并不是這些工程理論，不是說這些理論不重要，而是這些組織的癥結(jié)不在于此。很多的組織連代碼的質(zhì)量都管理不好，又何談其它呢？代碼管理是基礎(chǔ)的基礎(chǔ)，從管理的角度上來看，任何一個組織的管理都需要一個從上至下的管理過程，有基層的管理人員，也有高層的管理人員。對代碼的管理就是軟件開發(fā)中的基層管理，它起到的作用就是能夠把需求、設(shè)計的思路貫徹到最終的代碼中。
"管理無大事"。對軟件的管理也是一樣，大部分的問題都是由于很小的原因引起的。例如，一個產(chǎn)品如果后期在debug上花費了大量的時間，那么，這種現(xiàn)象是由于什么原因引起的？一種可能的原因是前期的代碼設(shè)計中對代碼質(zhì)量的把握不嚴(yán)。每一次代碼功能的演化并不會產(chǎn)生太多的問題，但是當(dāng)代碼累積越來越多的時候，問題也就慢慢出現(xiàn)了。那么如何解決呢？可以加強(qiáng)QA的力量，也可以引入復(fù)審，還可以引入單元測試。總之，要有一種方法對代碼進(jìn)行控制。
軟件的開發(fā)過程就象是一部精密的機(jī)器，任何一個環(huán)節(jié)的變化，都會對其它的環(huán)節(jié)產(chǎn)生影響。把軟件過程按照瀑布的形式進(jìn)行劃分是一種分解的處理思路，但同時我們還應(yīng)該看到不同活動之間的相互影響。軟件開發(fā)中的生命周期模型也是一個層次模型，從業(yè)務(wù)建模一直到軟件實現(xiàn)，需要跨越數(shù)個層次，同樣會出現(xiàn)執(zhí)行不力的情況，例如，代碼設(shè)計偏離需求、偏離設(shè)計的情況比比皆是。
如何避免這種情況呢？這就需要我們從源代碼的角度，反思其上游的實踐活動，是否足以約束代碼設(shè)計？就拿XP來說，他解決這個問題的方式是盡快的進(jìn)入代碼開發(fā)階段，從代碼開發(fā)中發(fā)現(xiàn)問題，并在下一輪的開發(fā)中解決。這種思路是正確的，但XP畢竟是方法論，他不會告訴你過于細(xì)節(jié)的東西，盡管XP已經(jīng)提供了大量面向代碼的實踐。因為方法論的抽象級別比較高，使得他必須舍棄部分的細(xì)節(jié)。而這篇文章告訴你的，就是這些細(xì)節(jié)。就像我們在下一節(jié)中討論的例子，需要在代碼中加入對異常的處理，那么，異常的源頭在哪里呢？是需求，在需求中，我們發(fā)現(xiàn)了一些業(yè)務(wù)的非正常的處理序列，發(fā)現(xiàn)了一些業(yè)務(wù)實體的限制性的要求，所以在代碼實現(xiàn)中，就需要有相應(yīng)的異常處理。在例如，一個優(yōu)秀的異常處理，還需要讓客戶端程序員了解可能發(fā)生的異常，以保證不同代碼間正確的集成。
2. 面向?qū)ο蟮拇a
面向?qū)ο蟮拇a已經(jīng)在現(xiàn)在的軟件開發(fā)中占據(jù)了主流的位置，面向?qū)ο蟮乃悸芬灿衅鋬?yōu)勢所在，就像后文所討論的，面向?qū)ο蟠a有著非面向?qū)ο蟠a的很多優(yōu)勢，而軟件業(yè)中很多新的思潮的產(chǎn)生，也都是基于面向?qū)ο笳Z言的，所以我們關(guān)注的代碼將是面向?qū)ο蟠a。
面向?qū)ο蟮乃枷雭碜杂诔橄髷?shù)據(jù)類型。對于面向?qū)ο髞碚f，它最重要的改進(jìn)就是把世間萬物都描述為對象，而類則描述了同一種對象的特征，而不是像傳統(tǒng)的開發(fā)方法那樣，按照機(jī)器指令的執(zhí)行順序來進(jìn)行設(shè)計。當(dāng)然，面向?qū)ο蟠a最終仍然是要按照時序來執(zhí)行的，但是從程序員的角度看來，面向?qū)ο蟠a更側(cè)重于對象之間的交互，多個對象各司其職，相互協(xié)作以完成目標(biāo)。而面向?qū)ο蠹夹g(shù)的發(fā)展，也是朝著更加貼近我們世界觀的方向發(fā)展。從這點來看，有人說完全沒有程序設(shè)計經(jīng)驗的人學(xué)習(xí)面向?qū)ο罂赡軙拥娜菀祝驗樗恍枰獜脑鹊臅r序程序的桎梏中擺脫出來，但這未必是事實。面向?qū)ο鬀Q不是一種簡單的程序設(shè)計思路。這是我們的觀點，也會在下文中反復(fù)的論證。
和所有的職業(yè)一樣，程序員，或者是面向?qū)ο蟪绦騿T，始終堅持的一點就是嚴(yán)謹(jǐn)。你會看到各種各樣優(yōu)秀的代碼，但那決不是一次能夠?qū)懗傻?，要不斷的嘗試，不斷的改進(jìn)。為什么重構(gòu)和測試優(yōu)先是敏捷方法中很重要的一項實踐？因為程序員不是神，他們需要慢慢改進(jìn)他們的代碼。雖然羅馬不是一天能夠建成的，但是在編寫面向?qū)ο蟠a的過程中，有一些實踐是需要堅持的，它體現(xiàn)了我們所說的嚴(yán)謹(jǐn)。
3. 編寫并管理面向?qū)ο蟮拇a
編寫優(yōu)秀的面向?qū)ο蟠a并不是一件容易的事情，優(yōu)秀的OO代碼如行云流水，糟糕的OO代碼讓人覺得渾身起雞皮疙瘩。編寫優(yōu)秀的OO代碼要求程序員有一定的自我修養(yǎng)，能夠以抽象的思路看待問題，找到問題的核心并對問題域進(jìn)行分解。它強(qiáng)調(diào)的是一種解題的思路，但這個解不是唯一的。
典型的例子是設(shè)計模式，設(shè)計模式確實給了我們以很大的啟發(fā)，通過它，我們能夠了解到優(yōu)秀的代碼是如何用于解決實際問題的。但是是不是你必須在軟件中照搬設(shè)計模式呢？如果你這么做，那么你對設(shè)計模式的理解仍然不夠。我曾和在建筑行業(yè)的朋友聊起Christopher Alexander的建筑的永恒之道。他很興奮的告訴我，那確實是一本很好的書，能夠引發(fā)人很深的思考，但是現(xiàn)在也有另外的一種觀點，認(rèn)為美仍然是無形的，應(yīng)該發(fā)自建筑師的內(nèi)心。對這句話我思考了很久，其實建筑是給人使用的，因此最重要的是它能都給人帶來的價值，隱含在其中的那種活生生的氣質(zhì)，這是建筑師文化底蘊(yùn)的外在表露。所以，Christopher Alexander在那本書中的目的，也是為了找到一種總結(jié)自己觀點的方法，來總結(jié)自己對人文的認(rèn)識。至于現(xiàn)在大家對他的思路提出了質(zhì)疑，那也是一件好事，這說明大家對建筑之道的認(rèn)識到了新的高度。建筑是這樣，軟件中的模式也是一樣的，我也曾熱衷于研究模式的使用，直到某一天我猛然驚醒，與其沉迷于模式的表面形式，為什么不去研究隱藏在它背后的文化底蘊(yùn)呢？武俠小說中常說無招勝有招，模式的應(yīng)用也應(yīng)當(dāng)?shù)竭_(dá)這個境界，你如果可以在不經(jīng)意間應(yīng)用模式的思想，那又何必拘泥于模式的形式呢？
編寫優(yōu)秀OO代碼雖難，但還有更難的事情，就是讓整個開發(fā)團(tuán)隊都產(chǎn)出優(yōu)秀的OO代碼。我們剛才說了，OO對問題的解不是唯一的，但各個不同的優(yōu)秀解匯集到一起，可能就是一個糟糕的解，這是風(fēng)格和架構(gòu)的問題。你如何在團(tuán)隊中制定制度，營造氛圍，讓優(yōu)秀OO代碼成為團(tuán)隊最終的成果？這些問題，在我看來，要比CMM難得多，這個問題并不是靠花錢就能夠解決的。如果能夠解決這個問題，這個團(tuán)隊的創(chuàng)造力一定是驚人的。
4. 面向?qū)ο筌浖_發(fā)過程
普通的軟件開發(fā)過程和面向?qū)ο箝_發(fā)過程有著很大的不同?；叵胛覀冊诜敲嫦?qū)ο笾虚_發(fā)過程中，最經(jīng)常采用的任務(wù)分配方法就是以軟件模塊為單位，這樣的好處是分配簡單，不同任務(wù)之間耦合程度低，容易操作。壞處是幾乎無法做到重用，也缺乏整體性的設(shè)計。而面向?qū)ο筌浖_發(fā)則不同，它是以類、類集合作為基本單位的。類之間關(guān)系錯綜復(fù)雜（雖然我們提倡低耦合的設(shè)計，但類之間的關(guān)系仍然是相對復(fù)雜的）。這種情況下程序員之間相互協(xié)作的要求就非常之高，這種關(guān)系如果處理恰當(dāng)，則能夠完全體現(xiàn)出面向?qū)ο蟮耐Γ駝t，那將會是一場大災(zāi)難，面向?qū)ο蟮能浖_發(fā)過程要養(yǎng)成一些好的習(xí)慣：
4. 1 盡量簡化和穩(wěn)定客戶端。
個人編程可以是一種享受，但團(tuán)隊開發(fā)始終是一項嚴(yán)謹(jǐn)?shù)穆殬I(yè)活動，因此多考慮別人，不要設(shè)計復(fù)雜的接口，雖然你省事了，但這會給理解和使用你的接口和人造成障礙。
4.2 準(zhǔn)備一份簡潔的文檔，并保持更新。
隨便一種形式的穩(wěn)定，可以是代碼，可以是UML圖，也可以是純粹的文字（估計沒幾個程序員喜歡這種形式）。只要它能夠傳達(dá)你的代碼的目的，那就足夠。記住，更新代碼后，同時更新你的文檔。過期的文檔不僅是廢紙這么簡單，它會給其它人造成麻煩。切記！
4. 3 盡可能多的考慮異常和錯誤的情況。
寫出一個功能并沒有什么，但是要把這個功能寫的非常的完善那就很難了，因為你需要考慮各種各樣的情況，正常的、非正常的。所以，寫完一個類的定義應(yīng)該是，完成編碼和穩(wěn)定，并通過原定的測試。
5. 基于面向?qū)ο蟠a的分析框架
在一個開發(fā)過程中，往往有著多種復(fù)雜的因素：過程、技能、工具、規(guī)范、組織、個性。所有的這些，都會對最終的代碼產(chǎn)生影響，對代碼的成本和質(zhì)量產(chǎn)生影響。軟件最有價值的部分是代碼，根據(jù)敏捷方法和精益編程的思路，除了代碼之外的產(chǎn)出物，都不具有價值，或者說對最終用戶沒有價值。但它們都需要成本的投入，而我們應(yīng)該考慮如何節(jié)省這些成本。
要考慮如何節(jié)約成本，關(guān)鍵的因素就是需要分析兩點：
首先，哪些活動對代碼的成本和質(zhì)量有正面的幫助。如果一個活動對代碼沒有幫助，那么它就沒有存在的意義。有一些軟件組織實施了UML，但是開發(fā)人員畫好了UML圖之后，就把它仍在一邊，仍然按照老的方式開發(fā)。這種的活動就沒有任何意義，只是徒增成本。我們稱之為有效原則。
其次，如果活動對代碼的成本和質(zhì)量有正面的幫助，那么，這種幫助的價值足夠大嗎？是否存在其他的活動，其價值能夠超出現(xiàn)有的活動呢？軟件需求規(guī)約（SRS）對代碼產(chǎn)生當(dāng)然有幫助，因為它對軟件要干什么進(jìn)行了定義。問題是，SRS往往需要很大的功夫去制作、維護(hù)。有沒有成本更低、效果更好的方法來替代它呢？用例技術(shù)是一種考慮方向，CRC卡片也是一種敏捷的處理思路。我們稱之為更優(yōu)原則。
有了這兩個概念，我們在后文中的分析將會以此為中心展開，討論代碼和過程、技能、工具、規(guī)范、組織、個性之間的關(guān)系。我們把它們之間的關(guān)系稱為基于代碼的分析框架。在下一篇中，我們選擇一個實際的案例進(jìn)行演練，然后我們從四個方面 -- 重用、優(yōu)化代碼組織、針對契約設(shè)計、業(yè)務(wù)建模 -- 來深入的分析該框架中的一些共通的特性。我們再次重申：軟件開發(fā)過程是一個復(fù)雜的生態(tài)環(huán)境，我們沒有辦法對其進(jìn)行機(jī)械的劃分，我們能夠做的就是把握平衡－成本和質(zhì)量的平衡。
|
