需求設計與反省

需求設計與反省 最近面試遇到些需要我描述 SA 或是 SD 的工作經驗描述，發現我講得的零零落落的，不然就是根本忘了，故挑幾點印象比較深刻做文字整理，以便以後需要的時候可以回來這裡回想。 郵局信箱與招領 所有信箱都來自實際存在的地址，在第一次申請(141)建立可投遞的信箱維護所有基本資料(姓名、電話等等…)依賴信箱主檔與客戶基本檔。 實際投遞遇到問題或是租戶自行申請將影響信箱狀態變更(142 狀態如:續租或暫停使用等等…)，影響信箱生命存續終止(145、146 如退租、屆期未續、轉空戶)。 若通訊地址有更改請先執行維護信箱交易(154 調整為改投或i郵箱)再執行退租，此時的通訊地址才會正確。 由多個交易可以看出信箱的所有狀態與存續的的生命週期。 所有變更資料面依賴信箱主檔、變更歷程寫入 BoxChange_LG(變更歷程)且幾乎所有報表查詢都會依賴變更歷程的最新一筆。 大量的計算邏輯(報表 781、782…)有大量的 sql 重複查詢，其實就是不同的查詢條件，可以彙總成共用 lib 抽離不同件數計算邏輯，不需要每個欄位都一個複雜又重工的 sql 指令。 反省: 礙於專案時程壓力，只好先寫寫看在再回過頭看需求細節的真實用意，其實很危險，很多姑且先寫寫看的功能，都會在終於懂得哪一刻發現很多多此一舉的地方，甚至在 QA 深入各個交易互測階段發現一些明顯邏輯不通的錯誤。 如果可以先了解欄位/物件真義，再進行開發還是比較好，但就是會需要說服 SA 把其他相關的交易規格都拿到，即便是大致掃一眼也是好的。 個資軌跡 h 銀行 個資軌跡交易類別，依 dal 實際邏輯做 function 做預設值參考，服務可以傳入參數強制改為要或不要寫入個資軌跡。 trackType比如: 查詢(新增/修改/刪除交易的查詢、新增 、修改 、刪除 等等。 db Entity 新增 annotation 註記不同機敏程度的代號，透過共用的 Repositary 層偵測更新的 model 牽涉機敏欄位多寡來記錄個資軌跡，並抽離以方便維護是否紀錄的邏輯 if (A_TypeCount >= 2 || (A_TypeCount >= 1 && B_TypeCount >= 1)) return 則記錄個資軌跡; 反省: 資料面攔截所有系統的機敏軌跡，但忽略列的業務邏輯層建立的 dto 也有個資，dal 可以寫入的內容有限，只能記錄自定義的 trackType 且依賴回傳的 TEntity result，如果回傳結果有多層 entities 結構，無法紀錄深層機敏資料( 多層 Entity 結構 )且會顯示 Expression Tree (LINQ 原始表達式字串) 無法讀取內容物例如: c.IdNo == value(HuaNan.Service+<>c__DisplayClass3_0).input.IdNo)