問：敏捷開發(fā)如何融入到現(xiàn)在在推行的CMMI中?
答：首先，我想說(shuō)一下為什么會(huì)在CMM的基礎(chǔ)上提出CMMI。Barry Boehm在其新作《Balancing Agility and Discipline: A Guide for the Perplexed》一書中對(duì)此進(jìn)行了比較深入的闡述。從總體上來(lái)說(shuō)，有兩個(gè)主要原因：1、對(duì)CMM中那些容易導(dǎo)致官僚的部分進(jìn)行了大幅度的更改；2、把風(fēng)險(xiǎn)驅(qū)動(dòng)作為一個(gè)核心內(nèi)容納入到CMMI的框架之中，這樣在CMMI的框架中就可以比較順暢的制定出一些可以非常敏捷的過(guò)程了。但是，CMMI的敏捷性是很難刻畫的，因?yàn)樽鳛橐粋€(gè)過(guò)程改進(jìn)參考模型，它更加貼近一組需求而不是一組實(shí)踐。也就是說(shuō)，我們只能刻畫那些為滿足這些需求而開發(fā)出的過(guò)程。一般來(lái)說(shuō)，CMMI在需求方面的約束少于SW-CMM。如果以更為寬廣的觀點(diǎn)去解釋需求就可以獲取更多的敏捷性。然而，如果在實(shí)施時(shí)采用了全面保守的做法并且使用了由SW-CMM所提供的重量級(jí)成熟度評(píng)估方法，那么所得出的CMMI兼容過(guò)程將是重型且非常計(jì)劃驅(qū)動(dòng)的。因此，我覺得敏捷本來(lái)就可以非常順暢地融入到CMMI的模型中。如果說(shuō)有問題的話，我覺得更多在于實(shí)施者對(duì)敏捷的排斥，而非其他。
?
問：敏捷開發(fā)流程是如何應(yīng)對(duì)各種可預(yù)知和不可預(yù)知的風(fēng)險(xiǎn)? 例如:人員流動(dòng)和變更,項(xiàng)目周期的變更,客戶代表的變更等風(fēng)險(xiǎn)。
答：人員流動(dòng)和變更、項(xiàng)目周期的變更以及客戶代表的變更等風(fēng)險(xiǎn)是任何一個(gè)軟件開發(fā)項(xiàng)目都不可避免要面臨的。一個(gè)好的過(guò)程方法應(yīng)該能夠使得這些風(fēng)險(xiǎn)導(dǎo)致的損失最小化。敏捷方法試圖營(yíng)造一種非常舒適的開發(fā)環(huán)境，這是一種典型的craftsmanship文化。在這種文化中，人們都一自己的技藝為榮，以開發(fā)出高質(zhì)量的軟件為榮，并且不斷追求技藝的提高。在這樣的環(huán)境中，人員流動(dòng)和變更的頻度被大大地降低。另外，敏捷方法對(duì)面對(duì)面溝通、結(jié)對(duì)編程以及高質(zhì)量代碼和文檔的強(qiáng)調(diào)也使得由于人員變動(dòng)所導(dǎo)致的風(fēng)險(xiǎn)大大降低。
對(duì)于項(xiàng)目周期的變更，我想再也沒有比快速、短的迭代更有效的應(yīng)對(duì)方法了。正是這些快速的短迭代為我們帶來(lái)的大量的反饋信息，使得我們對(duì)于項(xiàng)目的狀況具有全面、深入并且是真實(shí)的了解。有了這個(gè)基礎(chǔ)，我們?cè)谧钚』?xiàng)目周期變更風(fēng)險(xiǎn)方面就處于一個(gè)非常有利的位置。而快速的短迭代正是敏捷的重要特征。什么是敏捷呢？敏捷就是：“short cycles that are test-driven and feedback-driven, yielding constant improvements.”對(duì)于客戶代表的變更，我不想多說(shuō)。因?yàn)闊o(wú)論是對(duì)于敏捷方法還是計(jì)劃驅(qū)動(dòng)方法，客戶代表的變更帶來(lái)的風(fēng)險(xiǎn)都是一樣的。如果，沒有一個(gè)好的客戶代表，那么肯定是一個(gè)失敗的項(xiàng)目。
?
問：敏捷開發(fā)流程是否適用于大型、復(fù)雜的應(yīng)用系統(tǒng)？因?yàn)閷?duì)于一些架構(gòu)比較簡(jiǎn)單,代碼量小的系統(tǒng),可以通過(guò)不斷的代碼重構(gòu)進(jìn)行改進(jìn),但對(duì)于一些體系結(jié)構(gòu)比較復(fù)雜的系統(tǒng)在投入運(yùn)行后,短時(shí)間內(nèi),由于客戶業(yè)務(wù)的擴(kuò)張導(dǎo)致的數(shù)據(jù)容量的增大或者網(wǎng)絡(luò)訪問量的增加, 而導(dǎo)致原有的核心架構(gòu)設(shè)計(jì)已經(jīng)不能滿足用戶的需求,而這些重要的架構(gòu)在系統(tǒng)核心服務(wù)中起重要作用而很難進(jìn)行變更。這種情況，變更這些方面的代價(jià)會(huì)很高，因此需要早期花費(fèi)精力預(yù)期此類變更。而且這類軟件的復(fù)雜性和規(guī)模會(huì)導(dǎo)致嚴(yán)格的代碼重構(gòu)代價(jià)過(guò)高而且容易出錯(cuò)。
答：首先我們得在什么是大型、復(fù)雜的應(yīng)用系統(tǒng)這個(gè)問題上取得共識(shí)。Scrum方法應(yīng)用的最大的一個(gè)項(xiàng)目是一個(gè)醫(yī)療圖像信息系統(tǒng)，共有800人。XP方法應(yīng)用的最大一個(gè)項(xiàng)目是一個(gè)企業(yè)資源綜合管理系統(tǒng)，共有50人。當(dāng)然，在人數(shù)增多時(shí)，就必須要采取一些變通的實(shí)踐（否則就不敏捷了）。對(duì)于架構(gòu)方面的問題，我覺得應(yīng)該這樣看。如果是一個(gè)相對(duì)成熟的領(lǐng)域，那么可以借鑒很多業(yè)界已有的經(jīng)驗(yàn)，特別是一些相關(guān)的模式。這一點(diǎn)很重要，否則是要走很多彎路，付出很多代價(jià)的。比如：我覺得在并發(fā)、分布式通信領(lǐng)域，一個(gè)合格的系統(tǒng)工程師必須應(yīng)該知道并理解《Pattern-Oriented Software Architecture, Volume 2》中的所有模式。但是，這只是為你提供了一個(gè)方向，一個(gè)防止你犯重大錯(cuò)誤的方向。這些模式為你代碼的重構(gòu)和系統(tǒng)的演化提供了一個(gè)指引。如果不了解這些模式，基本不可能做出一個(gè)優(yōu)秀的架構(gòu)。了解了這些模式后，是不是就可以在一開始就把它們堆砌起來(lái)以形成一個(gè)能夠適應(yīng)未來(lái)的架構(gòu)呢？當(dāng)然不行。要想構(gòu)建一個(gè)能夠適應(yīng)未來(lái)的架構(gòu)，有兩種途徑，一種需要天才的系統(tǒng)架構(gòu)師，一種是在領(lǐng)域模式的引導(dǎo)下，通過(guò)TDD和Refactoring的方式不斷、逐步地修改。顯然，第2種方法是一種切實(shí)可行的方法。
問：敏捷開發(fā)流程是否不支持創(chuàng)建可復(fù)用產(chǎn)品？對(duì)于一個(gè)工程型,可復(fù)用的產(chǎn)品對(duì)于節(jié)約成本和提高效率是極其重要的!
答：關(guān)于可復(fù)用性的問題，一直都是軟件界討論的熱點(diǎn)。一般來(lái)說(shuō)，有機(jī)制層面的復(fù)用，比如：一般的函數(shù)庫(kù)或者類庫(kù)，也有應(yīng)用領(lǐng)域邏輯的復(fù)用，比如：各種領(lǐng)域相關(guān)的應(yīng)用框架。第一種復(fù)用方法相對(duì)比較容易，但是帶來(lái)的好處也相對(duì)較低。而第二種復(fù)用方法能給我們帶來(lái)最大的好處，但是非常的困難。也正是因?yàn)檫@一點(diǎn)，在業(yè)界一度有“復(fù)用神話”的說(shuō)法。無(wú)數(shù)實(shí)踐表明，要想得到一個(gè)相對(duì)可用的領(lǐng)域框架，必須要經(jīng)受至少3個(gè)同質(zhì)領(lǐng)域?qū)嵺`的錘煉。并且，失敗的數(shù)目要遠(yuǎn)遠(yuǎn)大于成功的。而試圖在一開始就把可復(fù)用性作為目標(biāo)的項(xiàng)目基本上沒有取得成功的（這樣的框架一般具有這樣的特點(diǎn)：本來(lái)一件簡(jiǎn)單的任務(wù)，但在使用了該框架后卻變得非常復(fù)雜。）。因此，現(xiàn)在業(yè)界比較一致的看法是，首先應(yīng)該針對(duì)你開發(fā)的領(lǐng)域搭建一個(gè)特定于項(xiàng)目的、簡(jiǎn)單的框架。一開始不要考慮復(fù)用性，而關(guān)注于系統(tǒng)的清晰性和簡(jiǎn)單性。在另一個(gè)同質(zhì)的項(xiàng)目中，通過(guò)重構(gòu)、演化的方法在對(duì)這個(gè)框架進(jìn)行修正，使之更具通用性，如此循環(huán)往復(fù)。在經(jīng)歷過(guò)多個(gè)項(xiàng)目后，可能你就得到了一個(gè)比較具有可復(fù)用性的框架。也就是說(shuō)，應(yīng)該關(guān)注于創(chuàng)建那些比較容易演化為可重用框架的東東，這個(gè)東東應(yīng)該具有兩個(gè)特點(diǎn)：1、針對(duì)具體問題；2、非常簡(jiǎn)單清晰。敏捷方法非常注重這種框架的形成，但是不會(huì)刻意去這樣做，它的思路是在不斷的循環(huán)、迭代中把它演化出來(lái)。在這個(gè)循環(huán)迭代中，敏捷方法以DRY（Don't Repeat Yourself）原則來(lái)逐步建立起更大規(guī)模重用的基礎(chǔ)。
問：敏捷開發(fā)流程的質(zhì)量保證機(jī)制是否足夠滿足開發(fā)有嚴(yán)格安全性和可靠性要求的軟件？對(duì)于在電力,電信系統(tǒng)中一些有嚴(yán)格安全性要求的軟件敏捷開發(fā)流程支持的質(zhì)量控制機(jī)制似乎并沒有證明來(lái)說(shuō)服使用者軟件是安全的。是否還需其它措施進(jìn)行補(bǔ)充?
答：首先我要說(shuō)的是，安全性和可靠性是屬于用戶需求的范疇，而敏捷方法中把客戶滿意放在了非常重要的位置上，單從過(guò)程方法的思想基礎(chǔ)方面來(lái)說(shuō)，沒有那種方法能比敏捷方法更關(guān)注客戶的滿意度了。其次，安全性和可靠性不是通過(guò)一些條條框框說(shuō)出來(lái)的，那些在系統(tǒng)方案中空洞地羅列一些安全性和可靠性方面的術(shù)語(yǔ)的做法，對(duì)于保證系統(tǒng)的可靠性和安全性沒有任何用處。保證安全性和可靠性的唯一方法就是去檢驗(yàn)，隨著系統(tǒng)的演化，不斷地檢驗(yàn)。把用戶在安全性和可靠性方面的需求通過(guò)測(cè)試用例的方式編寫出來(lái)，頻繁地去驗(yàn)證系統(tǒng)是否能夠通過(guò)這些測(cè)試，如果不通過(guò)，就是一次集成失敗。不知大家在保證系統(tǒng)可靠性和安全性方面是如何做的？
問：目前的項(xiàng)目和部門的組織架構(gòu),內(nèi)部客戶和外部客戶離開發(fā)人員都很遠(yuǎn),怎樣能夠達(dá)到零距離? 雖然單個(gè)客戶和開發(fā)人員在一起工作可以有效對(duì)需求變更進(jìn)行跟蹤,及時(shí)響應(yīng)需求變更,但如果系統(tǒng)面對(duì)的客戶是不同的,如何避免開發(fā)期間一些需求變更的單一性和獨(dú)特性?
答：無(wú)論項(xiàng)目采用任何方法，它對(duì)于客戶都有同樣的要求，就是這個(gè)客戶必須是CRACK（Collaborative、Representative、Authorized、Committed、Knowledgeable）型的客戶。鑒于目前我們所處的各種環(huán)境，完全的CRACK和現(xiàn)場(chǎng)客戶可能不太可能。但是一個(gè)能夠合格地?fù)?dān)當(dāng)其客戶角色，并且能夠比較頻繁的參與到項(xiàng)目開發(fā)中來(lái)的人員對(duì)于項(xiàng)目的成功來(lái)說(shuō)是必須的。另外，應(yīng)對(duì)需求的變化正是敏捷方法的強(qiáng)項(xiàng)，如果這些變化是客戶真正需要的，那么為何要避免呢？此時(shí)，我們應(yīng)該利用這些變化取得優(yōu)勢(shì)。
問：如何避免開發(fā)人員利用夠用文檔這個(gè)借口偷懶少寫文檔？
答：處于敏捷文化中的人以高質(zhì)量地完成任務(wù)為榮，如果寫文檔是高質(zhì)量地完成任務(wù)的一部分，那么他肯定會(huì)高質(zhì)量地寫出這份文檔。否則，寫再多言之無(wú)物、只滿足格式的文檔又有什么用呢？敏捷實(shí)踐都是能夠真正提供開發(fā)人員技能的實(shí)踐，敏捷方法強(qiáng)烈反對(duì)那些僅僅是為了防止開發(fā)人員“偷懶”而制定的規(guī)程。
?
問：開發(fā)人員面對(duì)面的交流過(guò)頻繁,導(dǎo)致大會(huì)小會(huì)不斷,如何把握這個(gè)度?
答：面對(duì)面交流不是開會(huì)。只要覺得需要就去交流。
?
問：簡(jiǎn)單設(shè)計(jì)的粒度如何把握,如果強(qiáng)調(diào)前期架構(gòu)的簡(jiǎn)單設(shè)計(jì),如何應(yīng)對(duì)軟件投入運(yùn)行后,短時(shí)間內(nèi),由于客戶業(yè)務(wù)的擴(kuò)張導(dǎo)致的數(shù)據(jù)容量的增大或者網(wǎng)絡(luò)訪問量的增加,而導(dǎo)致原有的設(shè)計(jì)已經(jīng)不能滿足用戶的需求?
答：請(qǐng)參見前面那個(gè)關(guān)于架構(gòu)的回答。首先，你要有豐富的經(jīng)驗(yàn)和知識(shí)，這些東西可以為你提供一個(gè)架構(gòu)演化的方向。如果沒有這些東西，基本上沒有可能首次就找到正確的方向。有了方向后，下面就是TDD＋Refactoring不斷演化。
?
問：簡(jiǎn)單設(shè)計(jì)如何能保證實(shí)施測(cè)試驅(qū)動(dòng)開發(fā)?如果設(shè)計(jì)的不夠詳細(xì),如何對(duì)接口編寫測(cè)試用例和測(cè)試代碼?
答：首先，不是簡(jiǎn)單設(shè)計(jì)保證實(shí)施測(cè)試驅(qū)動(dòng)開發(fā)，而是測(cè)試驅(qū)動(dòng)開發(fā)可以促使你得到一個(gè)簡(jiǎn)單的設(shè)計(jì)。其次，是先有測(cè)試用例，然后才有設(shè)計(jì)和接口。
?
問：《敏捷》書中把創(chuàng)建驗(yàn)收測(cè)試作為一種設(shè)計(jì)系統(tǒng)架構(gòu)的重要手段，也作為對(duì)最終用戶的一種功能演示，但本質(zhì)上還是對(duì)系統(tǒng)特性的一種模擬集成測(cè)試，并不能完全代表實(shí)際系統(tǒng)，這種驗(yàn)收測(cè)試與傳統(tǒng)意義上的驗(yàn)收測(cè)試不同，這種驗(yàn)收測(cè)試可靠嗎？
答：這里所指得傳統(tǒng)意義上的驗(yàn)收測(cè)試是什么？是指有測(cè)試人員進(jìn)行的測(cè)試嗎？一般在敏捷方法中（特別是XP）所指的驗(yàn)收測(cè)試，都是由QA和客戶代表共同編寫的，如果通過(guò)就表明實(shí)現(xiàn)了客戶需求。我覺得沒有其他方法能比這個(gè)方法更可靠了。
?
問：測(cè)試驅(qū)動(dòng)開發(fā)的例子中，開始也做了簡(jiǎn)單的設(shè)計(jì)，然后再編寫測(cè)試用例，最后形成另外一種設(shè)計(jì)。開始時(shí)需要設(shè)計(jì)嗎？如果需要，應(yīng)該達(dá)到什么程度？開始不進(jìn)行設(shè)計(jì)而純粹依靠測(cè)試來(lái)驅(qū)動(dòng)設(shè)計(jì)可能嗎？我的理解是，測(cè)試驅(qū)動(dòng)開發(fā)更適合于詳細(xì)設(shè)計(jì)階段，測(cè)試驅(qū)動(dòng)開發(fā)適合于架構(gòu)設(shè)計(jì)嗎？文章中的測(cè)試驅(qū)動(dòng)開發(fā)例子中，軟件需求好像來(lái)自個(gè)人“隨心所欲”的想象，這種測(cè)試用例的生成方法是否缺乏系統(tǒng)性和完備性？或者說(shuō)，測(cè)試驅(qū)動(dòng)開發(fā)的測(cè)試用例的產(chǎn)生是否也需要嚴(yán)密的設(shè)計(jì)呢？
答：什么是設(shè)計(jì)？這是一個(gè)必須首先達(dá)成共識(shí)的問題。TDD的核心就是持續(xù)設(shè)計(jì)，不斷關(guān)注設(shè)計(jì)質(zhì)量，這種關(guān)注是建立在頻繁的、真實(shí)的反饋的基礎(chǔ)之上的，而不是一些臆想。達(dá)到的程度就是“tuned to today and poised to strike at tomorrow.”通過(guò)一些想象畫幾張UML圖，那不是設(shè)計(jì)，設(shè)計(jì)應(yīng)該是可驗(yàn)證的，并且要通過(guò)反饋持續(xù)修正的。設(shè)計(jì)的驗(yàn)證正是通過(guò)測(cè)試用例進(jìn)行的。測(cè)試用例可以是客戶需求，這是驗(yàn)收測(cè)試。也可以是開發(fā)團(tuán)隊(duì)內(nèi)部實(shí)現(xiàn)上的需求，這是開發(fā)團(tuán)隊(duì)內(nèi)部的測(cè)試（一般也成為單元測(cè)試）。測(cè)試用例應(yīng)該來(lái)自客戶，這是勿庸置疑的。測(cè)試活動(dòng)本來(lái)就是一項(xiàng)風(fēng)險(xiǎn)驅(qū)動(dòng)活動(dòng)，在測(cè)試投入到達(dá)一定水平后，它的效果會(huì)迅速降低。對(duì)于“系統(tǒng)性”、“完備性”以及“嚴(yán)密性”，我不知道具體指得是什么？能不能詳細(xì)說(shuō)明一下，并介紹大家是如何做到需求的“系統(tǒng)性”、“完備性”以及“嚴(yán)密性”。
問：敏捷設(shè)計(jì)開始設(shè)計(jì)的程序也可能是最簡(jiǎn)單，不具有靈活性，直到需要變化時(shí)，團(tuán)隊(duì)才抓住機(jī)會(huì)應(yīng)用敏捷設(shè)計(jì)原則去改進(jìn)設(shè)計(jì)。這里有幾個(gè)前提，團(tuán)隊(duì)?wèi)?yīng)該對(duì)不良設(shè)計(jì)足夠敏感，才能抓住改進(jìn)設(shè)計(jì)的機(jī)會(huì)；團(tuán)隊(duì)有足夠的時(shí)間去改進(jìn)設(shè)計(jì)。如果這兩個(gè)前提不成立，如果進(jìn)行敏捷設(shè)計(jì)？
答：怎樣才具有靈活性呢？把東西做簡(jiǎn)單，簡(jiǎn)單的東西最具有靈活性！Kent Beck在《eXtreme Programming》一書中對(duì)什么是簡(jiǎn)單做過(guò)明確的定義。用一句話來(lái)說(shuō)，就是：“clean code that works.”如果這些前提不成立的話，那么什么設(shè)計(jì)都做不了。很多敏捷實(shí)踐的目的就是幫助我們通過(guò)學(xué)習(xí)、實(shí)踐來(lái)培養(yǎng)這種敏感性。
問：測(cè)試驅(qū)動(dòng)開發(fā)過(guò)程中如何把握“前進(jìn)的步伐”，即，每個(gè)測(cè)試用例的粒度如何把握？粒度大，可以加快開發(fā)速度，但又可能漏掉某些bug；粒度小，又影響開發(fā)進(jìn)度。如何看待測(cè)試驅(qū)動(dòng)開發(fā)過(guò)程中的測(cè)試用例？是單元測(cè)試嗎？還是粒度很大的集成測(cè)試？如果是單元測(cè)試，至少也不應(yīng)該是傳統(tǒng)意義上的單元測(cè)試，此時(shí)的單元測(cè)試是屬于黑盒測(cè)試還是白盒測(cè)試，或者既不是黑盒也不是白盒？如何理解測(cè)試驅(qū)動(dòng)開發(fā)可以改進(jìn)設(shè)計(jì)？有何理論根據(jù)？能夠從黑盒測(cè)試的理論闡述這個(gè)問題嗎？
答：粒度就是一個(gè)獨(dú)立的、可以驗(yàn)證的東西。Kent Beck在其《Test-Driven Development》一書中對(duì)使用TDD開發(fā)的節(jié)奏有詳細(xì)的描述，我就不再贅述。寫測(cè)試覺得不會(huì)影響開發(fā)進(jìn)度，越是在時(shí)間壓力大的情況下，越是如此。我想大家都有過(guò)這樣的經(jīng)歷吧：“花20分鐘完成了一項(xiàng)功能，然后花2個(gè)小時(shí)甚至更多的時(shí)間去調(diào)試。”在TDD中，測(cè)試用例只用兩種，面向客戶的驗(yàn)收測(cè)試用例，和面向開發(fā)團(tuán)隊(duì)內(nèi)部的內(nèi)部測(cè)試用例（一般也稱為單元測(cè)試）。為什么一定要那么清楚地區(qū)分黑盒和白盒呢？測(cè)試驅(qū)動(dòng)開發(fā)能夠改善設(shè)計(jì)的思想基礎(chǔ)在《Test-Driven Development》有詳細(xì)闡述。這和黑盒測(cè)試沒有任何關(guān)系。TDD更是一種設(shè)計(jì)方法，一種有反饋、有驗(yàn)證的真正的設(shè)計(jì)方法。
問：關(guān)于“軟件之美”：對(duì)軟件設(shè)計(jì)者來(lái)說(shuō)，被簡(jiǎn)單、直觀地分割，并具有最小內(nèi)部耦合的內(nèi)部結(jié)構(gòu)就是美的。美的系統(tǒng)是靈活、易于理解的，構(gòu)建、維護(hù)它們就是一種快樂。在軟件領(lǐng)域，如何審美？“靈活、易于理解的”這個(gè)概念含有很多主觀性，對(duì)某一具體的軟件審美，不同的人的評(píng)價(jià)是不一樣的，大師級(jí)別的人當(dāng)然更準(zhǔn)確些，但大師級(jí)別的人太少了，那么，有沒有一些客觀的、可以量化的指標(biāo)？使得沒有很多經(jīng)驗(yàn)的人，也可以以此為指引，改進(jìn)軟件使之向美的方向發(fā)展？
答：《敏捷軟件開發(fā)：原則、實(shí)踐和模式》一書中給出了很多原則和實(shí)踐方法，可以作為很好的參考。
?
問：極限編程只適用于輕量級(jí)團(tuán)隊(duì)和項(xiàng)目，還是也適用于重量級(jí)團(tuán)隊(duì)和項(xiàng)目？和CMM等有無(wú)矛盾？在推行極限編程哪些可行（如測(cè)試驅(qū)動(dòng)開發(fā)），哪些不可行（如結(jié)對(duì)編程）？在重量級(jí)團(tuán)隊(duì)和項(xiàng)目中如何運(yùn)用？
答：極限編程對(duì)于小型項(xiàng)目（10~20人）來(lái)說(shuō)肯定沒有問題。對(duì)于大型項(xiàng)目來(lái)說(shuō)，照搬XP中的實(shí)踐，肯定是會(huì)出問題的。所以需要一定程度的根據(jù)具體情況進(jìn)行修正。關(guān)于和CMM有無(wú)矛盾的問題，這方面的討論和文章有很多，基本上是見仁見智。不過(guò)，在提高開發(fā)質(zhì)量這個(gè)目標(biāo)上是肯定不矛盾的。其實(shí)，關(guān)于CMM本身該如何實(shí)施方面也存在很多不同意見，不同的評(píng)估師給出截然不同的結(jié)論的案例就有很多。其實(shí)也沒有必要非得全盤照搬XP不可，我覺得可以在不更改團(tuán)隊(duì)現(xiàn)有運(yùn)作流程的情況下，先引入小部分實(shí)踐，TDD應(yīng)該是首選。
?
問：5個(gè)重要的原則“單一職責(zé)原則、開放－封閉原則、Liskov替換原則、依賴倒置原則、接口隔離原則”雖然在此把它們表述為面向?qū)ο笤O(shè)計(jì)的原則，但是事實(shí)上它們只是軟件工程中一直存在的原則的特例而已。那么，軟件工程中一直存在的普遍性原則是什么？有哪些？在結(jié)構(gòu)化編程還大量應(yīng)用的嵌入式開發(fā)中，如何運(yùn)用？“為使用而使用”設(shè)計(jì)原則會(huì)導(dǎo)致不必要的復(fù)雜性，設(shè)計(jì)原則是經(jīng)驗(yàn)的總結(jié)，它必然是思考某個(gè)問題而得到的解決辦法指導(dǎo)，那么，在編程當(dāng)中，時(shí)刻要思考的問題有哪些？
答：首先我得說(shuō)一下，越是具有普遍性得原則，越不具有可實(shí)施性，只有針對(duì)特定context和force的原則才具有更多的實(shí)際意義，這也是模式為何在傳播優(yōu)秀的設(shè)計(jì)經(jīng)驗(yàn)方面得到普遍認(rèn)可的重要原因。如果非要給出一個(gè)普遍原則的話，我覺得Grady Booch曾經(jīng)說(shuō)過(guò)的一句話可以作為參考：“The entire history of sw enginerering is one of rising levels of abstraction.”不論你使用結(jié)構(gòu)化編程還是面向?qū)ο缶幊蹋私舛喾N編程范型肯定會(huì)對(duì)你的開發(fā)帶來(lái)好處。設(shè)計(jì)原則和模式只能為你指引方向，最為重要的是要保持（設(shè)計(jì)）代碼簡(jiǎn)單，時(shí)刻思考的問題就是，這段代碼是不是清晰地表達(dá)了我的意圖，也就是要intentional programming，要“Keep It DRY, Shy, and Tell the Other Guy.