軟體開發流程圖將一系列步驟、決策和結果轉化為任何人都能在幾秒鐘內讀取的圖表。一段文字需要仔細閱讀才能理解操作順序和改變路徑的條件，而流程圖則以空間化的方式呈現：從這裡開始，執行此操作，檢查該條件，向左或向右分支，一直持續到結束。正是這種空間化表示，使得流程圖在問世七十多年後，仍是軟體工程領域最廣泛使用的圖表工具之一。
本指南涵蓋了在軟體開發環境中閱讀、建立和應用流程圖所需的一切：標準符號及其含義、不同類型的流程圖及其使用時機、可立即複製和渲染的工作範例，以及流程圖如何與其所代表的實際程式碼連接，包括如何自動產生此連接而不是手動繪製。
軟體開發中的流程圖是什麼？
流程圖是一種以標準化符號和箭頭連接的圖表，箭頭指示流程方向，從而表示流程、演算法或工作流程。在軟體開發中，流程圖描繪了程式或流程的邏輯：操作順序、程式做出決策的節點，以及根據這些決策可以採取的不同執行路徑。
流程圖起源於20世紀20年代的工業工程領域，最初用於記錄製造流程。這項技術在20世紀40年代和50年代被正式應用於電腦領域。到了1970年代，隨著結構化程式設計成為標準實踐，流程圖已成為軟體設計文件的核心組成部分。如今，流程圖仍然被廣泛應用於演算法設計、新員工入職文件、業務流程圖繪製以及向非技術利益相關者傳達邏輯等方面，儘管一些更專業的圖表類型（例如UML圖、序列圖和狀態圖）已經取代了流程圖最初的部分功能。
流程圖和製程流程圖有什麼差別？
這些術語經常互換使用，在大多數情況下這並無不妥。但有時也需要區分：流程圖通常表示單一演算法或程式的邏輯，包括程式碼中的決策、循環和分支。而流程圖（或流程流程圖）則較常表示業務流程，即人員、部門或系統之間的活動順序，通常不像程式碼層級流程圖那樣包含細微的決策邏輯。實際上，兩者使用的符號和約定基本上相同，具體使用哪個術語主要取決於受眾和行業慣例，而不是嚴格的技術界限。
流程圖符號：完整參考手冊
流程圖符號均已標準化，以便任何讀者，無論其語言或背景如何，都能正確理解流程圖。下表列出了標準軟體開發流程圖中使用的所有符號：
| 符號 | 三方圈 | 名稱 | 意思 |
|---|---|---|---|
| ⬭ | 橢圓形/圓角矩形 | 終結者（開始/結束） | 標誌著過程的開始或結束。 |
| ▭ | 矩形 | 過程 | 表示一個單獨的步驟、動作或操作 |
| ◇ | 鑽石 | 決定 | 具有兩個或多個可能結果（是/否，真/假）的分支點 |
| ▱ | 平行四邊形 | 輸入輸出 | 表示進入或離開流程的數據 |
| ⬡ | 六邊形 | 準備 | 表示一個設定步驟，例如初始化循環計數器 |
| ▭（附雙邊框） | 預定義流程 | 呼叫一個單獨的、已定義的進程或子程序 | |
| ⬠ | 文件 | 表示列印或產生的文檔 | |
| ○ | 小圓圈 | 連接器 | 連接流程圖中的兩個點，通常用於避免線條交叉。 |
| ▽ | 三角形（尖端向下） | 合併 | 將多條路徑合併為一條路徑 |
| △ | 三角形（尖向上） | 提取 | 將一條路徑拆分成多條路徑 |
| → | 箭頭 | 流線 | 指示製程流程的方向 |
| ⬢ | 頁面外連接器 | 表示內容在另一頁繼續 |
流程圖讀者需要立即識別的兩個符號是矩形（表示流程步驟）和菱形（表示具有多個出口的決策點）。光是這兩個符號就涵蓋了流程圖的大部分內容。橢圓形/圓角終止符表示流程的開始和結束，這就構成了正確閱讀大多數流程圖所需的最基本術語。
軟體開發中常用的流程圖類型
不同類型的流程圖用途各異。如果選擇錯誤的流程圖類型，雖然圖表在技術上正確，但卻難以閱讀。
| 流程圖類型 | 它顯示了什麼 | 最適合用於 |
|---|---|---|
| 處理流程圖 | 單一流程中的連續步驟 | 記錄演算法、函數邏輯或業務流程 |
| 系統流程圖 | 資料如何在硬體和軟體元件中傳輸 | 高階架構文件、遺留系統映射 |
| 泳道（跨職能）流程圖 | 依負責人（個人、團隊或系統）分組的步驟 | 涉及多個角色或部門的流程 |
| 資料流程圖（DFD） | 資料如何在流程、儲存和外部實體之間流動 | 記錄資料轉換而非控制邏輯 |
| 工作流程圖表 | 業務流程中的任務交接與審核鏈 | 專案管理、審核流程、工單路由 |
| UML活動圖 | 使用正式的UML表示法表示並發和順序活動 | 物件導向軟體設計文檔 |
資料流程圖與流程圖：有什麼不同？
這是最容易造成混淆的地方之一，值得直接解答。流程圖展示的是控制流程：步驟的執行順序以及決定執行路徑的條件。資料流程圖（DFD）展示的是資料流：資料的來源、轉換過程、儲存位置以及最終去向，但不一定顯示操作的順序或決策邏輯。
流程圖回答「發生了什麼，按什麼順序，在什麼條件下？」資料流程圖回答「這些資料來自哪裡，是什麼改變了它，以及它最終流向哪裡？」許多實際系統都能從中受益：流程圖用於記錄處理邏輯，資料流程圖用於記錄資訊如何在邏輯中流動。
軟體開發中的流程圖範例
下面這個 Mermaid 語法可以直接在 GitHub、GitLab、Notion 和大多數現代文件平台中渲染，使其成為將流程圖與程式碼一起進行版本控制的標準方法，而不是將其維護為單獨的靜態影像。
基本流程圖
此流程圖展示了每個開發人員都熟悉的典型模式：以終止符開始，然後是一個流程步驟，一個包含兩個結果的決策菱形，最後收斂到同一個終點。每個流程圖，無論多麼複雜，都是由這種相同模式的重複實例建構而成的。
帶循環的流程圖
流程圖中的循環以箭頭表示，箭頭指向先前的決策點，而不是繼續向前。這相當於流程圖中的循環。 for or while 循環是程式碼中最常見的模式之一，也是入門程式設計課程中最常測試的模式之一，「繪製流程圖以找出三個數字中的最大值」等練習幾乎總是需要循環或嵌套決策結構。
泳道流程圖範例
泳道圖（也稱為跨職能流程圖）依執行人員將流程步驟分組，使團隊或系統之間的交接清晰可見。這種格式是記錄涉及多個部門或外部參與者的業務流程的標準格式。
如何建立軟體開發流程圖
第一步：定義起點和終點。每個流程圖都需要一個清晰的起點和一個或多個清晰的終點。如果您要記錄的流程沒有明顯的起點和終點，則表示流程的範圍尚未明確定義，無法有效地繪製流程圖。
步驟二：依序列出所有步驟。在分配符號之前，先用簡單易懂的語言寫出每個步驟。這樣做可以將邏輯定義與圖表繪製工作分開，更容易發現錯誤。在文字清單中修正缺少的步驟比在半成品圖表中修正快得多。
步驟 3：識別所有決策點。逐條檢查步驟列表，標記出每個下一步操作取決於某個條件的地方。每個決策點都以一個菱形表示，至少有兩個分支路徑，每個分支路徑都必須標註（是/否、真/假或特定條件）。
第四步：分配正確的符號。將每個步驟與其對應的符號對應：矩形代表操作，菱形代表決策，平行四邊形代表輸入/輸出，橢圓形代表開始和結束。符號使用的一致性使得流程圖即使是對特定流程不熟悉的人也能理解。
步驟五：使用方向箭頭連接。每個符號都應有清晰的入點和出點連接（起點和終點除外，起點和終點沒有出點）。箭頭應保持大致一致的方向，通常為自上而下或自左而右，以避免視覺混淆。
步驟 6：透過追蹤每條路徑進行驗證。手動遍歷流程圖，從起點到終點追蹤每一條可能的路徑。確認每個決策分支都指向某個地方，沒有路徑會在沒有到達終點的情況下終止，且循環都有明確的退出條件。
軟體開發流程圖工具
對於手動建立的流程圖，軟體開發工作流程中通常會使用以下幾種工具：
Mermaid和PlantUML都是將流程圖視為程式碼的工具：流程圖以文字形式定義並自動渲染，從而與它所記錄的原始程式碼保持版本同步。對於任何用於記錄程式碼邏輯的流程圖，這都是建議的做法，因為它可以與它所描述的程式碼變更在同一次提交中進行更新。
Lucidchart、Microsoft Visio和draw.io是具有拖放介面的通用圖表繪製工具，適用於業務流程文件、簡報和在版本控制之外維護的圖表。
白板工具（實體白板、Miro、FigJam）適用於協作設計會議，在這種會議中，流程圖是討論期間的工作成果，而不是永久文件。
這些類別之間的權衡在於同步性：在 Lucidchart 或 Visio 中手動維護的圖表會隨著底層流程或程式碼的變更而過時，因為更新圖表需要一個單獨的手動步驟，很容易被遺忘。圖表即程式碼和自動生成都透過將圖表的準確性與自動化流程而非人腦記憶連結起來，解決了這個問題。
從現有程式碼自動產生流程圖
手動繪製新設計的流程圖效果很好。但手動繪製流程圖來記錄一個現有的、複雜的、沒有文件的系統則不適用，而且如果底層程式碼在文件編寫過程中發生更改，那麼最終繪製的流程圖可能已經過時了。
對於現有程式碼庫，特別是大型或遺留系統，自動流程圖產生功能會解析實際原始碼，並直接從其控制流程產生流程圖。 if每個循環、每個函數呼叫都會以對應的流程圖符號的形式呈現，無需人工事先手動追蹤邏輯。
對於遺留系統而言，這種差異尤其重要。一個經過十幾位開發人員二十多年修改的 COBOL 程序，累積了複雜的條件邏輯，以至於沒有人能夠完全理解。如果要手動繪製程式的流程圖，就需要有人逐行閱讀並正確理解，而這正是流程圖所要解決的問題。而從實際原始碼自動產生的流程圖，無論人們對程式的理解程度如何，都能確保流程圖的準確性，因為它基於程式碼的實際功能，而非人們的臆想。
SMART TS XL 從程式碼庫產生流程圖
SMART TS XL 它可以直接從原始碼分析產生流程圖、呼叫圖和依賴關係圖，支援 COBOL、JCL、Java、Python、RPG 等多種語言，無需開發人員手動繪製。這與 Lucidchart 或 Visio 等通用圖表工具有著本質區別，後者雖然提供繪圖畫布，但並不了解程式碼的實際功能。
程式碼視覺化功能可以解析程式的控制流，並自動產生其決策邏輯、分支和循環的精確流程圖。對於累積了數十年條件邏輯的舊版 COBOL 程式而言，這意味著只需片刻即可產生完整且準確的流程圖，而無需耗費數天時間手動閱讀程式碼和繪製流程圖。
由於流程圖直接根據原始程式碼的當前狀態生成，因此不會像手動維護的流程圖那樣出現不同步的情況。每次底層程式發生變更時，重新產生的流程圖都會產生反映當前實際邏輯的更新版流程圖，從而解決了所有依賴手動繪製流程文件的團隊都會遇到的同步問題。
對於負責記錄複雜系統的團隊而言，應用程式依賴關係映射功能超越了單程式流程圖的局限，能夠展示多個程式、作業流程和資料來源如何在整個應用程式組合中相互連接，不僅回答“這個程式做什麼？”，還回答“這個程式連接到什麼，以及什麼又連接到它？”。如同在程式碼視覺化技術部分所述，自動產生的圖表解決了手動維護文件在任何活躍開發系統中因資訊過時而導致的不可靠性問題。
流程圖是一種溝通工具，而不僅僅是文件。
流程圖的價值不在於圖表本身，而是它能讓所有查看它的人達成共識。如果一個流程圖能夠準確地描繪流程，但在開發、程式碼審查或新員工入職培訓期間卻無人參考，那麼它就只是一份沒有價值的文檔。而一個團隊真正用來討論特殊情況、幫助新員工熟悉不熟悉的模組或辨識缺少的錯誤處理分支的流程圖，才算真正發揮了作用。
流程圖的實用價值取決於其是否保持最新。一張在初始設計階段繪製一次卻從未更新的圖表，一旦程式碼偏離其預期，就會產生誤導，甚至比沒有圖表更糟糕，因為它會給人以虛假的信心。無論是透過「圖即程式碼」實踐將流程圖與程式碼放在同一個程式碼庫中，或是透過自動化產生從程式碼的實際當前狀態導出流程圖，保持流程圖準確性的原則，才是真正能幫助團隊的流程圖與那些過時且無人信任的流程圖之間的區別所在。
