原則 1 質量第一 

       QUALITY IS #1 

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

       原則 2 質量在每個人眼中都不同

       QUALITY IS IN THE EYES OF THE BEHOLDER 

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

       原則 3 高質量軟件是可以實現的 

       HIGH-QUALITY SOFTWARE IS POSSIBLE 

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

       原則 4 不要試圖通過改進軟件實現高質量

       DON’T TRY TO RETROFIT QUALITY 

       質量無法通過軟件的改進來獲得。這適用于質量的任何定義：可 維護性、可靠性、適應性、可測試性、安全性等。即使我們在開發過 程中十分努力，使軟件具備高質量也是十分不易的。如果我們不努力， 又怎么可能期望獲得高質量呢？這就是絕不能將“一次性原型”轉換 成產品的主要原因（見原則 11）。

       原則 5 盡早把產品交給客戶

       GIVE PRODUCTS TO CUSTOMERS EARLY 

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

       原則 6 促使開發者與客戶的目標一致 

       ALIGN INCENTIVES FOR DEVELOPER AND CUSTOMER 

       項目經常會因為客戶和開發人員的目標不同（或不兼容）而失敗。一個簡單的案例是，客戶希望在特定日期前獲得特性 1、2、3，而開 發人員希望最大化營收或利潤。為了最大化營收，開發人員可能會嘗 試完整地開發這三個特性，即使會導致項目延期。與此同時，客戶可 能寧愿放棄其中一個特性的一部分功能，只要能按時交付其他特性。為使雙方的目標達成一致，有如下方法：（1） 按優先級對需求排序（見原則 50），以便開發人員了解它 們的相對重要性。（2） 根據需求的優先級獎勵開發人員（例如，所有高優先級的 需求必須完成；每完成一個中優先級的需求，開發人員可 獲得一些額外的小獎勵；每完成一個低優先級的需求，可 獲得的獎勵非常小）。（3） 對逾期交付實行嚴厲的處罰。

       原則 7 要快速地開發一次性原型 

       BUILD THROWAWAY PROTOTYPES QUICKLY 

       如果你已經決定開發一次性原型，那么就要用最快的方式。不用擔心質量。可使用“一頁紙”的需求規格說明。不用擔心設計或編碼中的文檔。可以使用任何工具。可以使用任何編程語言，只要能夠方 便程序的快速開發。不用擔心編程語言的可維護性。

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

       THE MORE SEEN, THE MORE NEEDED 

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

       原則 9 只要可能，購買而非開發

       IF POSSIBLE, BUY INSTEAD OF BUILD 

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

       原則 10 技術優先于工具 

       TECHNIQUE BEFORE TOOLS 

       一個沒規矩的木匠使用了強大的工具，會變成一個危險的沒規矩 的木匠。一個沒規矩的軟件工程師使用了工具，會變成一個危險的沒 規矩的軟件工程師。在使用工具前，你應該先要“有規矩”（即理解 并遵循適當的軟件開發方法）。當然，你也要了解如何使用工具，但 這和“有規矩”相比是第二位的。我強烈建議，在投資于工具以對某項技術“自動化”之前，先 手工驗證這項技術，并說服自己和管理層：這項技術是可行的。在 大多數情況下，如果一項技術在手工操作時不靈，那么在自動操作 時也不靈。

       原則 11 跟風要小心 

       FOLLOW THE LEMMINGS WITH CARE 

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

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

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

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

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

       給中國軟件工程師的寄語

       （節選）

       致我的兄弟姐妹們：

       和你們一樣，我的職業生涯始于軟件工程師，那是1975年，將近半個世紀之前。我認為我們在時間和國家方面的差異相當微不足道。所以，我像和我的朋友、我的同齡人一樣與你交談。

       26 年后的今天，當我審視201 Principles of Software Development中的這201 條原則時，我很高興地宣告，幾乎所有的原則都經受住了時間的考驗，就像物理學中的基本原理一樣。

       當你做軟件架構設計或“拋出代碼”時，不要忽視真正重要的事情。那是什么呢？是你的正直，這是你對自己的看法。如果有人要求你做一些你知道是錯誤的事情，你有義務阻止它。

       軟件工程是一個美妙的職業，它使你能夠進入數百個以軟件為支柱的專業領域。

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

       201 Principles of Software Development 作者   Alan M.Davis

       2021年9月

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

       本文由培訓無憂網長沙牛耳教育課程顧問老師整理發布，希望能夠對想在長沙參加影視動漫培訓的學生有所幫助。更多課程信息可關注培訓無憂網電腦IT培訓頻道或添加老師微信：15033336050

      注：尊重原創文章,轉載請注明出處和鏈接 http://m.hebeijilong.cn/news-id-13962.html 違者必究！部分文章來源于網絡由培訓無憂網編輯部人員整理發布,內容真實性請自行核實或聯系我們，了解更多相關資訊請關注程序開發頻道查看更多，了解相關專業課程信息您可在線咨詢也可免費申請試課。關注官方微信了解更多：150 3333 6050