資料結構
網路
關係資料庫管理系統
作業系統
Java
MS Excel
iOS
HTML
CSS
Android
Python
C 程式設計
C++
C#
MongoDB
MySQL
Javascript
PHP
物理學
化學
生物學
數學
英語
經濟學
心理學
社會學
時尚研究
法律研究優秀軟體工程方法的基本原則
軟體工程是指在建立軟體產品和應用程式時使用系統工程原理。它是一門工程學科，涉及評估使用者需求、軟體設計、開發、測試和維護。
以下是一些優秀的軟體工程基本原則：
更好的需求分析是一種基本的軟體工程技術，它提供了對專案的全面瞭解。最終，對使用者需求的透徹理解透過提供滿足其需求的高質量軟體解決方案為使用者創造價值。
所有設計和實現都應該儘可能簡單，這意味著遵循 KISS（保持簡單，愚蠢）原則。它將程式碼簡化到除錯和維護都變得更容易的程度。
軟體專案成功的最重要方面是在整個開發過程中保持專案的願景。由於對專案有清晰的願景，因此可以正確地開發它。
軟體專案中包含許多功能；所有功能都應使用模組化方法進行設計，以使開發更快更容易。由於這種模組化，功能或系統元件是自包含的。
抽象是關注點分離思想的專門化，用於抑制複雜事物併為客戶/使用者提供簡單性，這意味著它只為使用者提供他們需要的東西並隱藏其餘部分。
三思而後行是軟體工程中必不可少的概念，這意味著在開始實現功能之前，必須首先考慮應用程式架構，因為對專案開發流程的正確計劃會產生更好的結果。
當開發人員組合所有功能時，他或她隨後可能會發現它們不再需要。因此，堅持“永不新增額外功能”的方法至關重要，因為它只實現了真正必要的功能，從而節省了時間和精力。
當其他開發人員處理另一人的程式碼時，他們不應該感到驚訝，也不應該花費時間試圖弄清楚發生了什麼。因此，在關鍵階段改進文件是一種改進軟體專案的絕佳方法。
應該遵守迪米特法則，因為它根據功能分離類並減少耦合（類之間的連線和相互依賴性）。
開發人員應該以滿足通用性原則的方式設計專案，這意味著它不應該侷限於特定的一組案例/功能，而應該不受人為約束的限制，並且能夠為具有特定或一般需求的客戶提供全面的服務。
一致性原則在編碼風格和 GUI（圖形使用者介面）設計中很重要，因為一致的編碼風格使程式碼更容易理解，而一致的 GUI 使使用者更容易學習介面和程式。
如果需要某些東西並且它已經存在，則永遠不要浪費時間；相反，請使用開源以您自己的獨特方式解決它。
持續驗證確保軟體系統滿足其需求併發揮其預期功能，從而提高軟體質量控制。
為了擺脫當前的技術行業狂潮，使用最新的程式設計方法至關重要，以便以最及時和最複雜的方式滿足使用者的需求。
為了擴充套件和處理對軟體應用程式不斷增長的需求，應在軟體工程中保持可擴充套件性。
**關注點分離** - 關注點分離認識到人類需要在受限的環境中運作。根據 G. A. Miller [Miller56]，人類的大腦一次只能處理大約 7 個數據單元。一個單元是一個人已經學會作為一個整體處理的單個想法或概念。儘管人類似乎具有無限的抽象能力，但抽象成為一個有用的工具需要時間和反覆使用；也就是說，作為一個單元發揮作用。
在定義資料結構元件的行為時，通常需要考慮兩個方面：基本功能和資料完整性支援。當儘可能將這兩個關注點分離到不同的客戶端方法集中時，資料結構元件通常更容易使用。如果客戶端文件分別處理這兩個問題，客戶端將受益。單獨考慮核心演算法和資料完整性以及異常處理的更改也有助於實現文件和演算法說明。
關注點分離也很重要，因為另一個原因。為了提高產品的質量，軟體開發人員必須處理複雜的值。我們可以從演算法複雜度的研究中吸取寶貴的教訓。儘管存在使單個可測量變數最大化的有效方法，但需要最佳化多個數量的問題幾乎總是 NP 完全的。雖然這沒有得到證明，但大多數複雜性理論專家認為，多項式時間演算法無法解決 NP 完全問題。
鑑於此，分離不同值的處理似乎是合適的。這可以透過在軟體開發過程中的不同時間處理不同的值來實現，或者透過安排架構使不同的元件負責獲取不同的值來實現。
執行時效率是與其他軟體值發生衝突的一個值的示例。因此，大多數軟體工程師建議將效率視為一個單獨的問題。在建立程式以滿足其他需求後，可以評估和分析執行時間以發現時間在哪裡花費。如果需要，可以使用大部分執行時間的程式碼區域進行更新以減少執行時間。Ken Auer 和 Kent Beck 在 [VCK96，第 19-42 頁] 中的論文“惰性最佳化：高效 Smalltalk 程式設計模式”詳細介紹了這個概念。
**模組化** - 模組化概念是關注點分離原則的一個子集。遵循模組化概念需要根據其功能和職責將軟體分解成元件。Parnas [Parnas72] 撰寫了關於模組化問題的第一批文章之一。[WWW90]，一篇較新的論文，在面向物件的上下文中提供了一種責任驅動的模組化技術。
**抽象** - 抽象原則是一種關注點分離概念的專門化。抽象原則要求將軟體元件的行為與其實現分離。它需要學習從兩個角度檢查軟體和軟體元件：它們做什麼以及它們如何做。
未能將行為與實現分離通常會導致不必要的耦合。例如，在遞迴演算法中，通常會新增其他引數以使遞迴工作。之後，應使用提供其他引數的適當初始值的非遞迴外殼呼叫遞迴。否則，呼叫者將面臨更復雜的行為，這將需要指定其他引數。如果最終將實現切換到非遞迴方法，則需要更改客戶端程式碼。
對於處理抽象，契約式設計是一種關鍵技術。Fowler 和 Scott [FS97] 概述了契約式設計的核心概念。Meyer [Meyer92a] 對該方法提供了最全面的描述。
**變更預期** - 計算機程式是計算機輔助解決問題的解決方案。問題發生在軟體使用者知道的上下文或領域中。該領域指定使用者需要處理的資料型別以及它們之間的關係。
另一方面，軟體工程師熟悉資料抽象技術。他們使用結構和演算法，而無需考慮資料的含義或重要性。軟體開發人員可能會根據圖形和圖形演算法進行構思，而無需賦予頂點和邊具體的含義。
因此，找出問題的自動化解決方案對於軟體工程師及其客戶來說都是一個學習過程。軟體開發人員正在學習客戶端操作的領域。他們還了解客戶的價值觀：哪種資料呈現風格對客戶最有價值，以及哪些型別的資料至關重要並且需要特定的保護措施。
客戶越來越瞭解軟體技術可以帶來的解決方案的廣度。他們也正在學習根據其滿足客戶需求的能力來評估潛在的解決方案。
如果要解決的問題很複雜，那麼在短時間內找到最佳答案是不合理的。另一方面，客戶需要快速響應。大多數情況下，他們不願意等到找到理想的答案。他們希望儘快得到一個可接受的答案；完美可以等待。程式工程師需要了解需求，或者軟體應該如何執行，以便提供及時的解決方案。變更參與的概念承認軟體工程師及其客戶的學習過程的難度。早期應制定初步需求，但應允許在學習發展過程中調整標準。
耦合是轉化的一個重大障礙。如果兩個元件緊密連線，更改一個幾乎肯定需要替換另一個。
內聚性對可變性有積極的影響。當需求發生變化時，內聚元件更容易重用。如果一個元件將多個作業組合到一個包中，那麼在進行修改時幾乎肯定需要將其拆分。
通用性 - 通用性的概念與變更預期概念相關聯。建立不受人為約束和限制的軟體至關重要。使用兩位數的年份數字是人為約束或限制的一個突出示例，這導致了“2000年問題”：將在世紀之交混淆記錄儲存的軟體。儘管兩位數限制當時似乎是可以接受的，但優秀的軟體通常會超出其預期的使用壽命。
將客戶的業務方法更改為自動化軟體作為通用性概念在實踐中的另一個示例。他們通常試圖滿足廣泛的需求，但他們根據其現有行為來識別和表達他們的需求。隨著他們對自動化解決方案能力的瞭解越來越深入，他們開始認識到他們需要什麼，而不是他們目前正在做什麼來滿足這些需求。這種差異類似於抽象差異的概念，但其後果在軟體開發過程的早期就實現了。
分步開發 - Fowler 和 Scott [FS97] 對增量軟體開發方法進行了簡潔而全面的概述。此方法涉及分步構建軟體，例如一次新增一個用例。
使用增量軟體開發方法可以更容易地進行驗證。如果您以少量增量構建軟體，則在進行驗證時只需要處理新引入的功能。如果發現任何錯誤，它們已經被部分隔離，從而使其更容易糾正。
透過精心策劃的增量開發策略，也可以更容易地處理需求變更。為此，規劃必須確定最有可能更改的用例，並將它們放在開發過程的最後。
一致性 - 一致性的概念認識到在熟悉的環境中執行任務更容易。例如，編碼風格是一種以統一的方式編寫程式碼文字的方法。這實現了兩個目標。首先，它使理解程式碼變得更容易。其次，它使程式設計師能夠自動化程式碼輸入所需的一些能力，從而使他們能夠專注於更重要的挑戰。更高級別的一致性包括建立用於處理常見程式設計問題的習慣用法。
2K+ 閱讀量
