軟體實現

在本章中，我們將學習軟體實現中的程式設計方法、文件和挑戰。

結構化程式設計

在編碼過程中，程式碼行不斷增加，從而導致軟體大小增加。漸漸地，記住程式流程變得幾乎不可能。如果忘記了軟體及其底層程式、檔案、過程是如何構建的，那麼共享、除錯和修改程式就會變得非常困難。解決方法是結構化程式設計。它鼓勵開發人員使用子程式和迴圈，而不是在程式碼中使用簡單的跳轉，從而使程式碼更清晰並提高效率。結構化程式設計還有助於程式設計師減少編碼時間並正確組織程式碼。

結構化程式設計規定了程式的編碼方式。結構化程式設計使用三個主要概念

• 自頂向下分析 - 軟體總是被設計用來執行一些合理的工作。在軟體術語中，這項合理的工作被稱為問題。因此，瞭解如何解決問題非常重要。在自頂向下分析中，問題被分解成許多小塊，每個小塊都具有一定的意義。每個問題都單獨解決，並明確說明解決問題的方法。

• 模組化程式設計 - 在程式設計過程中，程式碼被分解成更小的指令組。這些組被稱為模組、子程式或子例程。模組化程式設計基於對自頂向下分析的理解。它不鼓勵在程式中使用“goto”語句進行跳轉，這往往會使程式流程難以追蹤。在結構化程式設計中，禁止使用跳轉並鼓勵使用模組化格式。

• 結構化編碼 - 參考自頂向下分析，結構化編碼將模組進一步細分為更小的程式碼單元，並按執行順序排列。結構化程式設計使用控制結構來控制程式流程，而結構化編碼使用控制結構以可定義的模式組織其指令。

函數語言程式設計

函數語言程式設計是一種程式語言風格，它使用數學函式的概念。數學中的函式在接收到相同引數時，應該始終產生相同的結果。在過程式語言中，程式的流程透過過程執行，即程式的控制權轉移到被呼叫的過程。在控制流從一個過程轉移到另一個過程時，程式會改變其狀態。

在程序式程式設計中，當使用相同引數呼叫過程時，它可能會產生不同的結果，因為程式本身在呼叫過程中可能處於不同的狀態。這是程序式程式設計的一個特性也是一個缺點，其中過程執行的順序或時間變得很重要。

函數語言程式設計提供了一種將計算作為數學函式的方式，無論程式狀態如何，它都能產生結果。這使得預測程式的行為成為可能。

函數語言程式設計使用以下概念

• 一等函式和高階函式 - 這些函式能夠接受另一個函式作為引數，或者將其他函式作為結果返回。

• 純函式 - 這些函式不包含破壞性更新，也就是說，它們不影響任何I/O或記憶體，如果它們沒有被使用，則可以很容易地刪除它們而不會影響程式的其餘部分。

• 遞迴 - 遞迴是一種程式設計技巧，其中一個函式呼叫自身並在其中重複程式程式碼，除非某些預定義條件匹配。遞迴是在函數語言程式設計中建立迴圈的方式。

• 嚴格求值 - 這是對作為引數傳遞給函式的表示式的求值方法。函數語言程式設計有兩種型別的求值方法，嚴格（急切）或非嚴格（惰性）。嚴格求值始終在呼叫函式之前對錶達式進行求值。非嚴格求值不會對錶達式進行求值，除非需要。

• λ演算 - 大多數函數語言程式設計語言使用λ演算作為其型別系統。λ表示式透過在它們出現時對其進行求值來執行。

Common Lisp、Scala、Haskell、Erlang和F#是一些函數語言程式設計語言的示例。

程式設計風格

程式設計風格是一套所有程式設計師遵循的編碼規則，用於編寫程式碼。當多個程式設計師在同一個軟體專案上工作時，他們經常需要使用其他開發人員編寫的程式程式碼。如果所有開發人員不遵循一些標準的程式設計風格來編寫程式，這就會變得乏味，有時甚至是不可能的。

合適的程式設計風格包括使用與預期任務相關的函式和變數名、使用適當的縮排、為方便閱讀者而註釋程式碼以及程式碼的整體呈現。這使得程式程式碼易於所有人員閱讀和理解，從而使除錯和解決錯誤更容易。此外，正確的編碼風格有助於簡化文件和更新。

編碼指南

編碼風格的實踐因組織、作業系統和編碼語言本身而異。

以下編碼元素可以在組織的編碼指南中定義

• 命名約定 - 本節定義如何命名函式、變數、常量和全域性變數。

• 縮排 - 這是在行首留出的空格，通常是2-8個空格或單個製表符。

• 空白字元 - 通常在行尾省略。

• 運算子 - 定義編寫數學、賦值和邏輯運算子的規則。例如，賦值運算子“=”應該在其前後留有空格，如“x = 2”。

• 控制結構 - 編寫if-then-else、case-switch、while-until和for控制流語句的規則，包括單獨使用和巢狀使用。

• 行長度和換行 - 定義一行中應該有多少個字元，大多數情況下，一行有80個字元。換行定義瞭如果一行太長，應該如何換行。

• 函式 - 定義如何宣告和呼叫函式，包括帶引數和不帶引數的函式。

• 變數 - 說明如何宣告和定義不同資料型別的變數。

• 註釋 - 這是重要的編碼元件之一，因為程式碼中包含的註釋描述了程式碼的實際作用以及所有其他相關描述。本節還有助於為其他開發人員建立幫助文件。

軟體文件

軟體文件是軟體過程的重要組成部分。編寫良好的文件提供了一個強大的工具和資訊庫，用於瞭解軟體過程。軟體文件還提供有關如何使用產品的資訊。

維護良好的文件應該包含以下文件

• 需求文件 - 該文件作為軟體設計師、開發人員和測試團隊執行各自任務的關鍵工具。該文件包含預期軟體的所有功能、非功能和行為描述。

  該文件的來源可以是先前儲存的有關軟體的資料、客戶端已執行的軟體、客戶端訪談、問卷調查和研究。通常，它以電子表格或文字處理文件的形式儲存在高階軟體管理團隊中。

  該文件作為要開發的軟體的基礎，主要用於驗證和確認階段。大多數測試用例都是直接從需求文件中構建的。

• 軟體設計文件 - 這些文件包含構建軟體所需的所有必要資訊。它包含：(a) 高階軟體架構，(b) 軟體設計細節，(c) 資料流圖，(d) 資料庫設計

  這些文件作為開發人員實現軟體的儲存庫。儘管這些文件沒有提供任何有關如何編寫程式的細節，但它們提供了編碼和實現所需的所有必要資訊。

• 技術文件 - 這些文件由開發人員和實際編碼人員維護。這些文件作為一個整體，代表了有關程式碼的資訊。在編寫程式碼時，程式設計師還會說明程式碼的目標、誰編寫的、在哪裡需要、它做什麼以及如何做、程式碼使用哪些其他資源等。

  技術文件增強了在同一程式碼上工作的不同程式設計師之間的理解。它增強了程式碼的可重用性。它使除錯變得容易且可追溯。

  有各種可用的自動化工具，有些工具隨程式語言本身一起提供。例如，Java提供了Javadoc工具來生成程式碼的技術文件。

• 使用者文件 - 該文件與上述所有文件不同。所有以前的文件都用於提供有關軟體及其開發過程的資訊。但是使用者文件解釋了軟體產品應該如何工作以及如何使用它來獲得期望的結果。

  這些文件可能包括軟體安裝程式、操作指南、使用者指南、解除安裝方法以及獲取更多資訊的特殊參考，例如許可證更新等。

軟體實現挑戰

在軟體實現過程中，開發團隊面臨一些挑戰。其中一些列舉如下：

• 程式碼重用 - 當今程式語言的程式設計介面非常複雜，並配備了大量的庫函式。儘管如此，為了降低最終產品的成本，組織管理層更傾向於重用之前為其他軟體建立的程式碼。程式設計師在相容性檢查以及決定重用多少程式碼方面面臨著巨大的問題。

• 版本管理 - 每次向客戶釋出新軟體時，開發人員都必須維護版本和配置相關的文件。這些文件需要高度準確並及時提供。

• 目標主機 - 組織正在開發的軟體程式需要針對客戶端的宿主機器進行設計。但有時，不可能設計出一個在目標機器上都能正常工作的軟體。