程式設計方法論 - 快速指南

---

---

程式設計方法論 - 引言

當開發程式來解決現實生活中的問題，例如庫存管理、工資處理、學生入學、考試成績處理等時，這些程式往往龐大而複雜。分析此類複雜問題、規劃軟體開發和控制開發過程的方法稱為程式設計方法論。

程式設計方法論的型別

軟體開發者中流行著許多型別的程式設計方法論：

程序式程式設計

問題被分解成過程或程式碼塊，每個程式碼塊執行一項任務。所有過程合在一起構成整個程式。它只適用於複雜程度低的較小程式。

示例 - 對於一個執行加法、減法、乘法、除法、平方根和比較的計算器程式，這些操作中的每一個都可以開發成單獨的過程。在主程式中，每個過程都將根據使用者的選擇被呼叫。

面向物件程式設計

在這裡，解決方案圍繞構成問題一部分的實體或物件展開。該解決方案處理如何儲存與實體相關的資料，實體如何執行以及它們如何相互互動以提供一個具有凝聚力的解決方案。

示例 - 如果我們必須開發一個工資管理系統，我們將擁有員工、工資結構、休假規則等實體，解決方案必須圍繞這些實體構建。

函數語言程式設計

在這裡，問題或所需的解決方案被分解成函式單元。每個單元執行自己的任務並且是自給自足的。然後將這些單元縫合在一起以形成完整的解決方案。

示例 - 工資處理可以具有員工資料維護、基本工資計算、總工資計算、休假處理、貸款償還處理等功能單元。

邏輯程式設計

在這裡，問題被分解成邏輯單元而不是功能單元。示例：在學校管理系統中，使用者具有非常明確的角色，例如班主任、科任老師、實驗助理、協調員、學術負責人等。因此，軟體可以根據使用者角色劃分為單元。每個使用者可以擁有不同的介面、許可權等。

軟體開發人員可以選擇一種或多種這些方法的組合來開發軟體。請注意，在討論的每種方法中，都必須將問題分解成更小的單元。為此，開發人員可以使用以下兩種方法中的一種：

• 自頂向下方法
• 自底向上方法

自頂向下或模組化方法

問題被分解成更小的單元，這些單元可以進一步分解成更小的單元。每個單元稱為一個模組。每個模組都是一個自給自足的單元，它擁有執行其任務所需的一切。

下圖顯示了一個示例，說明如何在開發工資處理程式時遵循模組化方法來建立不同的模組。

自底向上方法

在自底向上方法中，系統設計從最低級別的元件開始，然後將這些元件互連以獲得更高級別的元件。此過程持續進行，直到生成所有系統元件的層次結構。但是，在現實場景中，一開始很難知道所有最低級別的元件。因此，自底向上方法僅用於非常簡單的問題。

讓我們看一下計算器程式的元件。

理解問題

典型的軟體開發過程遵循以下步驟：

• 需求收集
• 問題定義
• 系統設計
• 實施
• 測試
• 文件
• 培訓和支援
• 維護

前兩步幫助團隊理解問題，這是獲得解決方案最重要的第一步。負責收集需求、定義問題和設計系統的人員稱為系統分析師。

需求收集

通常，客戶或使用者無法清楚地定義他們的問題或需求。他們對想要什麼只有一個模糊的想法。因此，系統開發人員需要收集客戶需求以瞭解需要解決的問題或需要交付什麼。只有首先了解正在開發解決方案的業務領域，才能對問題進行詳細的理解。一些有助於理解業務的關鍵問題包括：

• 正在做什麼？
• 它是如何完成的？
• 任務的頻率是多少？
• 決策或交易的數量是多少？
• 遇到了什麼問題？

一些有助於收集這些資訊的技巧包括：

• 訪談
• 問卷調查
• 研究現有系統文件
• 分析業務資料

系統分析師需要建立清晰簡潔但全面的需求文件，以便識別SMART（具體、可衡量、已商定、現實且基於時間）需求。未能做到這一點會導致：

• 問題定義不完整
• 程式目標不正確
• 為向客戶交付所需成果而進行的返工
• 成本增加
• 交付延遲

由於需要深入的資訊，需求收集也被稱為詳細調查。

問題定義

收集需求並對其進行分析後，必須清楚地陳述問題陳述。問題定義應明確說明需要解決哪些問題。擁有清晰的問題陳述對於：

• 定義專案範圍
• 保持團隊專注
• 使專案保持正軌
• 驗證在專案結束時是否達到了預期的結果

確定解決方案

通常，編碼被認為是任何軟體開發過程中最關鍵的部分。但是，編碼只是該過程的一部分，如果系統設計正確，實際上可能只需要最少的時間。在設計系統之前，必須為手頭的問題確定一個解決方案。

首先要注意的是，在設計系統時，系統分析師最初可能會提出多個解決方案。但是，最終解決方案或產品只能是一個。在需求收集階段收集到的資料的深入分析可以幫助找到獨特的解決方案。正確定義問題對於找到解決方案也至關重要。

面對多個解決方案的問題時，分析師會使用流程圖、資料流圖、實體關係圖等視覺輔助工具來深入瞭解每個解決方案。

流程圖繪製

流程圖繪製是透過符號和圖表來說明系統中的工作流程和資料流的過程。它是幫助系統分析師確定問題解決方案的重要工具。它直觀地描繪了系統的元件。

以下是流程圖繪製的優點：

• 視覺化表示有助於理解程式邏輯

• 它們充當實際程式編碼的藍圖

• 流程圖對於程式文件很重要

• 流程圖是程式維護過程中的重要輔助工具

以下是流程圖繪製的缺點：

• 複雜的邏輯無法使用流程圖來描述

• 如果邏輯或資料/工作流發生任何更改，則必須完全重新繪製流程圖

資料流圖

資料流圖或DFD是透過系統或子系統的資料流的圖形表示。每個過程都有其自身的資料流，並且存在資料流圖的級別。第0級顯示整個系統的輸入和輸出資料。然後將系統分解成模組，第1級DFD分別顯示每個模組的資料流。如果需要，可以將模組進一步分解成子模組並繪製第2級DFD。

虛擬碼

系統設計完成後，將其移交給專案經理進行實施，即編碼。程式的實際編碼是用程式語言完成的，只有接受過該語言培訓的程式設計師才能理解這種語言。但是，在實際編碼發生之前，程式的基本操作原理、工作流程和資料流是用類似於將要使用的程式語言的符號編寫的。這種符號稱為虛擬碼。

這是一個C++虛擬碼的示例。程式設計師只需要將每個語句轉換成C++語法即可獲得程式程式碼。

識別數學運算

所有對計算機的指令最終都作為機器級別的算術和邏輯運算來實現。這些運算很重要，因為它們：

• 佔用記憶體空間
• 需要時間執行
• 決定軟體效率
• 影響整體軟體效能

系統分析師在確定手頭問題的唯一解決方案時，會嘗試識別所有主要的數學運算。

應用模組化技術

現實生活中的問題複雜且龐大。如果開發了整體解決方案，則會產生以下問題：

• 難以編寫、測試和實施一個大型程式

• 交付最終產品後幾乎不可能進行修改

• 程式維護非常困難

• 一個錯誤可能會使整個系統停止執行

為了克服這些問題，應將解決方案分解成較小的部分，稱為模組。為了便於開發、實施、修改和維護，將一個大型解決方案分解成較小模組的技術稱為程式設計或軟體開發的模組化技術。

模組化程式設計的優點

模組化程式設計具有以下優點：

• 由於每個模組都可以並行開發，因此可以加快開發速度

• 模組可以重複使用

• 由於每個模組都需要獨立測試，因此測試速度更快且更可靠

• 更容易除錯和維護整個程式

• 模組較小且複雜程度較低，因此易於理解

識別模組

識別軟體中的模組是一項令人費解的任務，因為沒有一種正確的方法可以做到這一點。以下是一些識別模組的提示：

• 如果資料是系統中最重要的元素，則建立處理相關資料的模組。

• 如果系統提供的服務多種多樣，則將系統分解成功能模組。

• 如果其他方法都失敗了，則根據您在需求收集階段對系統的理解，將系統分解成邏輯模組。

在編寫程式碼時，為了方便程式設計，每個模組都必須再次分解成更小的模組。這可以使用上面分享的三個技巧結合具體的程式設計規則來實現。例如，對於像 C++ 和 Java 這樣的面向物件程式語言，每個類及其資料和方法可以構成一個模組。

分步解決方案

要實現模組，必須分步驟描述每個模組的流程。可以使用演算法或虛擬碼來開發分步解決方案。提供分步解決方案具有以下優點：

• 任何閱讀解決方案的人都能夠理解問題和解決方案。

• 程式設計師和非程式設計師都能同樣理解。

• 在編碼過程中，只需要將每個語句轉換為程式語句。

• 它可以作為文件的一部分，並有助於程式維護。

• 識別符號名稱、所需的操作等微觀細節會自動確定。

讓我們來看一個例子。

控制結構

正如你在上面的例子中看到的，程式邏輯並不一定順序執行。在程式語言中，控制結構根據給定的引數決定程式的流程。它們是任何軟體中非常重要的元素，必須在任何編碼開始之前識別出來。

演算法和虛擬碼幫助分析人員和程式設計師識別需要控制結構的地方。

控制結構有以下三種類型：

決策控制結構

當要執行的下一步取決於某個條件時，使用決策控制結構。這個條件通常是一個或多個必須評估的布林表示式。布林表示式總是計算結果為“真”或“假”。如果條件為“真”，則執行一組語句；如果條件計算結果為“假”，則執行另一組語句。例如，if 語句。

選擇控制結構

當程式序列取決於特定問題的答案時，使用選擇控制結構。例如，一個程式為使用者提供了許多選項。接下來要執行的語句將取決於選擇的選項。例如，switch語句、case語句。

重複/迴圈控制結構

當需要多次重複一組語句時，使用重複控制結構。重複的次數可能在開始之前就知道，也可能取決於表示式的值。例如，for語句、while語句、do while語句等。

正如你在上圖中看到的，選擇結構和決策結構在流程圖中的實現方式類似。選擇控制只不過是一系列按順序執行的決策語句。

以下是一些來自程式的例子，展示這些語句是如何工作的：

編寫演算法

必須遵循的一組有限步驟來解決任何問題稱為演算法。演算法通常在實際編碼之前開發。它使用類似英語的語言編寫，即使是非程式設計師也能輕鬆理解。

有時演算法使用虛擬碼編寫，即類似於將要使用的程式語言的語言。編寫用於解決問題的演算法具有以下優點：

• 促進團隊成員之間的有效溝通

• 能夠分析手頭的問題

• 作為編碼的藍圖

• 協助除錯

• 成為軟體文件的一部分，以便在維護階段將來參考

以下是良好且正確的演算法的特徵：

• 有一組輸入

• 步驟是唯一定義的

• 有有限數量的步驟

• 產生所需的輸出

演算法示例

讓我們首先以現實生活中的例子來建立演算法。以下是去市場購買鋼筆的演算法。

此演算法中的步驟 4 本身就是一個完整的任務，可以為此編寫單獨的演算法。現在讓我們建立一個演算法來檢查數字是正數還是負數。

流程圖元素

流程圖是程式邏輯步驟序列的圖解表示。流程圖使用簡單的幾何形狀來描述過程，並使用箭頭來顯示關係和過程/資料流。

流程圖符號

這是一個圖表，其中包含一些繪製流程圖中常用的符號。

開發流程圖的指導原則

在開發流程圖時，需要記住以下幾點：

• 流程圖只能有一個開始符號和一個停止符號

• 頁面內連線符用數字引用

• 頁面外連線符用字母引用

• 過程的總體流程是從上到下或從左到右

• 箭頭不應交叉

流程圖示例

以下是去市場購買鋼筆的流程圖。

以下是計算兩個數字平均值的流程圖。

使用清晰的指令

眾所周知，計算機本身沒有智慧；它只是遵循使用者給出的指令。指令是計算機程式以及軟體的構建塊。給出清晰的指令對於構建成功的程式至關重要。作為程式設計師或軟體開發人員，你應該養成編寫清晰指令的習慣。以下有兩種方法可以做到這一點。

表示式的清晰度

程式中的表示式是運算子和運算元的序列，用於進行算術或邏輯計算。以下是一些有效表示式的示例：

• 比較兩個值
• 定義變數、物件或類
• 使用一個或多個變數進行算術計算
• 從資料庫檢索資料
• 更新資料庫中的值

編寫明確的表示式是每個程式設計師都必須培養的一項技能。編寫此類表示式時，請記住以下幾點：

明確的結果

表示式的計算必須給出一個明確的結果。例如，應謹慎使用一元運算子。

避免複雜的表示式

不要試圖在一個表示式中完成許多事情。一旦事情開始變得複雜，就將其分解成兩個或多個表示式。

指令的簡潔性

不僅對於計算機，你還需要編寫清晰的指令。稍後閱讀程式的任何人（甚至你自己！）都應該能夠理解指令試圖實現的目標。程式設計師在一段時間後重新訪問自己的程式時無法理解自己的程式的情況非常普遍。這表明此類程式的維護和修改將非常困難。

編寫簡單的指令有助於避免此問題。以下是一些編寫簡單指令的技巧：

• 避免巧妙的指令——如果沒有人能夠正確理解，巧妙的指令以後可能看起來並不那麼巧妙。

• 每個指令執行一個任務——試圖一次做多件事會使指令複雜化。

• 使用標準——每種語言都有其標準，請遵循它們。記住，你並不是獨自一人從事該專案；請遵循專案的編碼標準和指南。

正確的程式設計技術

在本章中，我們將介紹如何編寫良好的程式。但在我們這樣做之前，讓我們看看良好程式的特徵：

• 可移植性——程式或軟體應該在所有相同型別的計算機上執行。相同型別是指為個人計算機開發的軟體應該在所有 PC 上執行。或者為平板電腦編寫的軟體應該在所有具有正確規格的平板電腦上執行。

• 效率——快速完成指定任務的軟體被稱為高效軟體。程式碼最佳化和記憶體最佳化是提高程式效率的一些方法。

• 有效性——軟體應該有助於解決手頭的問題。能夠做到這一點的軟體被稱為有效的軟體。

• 可靠性——程式應該在每次給定相同輸入集時都給出相同的輸出。

• 使用者友好性——程式介面、可點選的連結和圖示等應該使用者友好。

• 自文件化——任何程式或軟體，由於使用了明確的名稱，其識別符號名稱、模組名稱等都可以描述自身。

以下是一些編寫良好程式的方法。

正確的識別符號名稱

標識任何變數、物件、函式、類或方法的名稱稱為識別符號。使用正確的識別符號名稱可以使程式自文件化。這意味著物件的名稱將說明它做什麼或儲存什麼資訊。讓我們來看一下這個 SQL 指令的例子

看看第 10 行。它告訴任何閱讀程式的人都需要選擇學生的 ID、姓名和學號。變數的名稱使這一點不言自明。以下是一些建立正確的識別符號名稱的技巧：

• 使用語言指南

• 不要羞於使用長名稱來保持清晰

• 使用大寫和小寫字母

• 即使語言允許，也不要給兩個識別符號賦予相同的名稱

• 即使識別符號具有互斥的作用域，也不要給多個識別符號賦予相同的名稱

註釋

在上圖中，看看第 8 行。它告訴讀者接下來的幾行程式碼將檢索需要生成成績單的學生列表。此行不是程式碼的一部分，而只是為了使程式更使用者友好。

程式中未被編譯，而是作為程式設計師註釋或解釋的表示式稱為註釋。請看以下程式段中的註釋。註釋以 // 開頭。

註釋可以插入到：

• 程式的序言部分，解釋其目的

• 邏輯或功能塊的開頭和/或結尾

• 記錄特殊情況或異常

應避免新增多餘的註釋，因為這可能會適得其反，在閱讀程式碼時打斷程式碼流程。編譯器可能會忽略註釋和縮排，但讀者往往會閱讀每一個註釋。

縮排

文字距離左右邊距的距離稱為縮排。在程式中，縮排用於分隔邏輯上分開的程式碼塊。這是一個縮排程式段的示例

如您所見，縮排的程式更容易理解。從for迴圈到if以及返回for的控制流程非常清晰。縮排在控制結構中尤其有用。

插入空格或空行也是縮排的一部分。以下是一些您可以也應該使用縮排的情況：

• 程式中邏輯或功能程式碼塊之間的空行

• 運算子周圍的空格

• 新控制結構開頭的製表符

程式設計方法 - 除錯

識別並從程式或軟體中刪除錯誤的過程稱為除錯。除錯理想情況下是測試過程的一部分，但在實際中，它在程式設計的每個步驟中都會進行。程式設計師應該在繼續之前除錯他們最小的模組。這減少了在測試階段出現的錯誤數量，並顯著減少了測試時間和工作量。讓我們來看一下程式中可能出現的錯誤型別。

語法錯誤

語法錯誤是程式中的語法錯誤。每種語言都有自己的一套規則，例如建立識別符號、編寫表示式等，用於編寫程式。當違反這些規則時，這些錯誤被稱為語法錯誤。許多現代整合開發環境可以在您鍵入程式時識別語法錯誤。否則，將在您編譯程式時顯示。

在這個程式中，變數 prod 沒有宣告，編譯器會丟擲此錯誤。

語義錯誤

語義錯誤也稱為邏輯錯誤。語句沒有語法錯誤，因此它將被正確編譯和執行。但是，它不會給出預期的輸出，因為邏輯不正確。讓我們來看一個例子。

看第 13 行。在這裡，程式設計師想要檢查除數是否為 0，以避免被 0 除。但是，使用了賦值運算子 =，而不是比較運算子 ==。現在，每次“if 表示式”都將計算為 true，程式將輸出“您不能除以 0”。肯定不是預期的結果！！

邏輯錯誤無法被任何程式檢測到；當未達到預期輸出時，程式設計師必須自己識別它們。

執行時錯誤

執行時錯誤是在執行程式時發生的錯誤。這意味著程式沒有語法錯誤。程式可能會遇到的一些最常見的執行時錯誤包括：

• 無限迴圈
• 被 '0' 除
• 使用者輸入錯誤的值（例如，輸入字串而不是整數）

程式碼最佳化

任何修改程式碼以提高其質量和效率的方法都稱為程式碼最佳化。程式碼質量決定了程式碼的壽命。如果程式碼可以長期使用和維護，從一個產品延續到另一個產品，則其質量被認為是高的，並且具有更長的壽命。相反，如果一段程式碼只能短期使用和維護，例如直到某個版本有效，則其質量被認為是低的，並且壽命較短。

程式碼的可靠性和速度決定了程式碼效率。程式碼效率是確保軟體高效能的重要因素。

程式碼最佳化有兩種方法：

• 基於直覺的最佳化 (IBO) - 程式設計師嘗試根據自身的技能和經驗來最佳化程式。這可能適用於小型程式，但隨著程式複雜性的增加，它會慘敗。

• 基於證據的最佳化 (EBO) - 使用自動化工具找出效能瓶頸，然後相應地最佳化相關部分。每種程式語言都有自己的一套程式碼最佳化工具。例如，PMD、FindBug 和 Clover 用於最佳化 Java 程式碼。

程式碼針對執行時間和記憶體消耗進行了最佳化，因為時間是稀缺的，而記憶體是昂貴的。兩者之間必須取得平衡。如果時間最佳化增加了記憶體負載，或者記憶體最佳化使程式碼變慢，則最佳化的目的將丟失。

執行時間最佳化

最佳化程式碼的執行時間對於向用戶提供快速服務是必要的。以下是一些執行時間最佳化的技巧：

• 使用具有內建執行時間最佳化的命令

• 使用 switch 代替 if 條件

• 最大限度地減少迴圈結構中的函式呼叫

• 最佳化程式中使用的資料結構

記憶體最佳化

如您所知，資料和指令會消耗記憶體。當我們說資料時，它也指表示式結果的中間資料。我們還需要跟蹤有多少指令構成程式或我們嘗試最佳化的模組。以下是一些記憶體最佳化技巧：

• 使用具有內建記憶體最佳化的命令

• 最大限度地減少需要儲存在暫存器中的變數的使用

• 避免在多次執行的迴圈內宣告全域性變數

• 避免使用 CPU 密集型函式，例如 sqrt()

程式文件

任何書面文字、插圖或影片，用於向用戶描述軟體或程式，都稱為程式或軟體文件。使用者可以是任何人，從程式設計師、系統分析師和管理員到終端使用者。在不同的開發階段，可能會為不同的使用者建立多個文件。事實上，軟體文件是整個軟體開發過程中一個關鍵的流程。

在模組化程式設計中，文件變得更加重要，因為軟體的不同模組由不同的團隊開發。如果開發團隊以外的任何人想要或需要理解某個模組，良好且詳細的文件將使任務更容易。

以下是一些建立文件的指導原則：

• 文件應該從讀者的角度出發

• 文件應該明確無誤

• 不應該有重複

• 應該使用行業標準

• 文件應該始終保持更新

• 任何過時的文件都應在記錄淘汰後逐步淘汰

文件的優點

以下是提供程式文件的一些優點：

• 跟蹤軟體或程式的所有部分

• 更容易維護

• 開發人員以外的程式設計師可以理解軟體的所有方面

• 提高軟體的整體質量

• 協助使用者培訓

• 確保知識分散，如果人員突然離開系統，可以降低成本和工作量

文件示例

軟體可以有許多型別的文件與之相關聯。一些重要的文件包括：

• 使用者手冊 - 它描述了終端使用者使用軟體的不同功能的說明和步驟。

• 操作手冊 - 它列出並描述了所有正在執行的操作及其相互依賴關係。

• 設計文件 - 它概述了軟體並詳細描述了設計元素。它記錄了諸如資料流圖、實體關係圖等細節。

• 需求文件 - 它列出了系統的所有需求，以及對需求可行性的分析。它可以包含用例、現實場景等。

• 技術文件 - 它是實際程式設計元件（如演算法、流程圖、程式程式碼、功能模組等）的文件。

• 測試文件 - 它記錄測試計劃、測試用例、驗證計劃、驗證計劃、測試結果等。測試是軟體開發中需要大量文件的一個階段。

• 已知錯誤列表 - 每個軟體都有無法刪除的錯誤或錯誤，因為它們要麼發現得太晚，要麼是無害的，要麼糾正它們需要比必要的工作量和時間更多。這些錯誤與程式文件一起列出，以便以後可以刪除它們。它們還可以幫助使用者、實施人員和維護人員啟用錯誤。

程式維護

程式維護是在交付後修改軟體或程式的過程，以實現以下任何結果：

• 糾正錯誤
• 提高效能
• 新增功能
• 刪除過時的部分

儘管普遍認為維護是用來修復軟體上線後出現的錯誤，但實際上，大部分維護工作都涉及向現有模組新增次要或主要功能。例如，向報告中新增一些新資料，向輸入表單中新增新欄位，修改程式碼以合併更改的政府法規等。

維護型別

維護活動可以分為四個類別：

• 糾正性維護 - 在現場實施後出現的錯誤在這裡得到修復。錯誤可能是由使用者自己指出的。

• 預防性維護 - 為避免將來出現錯誤而進行的修改稱為預防性維護。

• 適應性維護 - 工作環境的變化有時需要對軟體進行修改。這稱為適應性維護。例如，如果政府教育政策發生變化，則必須對學校管理軟體的學生成績處理模組進行相應的更改。

• 完善性維護 - 對現有軟體進行更改以合併來自客戶的新要求稱為完善性維護。目標是始終使用最新的技術。

維護工具

軟體開發人員和程式設計師使用許多工具來協助他們進行軟體維護。以下是一些最廣泛使用的工具：

• 程式切片器 - 選擇程式中將受更改影響的部分

• 資料流分析器 - 跟蹤軟體中所有可能的資料流

• 動態分析器 - 追蹤程式執行路徑

• 靜態分析器 - 允許對程式進行一般檢視和總結

• 依賴性分析器 - 協助理解和分析程式不同部分的相互依賴性