檢討源由：使用ASP.NET WebFrom 製作留言板，再慢就一個下午完成吧；這次在公司確認完需求後，我還是花了三天才做完，為什麼？
作業流程：
討論（需求畫面與功能、資料表欄位設計）上班時間一天半
8/8 1:30PM 開始製作，到星期二下午五點才全部確定。
從寫User Case到手繪View到用小畫家View => Use Case實戰效率不高，手繪或劃ERD比較快，確定View用小畫家畫比較明確
開發用上班天數兩天半
遇到狀況：
週三
1. 使用介面設定路由問題，使用1.5hr
遇到錯誤訊息 XML 無法down ....TMSService ...以及另外兩個路由問題
動作
=> 以錯誤訊息較短的第二條和第三條開始, 踢鐵板1hr, 後來才發現第一條TMSService根本不存在。
=> 解決
我多新增了系統資料管理 這裡決定我將使用的Service 和 資料夾名稱
剛剛的錯誤在新增了一個TMS => Service 變成找 TMSService => 沒這個東西
所以修正的方式, TMS為CRMS底下的功能, 應該是改新增在CRMS底下即可
=> 學習 前端問題要從第一條錯誤開始解。
[週三下午5點~周四下午2點半]
2. System.Data.SqlClient.SqlException: 字串或二進位資料會被截斷。使用4.5hr
動作
(1) 開SQL Server追蹤想看產生的sql指令，
突然注意到#TempTable裡的編號為NULL
=> 開始懷疑tag, serial是否可以使用?
=> 結果，使用SN編號產生器，#TempTable不會先產生編號，會在呼叫SPC以後才會有產生
=> 看到null有這個懷疑正確，但針對錯誤訊息的方向是錯誤，此懷疑與錯誤訊息是非相關
(2) 開C#偵錯，用postman測試，發現
=> Postman丟 2016-08-10 21:5:33 進入C#的Service專案會有一句語法
JsonConvert.DeserializeObject<IEnumerable<T>>(option.Modify.Date); 就會變成中文時間
因為C#的JsonConvert轉換JSON傳入的時間時，會依DateTime型別把時間修成 '2016/8/10 下午 10:05:33' (受到中文OS影響)
=> 解決方向:
問Sean得到前端丟JSON可以先轉，所以朝此方向得到JavaScript有 new Date();
自己多嘗試兩種方式 new Date(也是newDate的變數.getTime()); -> 完整的文字版日期時間
自訂日期時間用getFullYear() + get......
自己方向朝改變C#裡面的set方式，想對傳入的日期做String.Format，或是做個轉換器來轉換字串為正確日期格式，此方向錯誤，因為用DateTime型別就已經轉為日期格式。
將類別屬性的DateTime型別改成String宣告，一樣得到二進位截斷問題，開始懷疑不是DateTime問題，可能是其他欄位問題。
(3) 給Elaine看過得到再嘗試方向: 檢查Entity.config、檢查流水編號是否真的要再#TempTable產生時產生？再檢查是否為其他欄位問題
(4) 重新檢查Entity.config，比對最原始的作業Customer，注意到entity裡schemaType用的資料型別值都放大小寫(ex: VarChar 非 VARCHAR)，檢查SQL Server追蹤的sql指令，產生的#TempTable都沒有data_type，以至於insert會有二進位被截斷問題!
(5) 因為#TempTable會依照Entity.config設定產生，而schemaType的大小寫寫錯，以致#TempTable沒有被順利產生，當改好以後，#TempTable順利產生，就沒有二進位被截斷問題。
=> 結果，日期時間應放在資料庫建立，不應該從前端建立回來。所以就在日期欄位被CREATE的時候放入DEFAULT(GETDATE()) 即可，但另一個回覆時間就不能放DEFAULT，要在SPC裡面去被建立。
=> 學習
**因為在C#使用DateTime資料型別所宣告的日期物件，用此物件讓C#對SQL做insert指令是不會有問題的，C#顯示給人看會有中文，但DateTime物件傳遞會是電腦正確的日期格式。
**SN流水號，不會在#TempTable產生時就產生，而是在#TempTable之後會再使用編號產生器SPC後才會產生。
**如果要Entity.config要改資料型別做測試，對應的類別class屬性資料型別也要跟著改。
**寫Code要配合語言特性，該使用大小寫還是照舊，操作系統防呆這件事，是要留給終端使用者，不是開發者。
=> 討論：
日期產生的事情，在Service裡面可以怎麼做。
[週四下午五點~五點半]
3. 使用StatusChange方法失效，使用時間半小時
=> 在類別的狀態屬性上要加上Attribute[Status]，主鍵要加[User]
裡面的程式運作如何使用Attribute未理解
[週五 下午五點半~六點半]
4. 欄位驗證 受到 ng-repeat 影響而失效，使用時間1hr
=> 將ng-form改放在ne-repeat下方 即可對單筆作驗證
[週五 下午五點半]
5. 遇到呼叫SPC有超出變數的問題，使用時間半小時
=> 在Entity.config要給SPC的變數要跟SPC裡面CREATE的變數一樣多。
後面其餘時間都在修版面了
其他提問：size 是一個分頁要顯示多少筆數 == 資料庫要撈出多少筆數
開發作業使用專案有
資料庫Database
Services
AP
作業流程：
討論（需求畫面與功能、資料表欄位設計）上班時間一天半
8/8 1:30PM 開始製作，到星期二下午五點才全部確定。
從寫User Case到手繪View到用小畫家View => Use Case實戰效率不高，手繪或劃ERD比較快，確定View用小畫家畫比較明確
開發用上班天數兩天半
遇到狀況：
週三
1. 使用介面設定路由問題，使用1.5hr
遇到錯誤訊息 XML 無法down ....TMSService ...以及另外兩個路由問題
動作
=> 以錯誤訊息較短的第二條和第三條開始, 踢鐵板1hr, 後來才發現第一條TMSService根本不存在。
=> 解決
我多新增了系統資料管理 這裡決定我將使用的Service 和 資料夾名稱
剛剛的錯誤在新增了一個TMS => Service 變成找 TMSService => 沒這個東西
所以修正的方式, TMS為CRMS底下的功能, 應該是改新增在CRMS底下即可
=> 學習 前端問題要從第一條錯誤開始解。
[週三下午5點~周四下午2點半]
2. System.Data.SqlClient.SqlException: 字串或二進位資料會被截斷。使用4.5hr
動作
(1) 開SQL Server追蹤想看產生的sql指令，
突然注意到#TempTable裡的編號為NULL
=> 開始懷疑tag, serial是否可以使用?
=> 結果，使用SN編號產生器，#TempTable不會先產生編號，會在呼叫SPC以後才會有產生
=> 看到null有這個懷疑正確，但針對錯誤訊息的方向是錯誤，此懷疑與錯誤訊息是非相關
(2) 開C#偵錯，用postman測試，發現
=> Postman丟 2016-08-10 21:5:33 進入C#的Service專案會有一句語法
JsonConvert.DeserializeObject<IEnumerable<T>>(option.Modify.Date); 就會變成中文時間
因為C#的JsonConvert轉換JSON傳入的時間時，會依DateTime型別把時間修成 '2016/8/10 下午 10:05:33' (受到中文OS影響)
=> 解決方向:
問Sean得到前端丟JSON可以先轉，所以朝此方向得到JavaScript有 new Date();
自己多嘗試兩種方式 new Date(也是newDate的變數.getTime()); -> 完整的文字版日期時間
自訂日期時間用getFullYear() + get......
自己方向朝改變C#裡面的set方式，想對傳入的日期做String.Format，或是做個轉換器來轉換字串為正確日期格式，此方向錯誤，因為用DateTime型別就已經轉為日期格式。
將類別屬性的DateTime型別改成String宣告，一樣得到二進位截斷問題，開始懷疑不是DateTime問題，可能是其他欄位問題。
(3) 給Elaine看過得到再嘗試方向: 檢查Entity.config、檢查流水編號是否真的要再#TempTable產生時產生？再檢查是否為其他欄位問題
(4) 重新檢查Entity.config，比對最原始的作業Customer，注意到entity裡schemaType用的資料型別值都放大小寫(ex: VarChar 非 VARCHAR)，檢查SQL Server追蹤的sql指令，產生的#TempTable都沒有data_type，以至於insert會有二進位被截斷問題!
(5) 因為#TempTable會依照Entity.config設定產生，而schemaType的大小寫寫錯，以致#TempTable沒有被順利產生，當改好以後，#TempTable順利產生，就沒有二進位被截斷問題。
=> 結果，日期時間應放在資料庫建立，不應該從前端建立回來。所以就在日期欄位被CREATE的時候放入DEFAULT(GETDATE()) 即可，但另一個回覆時間就不能放DEFAULT，要在SPC裡面去被建立。
=> 學習
**因為在C#使用DateTime資料型別所宣告的日期物件，用此物件讓C#對SQL做insert指令是不會有問題的，C#顯示給人看會有中文，但DateTime物件傳遞會是電腦正確的日期格式。
**SN流水號，不會在#TempTable產生時就產生，而是在#TempTable之後會再使用編號產生器SPC後才會產生。
**如果要Entity.config要改資料型別做測試，對應的類別class屬性資料型別也要跟著改。
**寫Code要配合語言特性，該使用大小寫還是照舊，操作系統防呆這件事，是要留給終端使用者，不是開發者。
=> 討論：
日期產生的事情，在Service裡面可以怎麼做。
[週四下午五點~五點半]
3. 使用StatusChange方法失效，使用時間半小時
=> 在類別的狀態屬性上要加上Attribute[Status]，主鍵要加[User]
裡面的程式運作如何使用Attribute未理解
[週五 下午五點半~六點半]
4. 欄位驗證 受到 ng-repeat 影響而失效，使用時間1hr
=> 將ng-form改放在ne-repeat下方 即可對單筆作驗證
[週五 下午五點半]
5. 遇到呼叫SPC有超出變數的問題，使用時間半小時
=> 在Entity.config要給SPC的變數要跟SPC裡面CREATE的變數一樣多。
後面其餘時間都在修版面了
其他提問：size 是一個分頁要顯示多少筆數 == 資料庫要撈出多少筆數
開發作業使用專案有
資料庫Database
Services
AP
沒有留言:
張貼留言