 |
相關閱讀 |
大道至簡——軟件工程實踐者的思想 第8章 是思考還是思想
|
>>> 讀書—連接古今充實信仰 >>> | 簡體 傳統 |
第8章 是思考還是思想
“此郎亦管中窺豹，時見一斑。”
——《晉書王獻之傳》
1. 軟件工程三個要素的價值
思考問題的方法可以是由點及面的，也可以是統攬全局的。換成業界最常用的詞匯，就是“自上而下”還是“自下而上”的區別。
“牛屎圖”中描述的工具、方法與過程也被稱為軟件工程的三個要素。在本書中他們被分解開來思考，并不是要孤立這個三個層面。——它們實際上是相互作用的。
例如“過程”問題，就既有實施過程的工具，也有相關的過程方法理論。我雖然說方法是“基于一種數據結構的編程實踐的結果”，但這實在一種非常狹義的定義。這個定義在過程的開發環節是有效的(或者說是對“開發方法”的定義)。然而“需求”、“設計”、“測試”等等其它環節也有各自的方法論，即使站在具體環節之外，過程本身也有方法論的問題，這還不包括管理方法等等在內。
由于方法在過程環節以及過程總體層面上具有貫通性，因此保證“方法(或其行為)”的實施的“工具”也會出現在過程的各個環節和層面上。因此這樣得到的軟件工程模型將不是經典的、層狀的“牛屎圖”，而可能象太極圖一樣由陰陽交匯而生萬物。
為了不使讀者認為我已經入了道家理論的歧途，這樣
的一副圖還是交由你自己去畫吧。只不過你應該清楚，即
使畫出了太極圖的軟件工程模型，你所視見到的仍舊是工
程的細部環節。就如同以管窺豹一般，斑是斑，豹是豹。
你能把每一個“管見”拼合起來，你得到的才能是
“豹”，而不是“斑”。所以盡管本書割裂了軟件工程的各
個要素，并從每個孤立的層面來審視。然而實質上，你應
該回歸到軟件工程的本體上來思考問題，而不是僅關注于
每一個局部的要素。
工程的整體問題仍舊是“實現”。
2. 其實 RUP 是一個雜物箱
我或許總是在批評 RUP，但是我不得不承認它是對
前人在軟件過程思想方面高度包容。
請注意我用“包容”這個詞，而不是按照語言習慣那
樣用“概括”。因為如果是“高度概括”，那你應該把目光
投向瀑布模型，而 RUP 其實就象一個雜物箱一樣“包容”
了全部的已知理論。
你可以把 RUP 定制成其它任何模型所表述的過程形
態。——RUP 本身的特質決定了這一點。——因而它也
如同一個雜物箱一樣放滿了各種希奇古怪的東西。你可能
從這個雜物箱里面拿出了一把剪刀，或一只蒼蠅拍，或者
是一根釣桿……
喂，等等。面對“軟件開發”這樣的一個需求，釣桿
能有什么作用呢？在你扔掉它之前，請轉換一下你的思
維：釣桿可能帶給你的團隊以精神上的激勵。如果你能意
識到這一點，那么它將立即轉化為生產力：把釣桿掛在開
發部的墻上。
RUP 能不能被用起來，將取決于在于你剛才那個挑
挑撿撿的行為，以及現在你在拿到釣桿后的辨識能力與組
織能力。
3. UML 與甲骨文之間的異同
在你真的打算用甲骨文來寫項目文檔之前，請先明確
UML 與甲骨文之間的異同。
在這本書里，他們都被作為溝通的工具。因此目標是
溝通，而不是“選用工具”這件事本身。更進一步的推論
是：即使你因為個人喜好而選擇了甲骨文，也不要試圖在
結繩記事的原始人面前去用它。
UML 與甲骨文都是符號文字，都具有象形含義。然
而這并不表明 UML 符號本身能表達多么豐富的含義。如
果要象甲骨文一樣用幾代人、上千冊的論著去解釋它，那
么 UML 圖的價值也就只剩下象征性的意義了。
出于溝通的必要，這種語言的象征意義在一個圖中應
當被表述得足夠準確和詳細，乃至于針對于不同的閱讀者
來說都能提供了充足的信息。然而，一方面 UML 的規范
中沒有提供一個標準來衡量“怎樣的 UML 圖是描述充分
的”；另一方面，UML 作為一個語言，也無法直接在某個
硬件平臺中被語法檢錯和調試。
所以在工程中使用 UML 圖，應該有相應的文字來描
述它。而且這種描述與圖之間的對應關系要持續地維護下
去。如果這種關系松散了、斷裂了，那么下一個閱讀 UML
圖的人所面對的，將是無異于甲骨文出土時的困境。
好在做 UML 圖的那個工程設計人員(在辭世之前)還
有機會為這些古怪符號寫下規約。
4. 經營者離開發者很遠，反之亦然
使我第一次意識到 EHM 模型反映了角色所關注的不
同視角的人，是我的老板。
事實上，他是一個完全不懂軟件技術的老板。在 EHM
模型中，他所處于的位置在最右端，而開發者在最左端，
在二者之間沒有相同的關注界面(關注點)。EHM 真實地反
應了“老板不懂技術”的合理性，同樣也真實的反應了“開
發者轉型為老板”的道路將是相當地漫長與艱難。
于是，項目經理這個中間角色就有了一種使命：協調
經營者與開發者之間的溝通。
例如招來一名開發高手，對于公司的運作并不會有深
入的影響(當然如果你招來了 Anders Hejlsberg 就另當別
論)。因此，我甚至不需要與 BOSS 討論這名高手的來歷
及作用。同樣，與一個技術分析人員討論一個產品的技術
價值與市場價值之間的差異，以及市場運作方式與技術實
現手段的無關性，是毫無必要的。
你要理解這種根源：角色的關注層面完全不同。
5. 矛盾：實現目標與保障質量
在需求階段我們就會面臨“目標”的問題。然而(在
大多數時候)，與此相反的是我們會在項目交付和試用時
才會碰到客戶在質量上的投訴。
需求人員會把所有的責任歸咎到開發人員，而開發人
員又不停地埋怨需求的不清不楚或者變更的沒完沒了。又
如果正巧需求和開發都是同一個人或者小組來做的，那么
他們便會開始埋怨客戶的苛刻以及工期的緊張。
總之一件事，沒有人會跳出來說：我們原本就錯了。
然而事實上可能真的出在源頭：我們把目標定錯了。
我們看到，在項目的平衡三角(時間、資源和功能)中
討論的是目標問題，但并不討論質量問題。也就是說，經
典教材中總是關注：如何更快的完成項目，并減少資源占
用，以及實現更多的功能。然而，即使平衡了這種關系，
項目的結果仍可能產生一個天生的殘障。
因為目標可能在平衡中確立，但質量卻要在過程中控
制。即使在時間、資源和功能三者中取得了平衡，即使客
戶、項目組和公司同樣滿意于這個平衡“目標”，它仍然
有可能是“不能實施”的。
如果原定的目標(的整體)本身就過大，那么無論如何
平衡這三者之間的關系，其結果仍舊是保障不了質量。
問題是：又有誰愿意在最初簽訂協議的時候，就降低
或者放棄協議的標的呢？
6. 枝節與細節
剛才說到目標和質量的問題時，提及“平衡時間、資
源和功能三者的關系”。這其實是一個實施過程中的細節。
或者說，它是一個具體的方法，而不是目的。
所以我們通常所說的細節，其實是對實施方法的一些
有限量的描繪。比如“軟件工藝”這個概念本身的提出，
就是考究“細節問題”的。從這個角度上來說，我并不反
對“細節決定成敗”這樣的觀點。但請注意一個前提：這
是技術或方法的細部。
我其實在前面的行文中一再地混用了“細節”與“枝
節”這兩個詞。枝節是事實發展的次要的分枝，它不涉及
行為本身，也不是對行為本身的考量。因此我在前面的文
字中說到“跳出細節”，其實的本意是“跳出枝節”。——
細節只有做到何種程度的問題，而不并是關不關注(或做
不做)的問題。
大多數情況下，管理人員有責任去審核、評估其它成
員的工作成果。這個時候可以討論“細節決定成敗”這樣
的問題，因為這決定了產品的最終質量，而質量是工程的
目標之一。
而在另一些情況下，例如管理人員做事件的決策的時
候，就必須要學會忽略枝節問題。
混淆這兩個名詞的使用，其根本原因在于一大部分讀
者并不能區分“細節”與“枝節”。從慣于“實做”的程
序員一路走來的工程人員，很難分清自己什么時候是在
“工作”，而什么時候又是在“決策”。
因此我只好用最笨的方法提示管理者：別管它是細節
還是枝節，只要你感到你的腳趾已經沾上了泥淖，就快點
回頭。
用腳趾去感覺，有時比用頭腦去思維來得有效。
7. 靈活的軟件工程
并不象現代人想見的那樣，古詩詞一定是“逐字論平
仄”的。變化或者變通，其實是常見之事。因此古詞譜中，
才常會見到冠以“攤破”、“減字”、“添字”等字的詞格。
然則古人在詞格上的這種變通，是基于“音律”的。
通常說的詞律是指詞格，這與音律是兩回事。詞律(格)
是平仄，音律則是樂器、音調與歌舞。古詞中用來吟唱與
歌舞的詞牌就不能混用，律不同，調不同，如是之。
“古人做詞的變格，勢必依音律而為之，舍周邦彥、東坡、
辛棄疾此等人物，輕易變格，是為他人所笑話的。所以，詞譜中
所錄變格既少，且俱為名家所創。”
然而古詞的音律(亦即是律譜)已經失傳了，也就是
說，今天的詞是用來讀的，不是唱，也不是舞，甚至連吟
哦也不是。所以今人總是拿普通話中的 1、2 聲作為平聲，
3、4 聲為仄聲來填詞，并以此論平仄，而全然不想詞的
格律的根基是“詞律”與“音律”這兩個部分的融合。
我曾經參與過一個討論，叫“古人是如何說話的”。
在我看來，古人做文章和說話是兩回事，文章中之乎者也，
日常交流中還是市井俚語的。因此評論中會說“以俚語入
詞”。也可見填詞作文章與說話畢竟是不同。再者說話也
存在方言的問題，因此方言之間平仄音調也當不同。古代
的歌妓是要求會“官話”的，這相當于現在“普通話”的
地位，她們歌唱起來，也是用的“官話”。
更進一步的推論是：古代的詞律中的平仄是以官話為
基礎的。然而如今的普通話畢竟不是古時的“官話”，也
就是說，即使我們以普通話的四聲為基礎在論平仄，在古
人看來，也是可笑的：這樣做出來的詞，依舊不可唱，也
不可讀。
因此今人做詞的標準，是應該重定的了。除了詞格(這
里僅指字句的格式)和用韻之外，其它的部分是無法遵循
的了。在各字的平仄以及句式上，應當以“能通順”和“能
品味”為準，風格上則以古雅為益。
僅此而已。
對于我這樣的格律觀點，一位網友曾有一句“未蘊而
變，自欺也。知律而變，智者之道也”，實為良言。變向
不變求。不變者，萬變之所源，亦萬變之所歸。習詩詞之
法度，若蠶蟲之結繭，若無結繭于前，何有破繭于后？故，
知律而變，智者之道也。
“知律而變”中的“律”字，若解釋作“規律”，那么便是可以用于軟件工程中的了。“道”是規律，如果明“道”，而可以變化無窮，這樣做軟件工程才是活的。就如同今人難于填詞一樣，不明道，則不明智，不明智則無所以為，因而在軟件工程實施中不可避免的盲目與停滯。
“知律”的另一層意思，是在于“知道原理”。明白“為什么要這樣”或者“為什么不是那樣”。這在軟件開發中是常見的問題，大多數人不知究竟地使用著技巧和方法，而一旦出了問題，則歸究于這些技巧和方法的不好。
而真正的問題在于，這些人(我們通常叫做 Copy&Paster)并不知道這些技巧、技術和方法的原理，因而不知道變通，也不知道回避錯誤。
所以死讀一本《軟件工程》的人不會做真正的軟件工程。
所以我寫《大道至簡——軟件工程實踐者的思想》。
周愛民(Aimingoo) 2013-08-24 22:39:52
評論集
暫無評論。
稱謂：
内容：
驗證：
返回列表