軟體維護

2022年11月18日 in 中國科學院大學

軟體成本60%是維護，軟體維護成本的60%是增強（修複缺陷占17%）

一、四類軟體維護

糾正性維護（修複缺陷）
完善性維護（擴充功能）
适應性維護（變化運作環境）
預防性維護（改變軟體結構提高未來可維護性）

二、遺留代碼重構

遺留代碼：仍滿足使用者需求，但軟體積累了許多沒有被目前設計文檔涵蓋的更新檔（文檔差、時間長、缺少充分測試）
重構：改變代碼結構而不改變軟體功能

問題1：在開發過程中會逐漸偏離原有設計文檔

解決方案：非正式設計文檔
- 高可讀性單元（lo-fi UI、Cucumber、應用架構草圖、類關系）
- Git日志檔案（代碼注釋、設計評審存檔）

問題2:改進遺留代碼？

解決方案：
- a. 編輯并祈禱
- b. 測試覆寫
  - 建立能夠覆寫将要更新代碼的測試
  - 作為安全系統檢查是否引起非計劃行為改變

三、解決方式：靈活方法提供幫助

`｜靈活過程｜`

确定更改點
判斷是否需要重構
- 對更改點代碼測試（被測試了嗎？能測試嗎？）
- 被測試了：可以使用
- 沒被測試但可以測試：使用BDD+TDD提高代碼覆寫率
- 不可測試：重構
根據需要，增加測試、提高覆寫率
進行修改，使用已認證測試作為基石
進一步重構，讓代碼庫變得更好

a. 被配置設定來修改遺留代碼，哪個叙述會讓你最高興？——測試覆寫很好

許多原始的設計文檔都是可用的？——在靈活開發中可能不存在設計文檔

b. 探索遺留代碼：讓代碼run起來

檢出一個分支，在開發環境中運作起來
了解使用者故事
檢查資料庫模式和類關系
- 類-責任-協作者（CRC卡片）：一個卡片确定一個類、它的職責以及與之互動完成任務的協作類
随時保留設計文檔

c. 使用特征/表征測試來建立基準事實

測試用例是代碼現階段完成客觀事實的規範，！但不要在現階段做代碼改進！

內建級别的特性測試：黑盒（使用Cucumber等工具執行指令式場景）

問題：相比于子產品級或單元級特性測試，關于內建級特性測試，錯誤的說法是？——它們較少依賴對代碼結構的詳細了解

d. 如何寫出好的注釋

好的注釋要比代碼有更進階别的抽象（并非指令式告訴其他人代碼執行過程）

四、對代碼評價的定性名額

1. 定性：代碼壞味（SOFA）

Short：代碼短
One：代碼隻做一件事
Few：代碼參數較少
- 參數過多的問題：
  - a.容易造成測試覆寫率不高、狀态空間幾何次元增加（測試用例越來越多）
  - b.功能與其他方法之間的關聯性越高（存根Stub越多）
  - c.若存在bool參數，可能導緻函數分支行為越來越多
Abstraction：抽象級别一緻
- 複雜任務要分成小問題，小問題的封裝程度要好

2. 定量

a. ABC複雜度

計算指派（Assignment）、分支（Branch）、條件（Condition）
score = A2+B2+C2 <= 20

b. 循環複雜度

線性獨立路徑數 CC = E – N + 2P(E：邊, N：節點, P：連接配接元件)
度量名額（僅供參考）

五、重構

1.想法

從有1個或更多問題/壞味的代碼開始
通過一系列的小步驟，轉換成沒有這些壞味的代碼
用測試保護每一步
最小化改變測試為紅色的時間

2.怎樣去做

修複愚蠢的命名
提取方法
提取方法進行類封裝
測試提取的類
關于單元測試的一些想法

SOFA哪個指導原則對單元級測試最重要?參數少(Few)

不是方法級重構的目标?消除錯誤

重構通常會導緻對測試套件的更改(重構需要修改代碼)

六、軟體維護的P&D視角

P&D花費1/3在開發上，2/3在維護上
開發團隊 ≠ 維護團隊

1. 維護流程

a. 在現場/生産現場運作軟體
b. 與客戶協作，與客戶一起改進下一版本
c. 響應變化（變更請求表單有票證跟蹤）

2.對于需求變更

a. 變更控制委員會
b. 緊急變更請求

3.如何判斷改進還是替換/再工程？

當軟體老化，維護困難時，使用自動化工具進行更新

4.維護: P&D與靈活的對比關系

任務	P&D	靈活
客戶變更請求	變更請求表單	3x5卡片上的使用者故事
變更請求成本/ 時間估計	由維護經理	開發團隊評估點數
變更請求分類	變更控制委員會	開發團隊與客戶參與

【軟體維護】靈活開發中的軟體維護問題軟體維護