原則 1 質(zhì)量第一 

       QUALITY IS #1 

       無論如何定義質(zhì)量，客戶都不會(huì)容忍低質(zhì)量的產(chǎn)品。質(zhì)量必須被量化，并建立可落地實(shí)施的機(jī)制，以促進(jìn)和激勵(lì)質(zhì)量目標(biāo)的達(dá)成。即使質(zhì)量沒達(dá)到要求，也要按時(shí)交付產(chǎn)品，這似乎是政治正確的行為， 但這是短視的。從中長(zhǎng)期來看，這樣做是自殺。質(zhì)量必須被放在首位，沒有可商量的余地。Edward Yourdon 建議，當(dāng)你被要求加快測(cè)試、 忽視剩余的少量 bug、在設(shè)計(jì)或需求達(dá)成一致前就開始編碼時(shí)，要直接說“不”。

       原則 2 質(zhì)量在每個(gè)人眼中都不同

       QUALITY IS IN THE EYES OF THE BEHOLDER 

       軟件質(zhì)量沒有唯一的定義。對(duì)開發(fā)者來說，質(zhì)量可能是優(yōu)雅的設(shè) 計(jì)或優(yōu)雅的代碼。對(duì)在緊張環(huán)境中工作的客戶來說，質(zhì)量可能是響應(yīng) 時(shí)間或高吞吐量。對(duì)成本敏感的項(xiàng)目來說，質(zhì)量可能是低開發(fā)成本。對(duì)一些客戶來說，質(zhì)量可能是滿足他們所有已知和未知的需求。這里 的難題是，以上要求可能無法完全兼顧。當(dāng)優(yōu)化某人關(guān)注的質(zhì)量時(shí)， 可能會(huì)影響其他人關(guān)注的質(zhì)量（這就是溫伯格的“政治困境”原則）。項(xiàng)目必須確定各因素的優(yōu)先級(jí)，并清晰地傳達(dá)給所有相關(guān)方。

       原則 3 高質(zhì)量軟件是可以實(shí)現(xiàn)的 

       HIGH-QUALITY SOFTWARE IS POSSIBLE 

       盡管我們的行業(yè)中有一些表現(xiàn)不佳、包含 bug，或者根本無法滿 足客戶需求的軟件系統(tǒng)的例子，但仍然有一些成功的例子。大型軟件 系統(tǒng)可以以非常高的質(zhì)量構(gòu)建，但價(jià)格昂貴：每行代碼高達(dá) 1000 美 元。例如，IBM 為美國(guó)宇航局的航天飛機(jī)開發(fā)的機(jī)載飛行軟件，總共 約 300 萬行代碼，源于嚴(yán)謹(jǐn)?shù)能浖�開發(fā)過程，產(chǎn)品發(fā)布后每萬行代碼中發(fā)現(xiàn)的錯(cuò)誤少于一個(gè)。作為軟件開發(fā)人員，應(yīng)該學(xué)習(xí)和了解已被驗(yàn)證、可以極大提高軟件質(zhì)量的方法。這些方法包括：讓客戶參與（見原則 8）、原型設(shè)計(jì) （在全面開發(fā)之前驗(yàn)證需求；見原則 11～13）、保持設(shè)計(jì)簡(jiǎn)單（見原 則 67）、審查代碼（見原則 98）和雇用最優(yōu)秀的人（見原則 130 和 131）。作為客戶，在追求卓越的同時(shí)，要意識(shí)到隨之而來的高額成本。

       原則 4 不要試圖通過改進(jìn)軟件實(shí)現(xiàn)高質(zhì)量

       DON’T TRY TO RETROFIT QUALITY 

       質(zhì)量無法通過軟件的改進(jìn)來獲得。這適用于質(zhì)量的任何定義：可 維護(hù)性、可靠性、適應(yīng)性、可測(cè)試性、安全性等。即使我們?cè)陂_發(fā)過 程中十分努力，使軟件具備高質(zhì)量也是十分不易的。如果我們不努力， 又怎么可能期望獲得高質(zhì)量呢？這就是絕不能將“一次性原型”轉(zhuǎn)換 成產(chǎn)品的主要原因（見原則 11）。

       原則 5 盡早把產(chǎn)品交給客戶

       GIVE PRODUCTS TO CUSTOMERS EARLY 

       在需求階段，無論你多么努力地試圖去了解客戶的需求，都不如 給他們一個(gè)產(chǎn)品，讓他們使用它，這是確定他們真實(shí)需求的最有效方 法。如果遵循傳統(tǒng)的瀑布式開發(fā)模型，那么在 99% 的開發(fā)資源已經(jīng) 耗盡之后，才會(huì)第一次向客戶交付產(chǎn)品。如此一來，大部分的客戶需 求反饋將發(fā)生在資源耗盡之后。和以上方法相反，可在開發(fā)過程的早期構(gòu)建一個(gè)快速而粗糙的原 型。將這個(gè)原型交付給客戶，收集反饋，然后編寫需求規(guī)格說明并進(jìn) 行正規(guī)的開發(fā)。使用這種方法，當(dāng)客戶體驗(yàn)到產(chǎn)品的第一個(gè)版本時(shí)， 只消耗了 5%～20% 的開發(fā)資源。如果原型包含合適的功能，就可以 更好地理解和把握最有風(fēng)險(xiǎn)的客戶需求，最終產(chǎn)品也就更有可能讓客 戶滿意。這有助于確保將剩余的資源用于開發(fā)正確的系統(tǒng)。

       原則 6 促使開發(fā)者與客戶的目標(biāo)一致 

       ALIGN INCENTIVES FOR DEVELOPER AND CUSTOMER 

       項(xiàng)目經(jīng)常會(huì)因?yàn)榭蛻艉烷_發(fā)人員的目標(biāo)不同（或不兼容）而失敗。一個(gè)簡(jiǎn)單的案例是，客戶希望在特定日期前獲得特性 1、2、3，而開 發(fā)人員希望最大化營(yíng)收或利潤(rùn)。為了最大化營(yíng)收，開發(fā)人員可能會(huì)嘗 試完整地開發(fā)這三個(gè)特性，即使會(huì)導(dǎo)致項(xiàng)目延期。與此同時(shí)，客戶可 能寧愿放棄其中一個(gè)特性的一部分功能，只要能按時(shí)交付其他特性。為使雙方的目標(biāo)達(dá)成一致，有如下方法：（1） 按優(yōu)先級(jí)對(duì)需求排序（見原則 50），以便開發(fā)人員了解它 們的相對(duì)重要性。（2） 根據(jù)需求的優(yōu)先級(jí)獎(jiǎng)勵(lì)開發(fā)人員（例如，所有高優(yōu)先級(jí)的 需求必須完成；每完成一個(gè)中優(yōu)先級(jí)的需求，開發(fā)人員可 獲得一些額外的小獎(jiǎng)勵(lì)；每完成一個(gè)低優(yōu)先級(jí)的需求，可 獲得的獎(jiǎng)勵(lì)非常小）。（3） 對(duì)逾期交付實(shí)行嚴(yán)厲的處罰。

       原則 7 要快速地開發(fā)一次性原型 

       BUILD THROWAWAY PROTOTYPES QUICKLY 

       如果你已經(jīng)決定開發(fā)一次性原型，那么就要用最快的方式。不用擔(dān)心質(zhì)量。可使用“一頁(yè)紙”的需求規(guī)格說明。不用擔(dān)心設(shè)計(jì)或編碼中的文檔。可以使用任何工具。可以使用任何編程語(yǔ)言，只要能夠方 便程序的快速開發(fā)。不用擔(dān)心編程語(yǔ)言的可維護(hù)性。

       原則 8 看到越多，需要越多 

       THE MORE SEEN, THE MORE NEEDED 

       在軟件行業(yè)，一次次見證了：提供給用戶的功能（或性能）越多， 用戶想要的功能（或性能）就越多。當(dāng)然，這與原則 7（盡早把產(chǎn)品 交給客戶）、原則 14（漸進(jìn)地?cái)U(kuò)展系統(tǒng)）、原則 185（軟件會(huì)持續(xù)變化） 以及原則 201（系統(tǒng)的存在促進(jìn)了演變）互相支持。但更重要的是， 你必須為不可避免的情況做好準(zhǔn)備。在管理和工程處理流程的每個(gè)方 面都應(yīng)該做好準(zhǔn)備，一旦用戶看到產(chǎn)品，他們就會(huì)想要更多的東西。這意味著，所產(chǎn)生的每個(gè)文檔都應(yīng)該以有利于更改的方式進(jìn)行存 儲(chǔ)和組織。這意味著，配置管理流程（見原則 174）必須在距離交付很長(zhǎng)時(shí)間之前就就位。這也意味著，在軟件部署后不久，你就應(yīng)該準(zhǔn)備好，以應(yīng)對(duì)用戶口頭或書面請(qǐng)求的沖擊。這還意味著，你選擇的設(shè)計(jì)方案應(yīng)使容量、輸入速率和功能都很容易變更。

       原則 9 只要可能，購(gòu)買而非開發(fā)

       IF POSSIBLE, BUY INSTEAD OF BUILD 

       要降低不斷上漲的軟件開發(fā)成本和風(fēng)險(xiǎn)，最有效的方法就是，購(gòu)買現(xiàn)成的軟件，而不是自己從頭開發(fā)。確實(shí)，現(xiàn)成的軟件也許只能解 決 75% 的問題。但考慮一下從頭開發(fā)的選擇吧：支付至少 10 倍于購(gòu)買軟件的費(fèi)用，且要冒著超出預(yù)算 100% 且延期的風(fēng)險(xiǎn)（如果最后能 夠完成！），并且最終發(fā)現(xiàn)，它只能滿足 75% 的預(yù)期。對(duì)一個(gè)客戶來說，新的軟件開發(fā)項(xiàng)目似乎最初總是令人興奮的。開發(fā)團(tuán)隊(duì)也是“樂觀的”，對(duì)“最終”解決方案充滿了希望。但幾乎 很少有軟件開發(fā)項(xiàng)目能夠順利運(yùn)行。不斷增加的成本通常會(huì)導(dǎo)致需求 被縮減，最終研發(fā)出的軟件可以滿足的需求也許跟現(xiàn)成的軟件差不多。作為一個(gè)開發(fā)者，應(yīng)該復(fù)用盡可能多的軟件。復(fù)用是“購(gòu)買而非開發(fā)” 原則在較小范圍內(nèi)的體現(xiàn)。可參考原則 84。

       原則 10 技術(shù)優(yōu)先于工具 

       TECHNIQUE BEFORE TOOLS 

       一個(gè)沒規(guī)矩的木匠使用了強(qiáng)大的工具，會(huì)變成一個(gè)危險(xiǎn)的沒規(guī)矩 的木匠。一個(gè)沒規(guī)矩的軟件工程師使用了工具，會(huì)變成一個(gè)危險(xiǎn)的沒 規(guī)矩的軟件工程師。在使用工具前，你應(yīng)該先要“有規(guī)矩”（即理解 并遵循適當(dāng)?shù)能浖�開發(fā)方法）。當(dāng)然，你也要了解如何使用工具，但 這和“有規(guī)矩”相比是第二位的。我強(qiáng)烈建議，在投資于工具以對(duì)某項(xiàng)技術(shù)“自動(dòng)化”之前，先 手工驗(yàn)證這項(xiàng)技術(shù)，并說服自己和管理層：這項(xiàng)技術(shù)是可行的。在 大多數(shù)情況下，如果一項(xiàng)技術(shù)在手工操作時(shí)不靈，那么在自動(dòng)操作 時(shí)也不靈。

       原則 11 跟風(fēng)要小心 

       FOLLOW THE LEMMINGS WITH CARE 

       即使有五千萬人說傻話，那仍然是傻話。 

       安那托爾·佛朗士（Anatole France） 

       大家都做的事情，對(duì)你來說也不一定是正確的。也許它是正確的， 但你也應(yīng)該評(píng)估它對(duì)你所處環(huán)境的適用性。這樣的例子包括：面向?qū)?象，軟件度量（見原則 142、143、149、150 和 151），軟件復(fù)用（見 原則 84），過程成熟度（見原則 163），計(jì)算機(jī)輔助軟件工程（CASE， 見原則 22 至 25），原型設(shè)計(jì)（見原則 11、12、13、42）。在所有案 例中，以上這些方法都提供了非常積極的幫助，體現(xiàn)在提高質(zhì)量、降 低成本、提高用戶滿意度等方面。然而，這些好處只在它們能發(fā)揮作 用的組織中才會(huì)顯現(xiàn)出來。盡管回報(bào)顯著，但是它們的作用常常被過 度宣傳，其實(shí)它們并不是那么必然或通用。當(dāng)你學(xué)習(xí)“新”技術(shù)時(shí)，不要輕易接受與之相關(guān)的不可避免的 炒作（見原則 129）。要仔細(xì)閱讀，理性考慮它的收益和風(fēng)險(xiǎn)。在大 規(guī)模應(yīng)用之前要進(jìn)行試驗(yàn)。但同時(shí)也絕對(duì)不要忽略“新”技術(shù)（見 原則 31）。

       Davis, A., "Software Lemmingineering," IEEE Software, 10, 6 (September 1993), pp. 79-81, 84.

       類似的原則還有很多，以上內(nèi)容摘自《201 Principles of Software Development》中文版，書名是《軟件開發(fā)的201個(gè)原則》。

       給中國(guó)軟件工程師的寄語(yǔ)

       （節(jié)選）

       致我的兄弟姐妹們：

       和你們一樣，我的職業(yè)生涯始于軟件工程師，那是1975年，將近半個(gè)世紀(jì)之前。我認(rèn)為我們?cè)跁r(shí)間和國(guó)家方面的差異相當(dāng)微不足道。所以，我像和我的朋友、我的同齡人一樣與你交談。

       26 年后的今天，當(dāng)我審視201 Principles of Software Development中的這201 條原則時(shí)，我很高興地宣告，幾乎所有的原則都經(jīng)受住了時(shí)間的考驗(yàn)，就像物理學(xué)中的基本原理一樣。

       當(dāng)你做軟件架構(gòu)設(shè)計(jì)或“拋出代碼”時(shí)，不要忽視真正重要的事情。那是什么呢？是你的正直，這是你對(duì)自己的看法。如果有人要求你做一些你知道是錯(cuò)誤的事情，你有義務(wù)阻止它。

       軟件工程是一個(gè)美妙的職業(yè)，它使你能夠進(jìn)入數(shù)百個(gè)以軟件為支柱的專業(yè)領(lǐng)域。

        “生生不息，繁榮昌盛。”好好享受！

       201 Principles of Software Development 作者   Alan M.Davis

       2021年9月

       全書共9 章，第1章為引言，后面8章將201個(gè)軟件工程的原則劃分為8個(gè)大的類別：一般原則、需求工程原則、設(shè)計(jì)原則、編碼原則、測(cè)試原則、管理原則、產(chǎn)品保證原則和演變?cè)瓌t。甚至你可以在空白處寫上簡(jiǎn)單的，聰明的你認(rèn)為的“原則”。

       本文由培訓(xùn)無憂網(wǎng)長(zhǎng)沙牛耳教育課程顧問老師整理發(fā)布，希望能夠?qū)ο朐陂L(zhǎng)沙參加影視動(dòng)漫培訓(xùn)的學(xué)生有所幫助。更多課程信息可關(guān)注培訓(xùn)無憂網(wǎng)電腦IT培訓(xùn)頻道或添加老師微信：15033336050

      注：尊重原創(chuàng)文章,轉(zhuǎn)載請(qǐng)注明出處和鏈接 http://www.hebeijilong.cn/news-id-13962.html 違者必究！部分文章來源于網(wǎng)絡(luò)由培訓(xùn)無憂網(wǎng)編輯部人員整理發(fā)布,內(nèi)容真實(shí)性請(qǐng)自行核實(shí)或聯(lián)系我們，了解更多相關(guān)資訊請(qǐng)關(guān)注程序開發(fā)頻道查看更多，了解相關(guān)專業(yè)課程信息您可在線咨詢也可免費(fèi)申請(qǐng)?jiān)囌n。關(guān)注官方微信了解更多：150 3333 6050