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