[經驗談] 開發客製化應用程式的建議和注意事項

這篇也躺在我的私人筆記中很久了，一直都想要寫，也一直都覺得自己經驗還不足。不過永遠都不夠完美，就盡量先將自己的理解寫下來，先放上來讓大家討論，如果未來有其他領悟再繼續更新，也歡迎各位先進批評指教！

關於我

筆者有寫過 Struts, Spring Boot, ASP.NET, ASP.NET Core, Android App, WinForms 等專案，以「專案數量」來說最多的就是 C# WinForms 專案了，幾乎都是小型客製化專案，會使用到 SQLite, SQL Server 等資料庫，也有界接 RS232(SerialPort), WebService, WebAPI, WebSocket, 自訂的 DLL 等，大多數都是拿到需求文件後就開始自行開發、協助安裝、維護，也有需要多人合作的專案。下面說明的是關於專案從頭開始時在筆者開發身涯中的領悟。

有許多專案沒有經過「正統」的規劃流程，大多數是接收到客戶需求，例如將指定路徑的 csv 資料轉換後使用 WebAPI 上傳，有提供一兩個範例檔案，但是沒有辦法做上傳測試。開發完成後大約隔一兩個月客戶再依照說明文件安裝或是可以遠端安裝，遇到問題如果能遠端連線的都好解決，不能的就只能請客戶提供 log 檔案，分析後提供更新程式，然後再次分析 log 文件再次更新...

開發前

需求訪談非常重要，最大的問題往往是因為雙方想法不同，有可能客戶想的很簡單，自己不小心把它變複雜。例如在主要系統外客戶還想要能夠紀錄出現問題時的檢討紀錄，往大的做可以變成表單簽核流程，紀錄錯誤分析、主管確認。但是其實客戶只需要以類似留言版的方式記錄問題和將處理方式留下紀錄即可。當然也有可能客戶想的很簡單，但實際執行起來非常複雜，這時候就很需要經驗了。

雖然很基礎，但是最好能夠和客戶確認:

• 目標執行環境: 作業系統、資料庫種類、需要支援的瀏覽器 等等
• 需要徹底的了解需求: 避免需求有前後矛盾，或是過於複雜的地方，盡可能使用簡單的方式處理，避免無限延伸需求
• 確認需求和流程細節: 有許多「例外情況」或是「已經習慣的例外」是客戶沒有想到或是提及的，例如在當前系統中只能註記是否繳費，但其實客戶的廠商很常發生多繳費或少繳的情況，而目前都是會計額外紀錄在紙本記事本中，在訪談時了解到此情況後也可以評估加入預收款的設計

開發中

筆者一直相信「讓開發快速的方式，就是持續保持程式碼的整潔」，只是礙於專案交付時間，往往會有許多妥協。但是做好這些細節往往能夠省去後面許多時間。本篇主要不是再談論程式碼，不會提及太多程式開發相關的技巧，不過這些也都非常有效。

• 使用版本控制軟體: 現在開發基本上都會使用 git 或是其他版本控制軟體來記錄變更資訊，方便恢復。不只可以記錄編輯資訊、有異地備援(例如使用 Github)、還可以節省空間(不用使用壓縮整個檔案的方式備份)。筆者就有遇過客戶是直接在正式機上的 IIS 站台中編輯程式碼，在維護時都很怕萬一有修改錯誤或誤刪就完蛋了，直接影響到一票人。
• 更多的設定值: 有些需求客戶會說「就每分鐘把 OO 檔案用 XX API 上傳就好了」，像這種筆者一律會把間隔時間、檔案路徑、API 連結等做成設定檔，避免正式環境時又有調整，需要再修改程式。
• 圖形化設定檔: 以桌面應用程式而言，筆者有使用過許多設定檔讓使用者設定，例如 xml, ini, json, yaml 等，但是實際使用的使用者百百種，有許多問題都是因為設定檔設定錯誤造成，如果可以的話最好還是能夠提供圖形介面，筆者在使用 WinForms 時很簡單就把類別反射到 PropertyGrid 上，自動產生對應的設定介面，要產生設定介面不用花費多久的時間，重點是可以使用屬性(Attribute)(類似於 Java 的註解 Annotation)簡單的達成資料限制和防呆，可以省去許多回答和解決問題的時間。並且最好也紀錄修改前和修改後的設定內容，筆者就有遇到下午使用者反映說無法連線，查看修改紀錄才發現凌晨有設定資料被修改，也還好有留下紀錄，能夠快速復原，不然最後都會怪到開發者頭上。
• 少用「魔法數字」，多使用列舉(enum): 如果繳款狀態是 1, 2, 3, 4 不論是未來的自己或是其他同仁都沒有辦法馬上了解，使用列舉的話就可以是 Pending, Completed, Failed, Canceled，方便理解的程度可以說是天差地別。如果有做成圖形化設定介面，選項也建議使用列舉，方便使用者選擇，不用再去翻說明文件找要輸入什麼神秘代號
• 多寫 log: 其實這點有些爭議，不過對於大多數系統而言，只要做好自動刪除過舊的日誌檔案(許多日誌工具都有內建)都沒有什麼問題，筆者在寫 WebAPI 時會將完整的請求和回應記錄下來，在回應時的 Header 中加入追蹤 ID ，方便其他系統界接時快速除錯，不過這樣完整的紀錄就會需要確認客戶的需求和做好資料過濾，以免有其他資安疑慮。
• 建立資料變更紀錄: 與上面 log 不同的是這裡指的是資料庫中的紀錄，建立中介軟體(Middleware)將程式中所有資料變更記錄下來，並且在幾乎每張資料表都會紀錄建立者、建立時間、修改者、修改時間等資訊，方便尋找變更資料的使用者，也避免發生是使用者修改但被誤會是系統錯誤。
• 錯誤處理: 任何輸入的資料都有可能是錯誤的，不符合預期，最好留下紀錄，方便查閱。並且一定要做好防呆和錯誤處理，資料有問題就跳過並提示使用者，如果可以的話這些也可以做成選項，讓使用者選擇是否要限制輸入。
• 比客戶要求的再多寫一些: 前面提到的「更多的設定值」和「圖形化設定檔」都算是「額外」多做的，客戶沒有要求，可能只是還沒有想到，或是其他廠商還沒有這樣做。不過目前開發下來

交付時

• 所有地方都有可能發生問題: 遇到問題時最好要從頭開始檢查，例如檔案位置、網路狀態等，在 Windows 10 以後很常發生應用程式無法在一般權限下存取 C 槽中的檔案，可以先留意無法存取檔案是否是位置的問題。無法連線到主機時也可以確認是否是客戶網路安全規定導致兩台主機無法連線。
• 提供說明文件: 目前筆者在交付的軟體中都會要求要有 word 檔案做簡易的操作說明，如果可以的話最好寫的詳細一些，視情況包含預設資料庫帳號密碼等，因為可能三四年前的軟體都還在使用，客戶詢問時還要去翻程式碼才能了解有點不太方便，也顯得很不專業，另外文件最好可以提供 PDF 檔案，因為用瀏覽器就可以開啟。筆者目前很常遇到就算是使用 WinForms 專案的電腦上也有沒有安裝 Office 軟體，無法開啟 word 檔案。後來筆者的解決方案就是使用 Markdown 撰寫文件，提供一份轉換為 PDF 的檔案，並且在軟體中加入簡易的 Markdown 瀏覽，讓使用者能夠透過 F1 快捷鍵開啟。