工程師在工作上的挑戰
除了程式碼之外大概就是文件了
如果是「開發新系統」的專案
文件通常會比較有規範
畢竟要驗收
而且大家寄予厚望
但如果是「維護舊系統」的專案
相對沒那麼矚目
要麼沒記錄，要麼寫得自由奔放
我個人長期記錄下來
大概總結出幾點模式
是容易遵守且簡單易懂的
一、解 bug
已有的功能出現錯誤
bug 有分嚴重度、緊急度等
但不影響記錄方式
- 問題描述：敘述發生的情況、時間、裝置、訊息等
- 問題成因：經排查後的肇因
- 解決方式：如何處理，牽涉到系統設計
二、開發功能
原本沒有這項功能，要新增額外的功能
可以是既有的功能優化
也可以是全新的功能
因此可大可小
- 需求描述：說明現況是什麼，理想是什麼
- 系統設計：如何補足現況與理想的差距
三、重構
這是最困難的
不像 bug 與新功能一樣肉眼可見
而且這屬於編碼風格
難以客觀量化
把 1000 行程式碼簡化為 300 行
抽取了 10 個共用方法
統一 100 個變數的命名
就算已經加入數字了還是很抽象
因此可以理解為什麼大部分企業都不在乎這一塊