資料結構
網路
關係型資料庫管理系統 (RDBMS)
作業系統
Java
MS Excel
iOS
HTML
CSS
Android
Python
C語言程式設計
C++
C#
MongoDB
MySQL
Javascript
PHP
物理學
化學
生物學
數學
英語
經濟學
心理學
社會學
服裝學
法學傳統軟體工程原理
傳統軟體工程原則
對“老式”工程軟體有很多描述。軟體行業在多年的軟體開發過程中積累了許多經驗教訓，並建立了許多原則。本部分透過描述對當今軟體工程原則的一種視角，介紹了貫穿本書其餘部分探討的基本思想。我選擇了一篇題為“軟體工程十五原則”[Davis，1994]的小論文作為基準。這篇論文後來擴充套件成一本書[Davis，1995]，列出了201個原則。儘管標題如此，但這篇文章概述了最重要的30個原則，它也是對軟體行業常識的最佳描述之一。雖然我同意其中的大部分內容，但我認為其中一些內容已經過時。接下來，以斜體字顯示的是戴維斯最重要的30個原則。對於每個前提，我都會討論本書後面介紹的觀點是否支援或與之矛盾。這裡我提出了一些論點，直到後續章節才會得到充分的支援。
優先考慮質量。必須對其進行量化，並制定措施以鼓勵實現。
為手頭的專案定義合適的質量至關重要，但在專案開始時很難做到。因此，現代流程框架的目標是在生命週期的早期儘可能地理解特性、質量、成本和進度之間的權衡。除非獲得這些知識，否則無法指定或控制質量的實現。
建立高質量軟體是可行的。讓客戶參與、原型設計、簡化設計、執行檢查和招聘最優秀的人員都是提高質量的行之有效的方法。該原則在大多數方面都與其他原則重疊。
儘快向消費者提供商品。無論您在需求階段多麼努力地弄清楚消費者想要什麼，唯一能找到他們想要什麼的方法就是向他們提供產品，讓他們試用。
這是現代流程結構的一個關鍵方面，必須有很多方法來保持客戶在整個生命週期中的參與。根據領域的不同，這些技術可能包括演示原型、基於演示的里程碑和 alpha/beta 版本。
在定義標準之前，先弄清楚問題是什麼。大多數工程師在遇到他們認為是問題的事情時，都會急於提出解決方案。在嘗試解決問題之前，請確保您已經考慮了所有選擇，並且沒有被顯而易見的解決方案所迷惑。
該原則指出了傳統需求規範方法的問題。隨著解決方案的發展，問題的引數變得更加明顯。現代流程框架共同努力開發問題和解決方案，直到對問題有足夠的瞭解才能投入全面生產。
考慮多種設計方案。在您就標準達成一致後，您需要檢視許多設計和方法。您應該避免僅因為在需求規範中提到了“架構”而使用它。
這個原則似乎在兩個方面都根植於瀑布式思維：（1）需求優先，而不是架構之後。（2）需求定義包括架構。雖然現代流程鼓勵評估設計方案，但這些活動與需求定義同時發生，並且需求和架構的符號和工件是明確分開的。
使用合適的流程模型。根據公司文化、冒險意願、應用領域、需求的波動性和需求的充分理解程度，每個專案都必須選擇最適合該專案的流程。
沒有放之四海而皆準的流程。我使用“流程框架”一詞來描述一類靈活的流程，而不是一個單一的僵化例項。
對不同階段使用多種語言。許多人認為，最佳開發流程是在整個生命週期中使用相同符號的流程，這是因為我們行業對複雜問題的簡單答案有著無法滿足的需求。如果Ada不是所有這些階段的最佳語言，為什麼軟體工程師要將Ada用於需求、設計和程式碼呢？
這是一個需要記住的關鍵思想。第 6 章描述了流程的原始工件，並給出了可接受的安排和推薦的語言/符號。
將認知距離最小化。為了減少認知距離，軟體的結構應儘可能接近現實世界的結構。
面向物件方法、基於元件的開發和視覺化建模的發展都受到了這一概念的推動。
優先考慮技術而非工具。一個危險的、缺乏紀律的軟體工程師會變成一個擁有工具但仍然缺乏紀律的軟體工程師。雖然這個觀點是正確的，但它忽略了兩個關鍵點：（1）一個紀律嚴明的軟體工程師擁有好的工具，其效率要高於一個沒有好工具的紀律嚴明的軟體專家。（2）自動化是促進、標準化和提供優良方法的最有效策略之一。
在嘗試加速之前先把它做好。使功能程式執行得更快比使快速程式工作要容易得多。在早期編碼過程中，不要擔心最佳化。
這是一個很好的說法。一些軟體專家誤解了它，如下所示：“軟體系統中早期的效能問題是下游危險的明確標誌。”在我知道的每個成功的、非平凡的軟體專案中，效能問題都出現在生命週期的早期。我想說的是，在我所知道的幾乎所有不成熟的架構（特別是大型架構）的最初可執行迭代中，都會出現效能問題。瞭解各種效能權衡需要儘早執行（工作）。僅僅透過檢查來獲得這種理解太困難了。
檢查程式碼。測試比檢查詳細設計和程式碼更能有效地檢測缺陷。對於除最簡單的軟體系統之外的所有系統，該原則的重要性都被誇大了。得益於當今的硬體資源、程式語言和自動化環境，可以在整個生命週期中高效地進行自動化分析和測試。在當今的迭代開發中，持續的和自動化的生命週期測試是必不可少的。
在一般性的、無目標的檢查（與關注已知問題的檢查相反）中，很少發現架構缺陷和全域性設計缺陷。這並不是說所有檢查都沒有價值。當明智地使用並關注已知問題時，檢查在解決問題方面非常有效。但是，鑑於該行業的預設方法是過度檢查，因此該指南不應屬於最重要的 15 個指南。
有效的管理比優越的技術更重要。糟糕的管理不會因為最好的技術而得到補償，而一位稱職的管理者即使資源很少也能取得巨大的成就。良好的管理激勵員工盡最大努力工作，但沒有普遍接受的“正確”管理方法。
憑藉少量預算和時間表，一個強大且管理良好的團隊可以做出非凡的事情。另一方面，優秀的管理和低素質的團隊是相互排斥的，因為一位優秀的經理會吸引、配置和留住一個高質量的團隊。
人是取得成功最重要的因素。擁有必要經驗、才能和培訓的高素質人員的重要性怎麼強調都不為過。在缺乏工具、語言和流程的情況下，合適的人員也能取得成功。使用錯誤的工具、語言和流程的錯誤人員幾乎肯定會失敗。這個原則在優先順序列表中的位置太低了。
謹慎行事。 僅僅因為其他人都在這樣做並不意味著它也適合你。它可能是正確的，但你必須仔細考慮它在你這種情況下的適用性。面向物件、度量、複用、流程最佳化、CASE、原型設計——所有這些技術都有可能提高質量、節省成本並提升使用者滿意度。但這些方法的承諾往往被誇大，其優勢遠非確定或普遍。
這尤其在快節奏的行業中是明智的建議，在快節奏的行業中，技術潮流和進步可能難以識別。在平衡功能、價格和截止日期方面，最新的技術並不一定是最優選擇。
對你的行為負責。當橋樑倒塌時，我們會問：“工程師出了什麼問題？” 即使軟體失敗，我們也很少會這樣問。事實上，在每一個工程領域，最先進的方法都可能導致糟糕的設計，而最原始的方法卻可能產生優秀的解決方案。
這是對第14條的絕佳補充。要取得成功，你需要的不僅僅是好的技術、工具和元件。你還需要優秀的人才、有效的管理和一種學習型文化，這種文化強調持續發展，即使會遇到頻繁且不可避免的中間失敗。
認識到客戶的首要任務。 如果只有10%的功能按時交付，而90%的功能延遲交付，客戶也可能接受。理解客戶的優先順序至關重要，但這必須放在其他利益相關者利益的背景下。“客戶永遠是對的”這一信念可能導致的資金浪費比任何其他信念都多。客戶經常是錯的，尤其是在政府合同領域，但更廣泛地說，每當客戶與系統整合商簽訂合同時都會出現這種情況。
他們看得越多，需求越多。 你提供的功能（或效能）越多，使用者就越想要更多功能（或效能）。這種說法是對的，但這意味著你永遠不應該向使用者展示任何東西。“使用者看得越多，理解得越好”，這句話更貼切。並非所有投資者都只被利潤驅動。他們知道自己的資源有限，也知道開發人員面臨的限制。
必須同步利益相關者的期望，因此展示中間成果是一項高度可見的活動。在現代流程中，軟體專案經理需要客觀的事實來證明不可避免的變更請求是合理的，並平衡成本、功能和風險。
制定一個丟棄一個的計劃。 產品是否完全是新的，這是最重要的關鍵成功因素之一。新的應用程式、系統、介面或演算法很少在第一次使用時就獲得成功。
你應該不打算丟棄一個。相反，你應該旨在將產品從早期原型發展到完全功能的基線。如果你必須丟棄它，那也沒關係，但不要計劃這樣做。過去，對於需要100%定製、尖端軟體開發的專案來說，這可能是明智的建議。如今的軟體系統（至少包括作業系統、DBMS、GUI、網路和中介軟體）中的許多元件已經存在，第一次開發的許多內容都可以重複使用。
建立靈活的設計。 你使用的架構、元件和規範方法必須能夠適應變化。這是一個簡單的陳述，但已被證明非常難以實現。從本質上講，這意味著我們必須預測未來，並構建一個框架來接受尚未完全定義的變化。儘管如此，我完全支援這個想法，因為它對成功至關重要。雖然不可能準確預測未來，但嘗試預測系統生命週期中可能發生的變更型別，是一項有益的風險管理工作，也是成功軟體專案的共同主題。
設計只有在有文件支援的情況下才算完成。 我經常聽到軟體開發人員說：“我已經完成了設計。剩下的只是文書工作。”
這個概念也源於傳統的文件驅動方法，在這種方法中，文件與程式分開維護。使用視覺化建模和高階程式語言，為定義軟體設計而維護單獨的文件通常是低效的。如果高階架構文件編寫清晰簡潔，它們可能非常有用，但設計符號、原始碼和測試基線是工程團隊使用的主要工件。為了更好地利用當今的技術進步，我會將這種方法修改如下：“大多數軟體工件應該是自文件化的。”
2K+ 次檢視
