1. 架構
   1. 使用3-layer架構
      1. 建議
         1. business layer的分析由BU使用domain model來分析，會讓service object更具有意義
      2. 好處
         1. 自動測試可行性與測試品質提高
         2. 針對問題分析後，可快速釐清是哪個layer的問題，再去修改對應的檔案
            1. 需搭配coding rule，註解
            2. 需記錄清楚的log
         3. 維護他人程式碼的時候，比較容易從問題單找到問題，而毋須瞭解整支規格
            1. 例如僅修改Presentation layer呈現的問題
      3. 壞處
         1. 每支程式之間的關係，coding rule需規範清楚
            1. 因為trace code至interface即無法移至定義
   2. 使用Spring.Net
      1. 好處
         1. transaction控制變得容易
         2. Adotemplate的parameter用法簡單，可有效防止SQL injection
         3. rowmapper的部分可達到OR-mapping
         4. Dependency Injection可輕易設計出Strategy Pattern
         5. 內建模組可輕易設計出Factory Pattern
      2. 壞處
         1. 需額外撰寫一些設定檔
         2. 不容易直接看到最後執行的SQL statement
   3. 底層控制項
      1. 好處
         1. 客製化的部分多屬於append，而非modified，Reuse比率高，底層開發時程短
         2. 已經克服公司UI核心元件與AJAX不相容的問題
         3. 共用的部分可統一修改
         4. 開發速度快、維護成本低
      2. 壞處
         1. 開發人員較難提升自身的技術能力
      3. 可以改進的地方
         1. 將客製化需要的js內嵌至dll裡
         2. 特殊驗證可採用AJAX control toolkit的Extender來improve
   4. 參數使用object，也就是DTO的方式傳遞
      1. 好處
         1. 容易擴充
      2. 壞處
         1. 多了很多可能只用一次的object class
         2. 可能會喪失一些OO的優點
2. 開發
   1. 使用C#
      1. 好處
         1. 與java跟javascript的語法比較類似
            1. 新人建議從C#開始學起，C#與js一起學，轉換陣痛可以少一次
      2. 壞處
         1. 公司人員熟悉VB的居多，需有轉換的陣痛
         2. Page的Event無法直接用下拉選單，需手動撰寫
      3. 只懂VB，不懂C#的應變計畫
         1. http://www.developerfusion.com/tools/convert/vb-to-csharp/
   2. client端
      1. 與先前的專案相比需要撰寫的javascript減少很多
         1. 總共僅52個js檔
            1. 一般程式+user control僅15支js檔
      2. 可以改進的地方
         1. 使用jQuery讓UI更Rich
3. 偵錯
   1. Log4Net
      1. 問題
         1. 直接使用log4net，搭配Spring.net會有問題，會抓不到是哪支class哪個method哪一行呼叫logwriter
            1. 因為一開始Spring就會呼叫所有dao的建構式
      2. 解決方式
         1. 從一開始設計時就避開這個問題
         2. 在BaseDao裡，使用system reflection與tracestack，追蹤stack該method是被誰呼叫
      3. feedback
         1. 可手動將adotemplate轉換前的SQL，判斷datatype，自行取代成可執行的SQL statement記錄在log中
   2. Session information on page
      1. 可加快偵錯速度與問題還原的品質
         1. UAT在user side的人員可提供訊息給後端開發人員偵錯
            1. SA或其他user site開發人員可透過SQL log與session快速分析問題癥結點
      2. 會影響些許performance
      3. 可以改進的地方
         1. 可設計在webconfig動態開關此功能
   3. feedback
      1. UAT時可以獲得user site的測試資料與DB schema，可以提高相當高的問題還原速度
         1. 有效解決以往在user site才會發生的問題，在公司卻正常的情況
      2. 定時備份DB schema與資料
         1. 尤其問題單是整合測試才會發生的問題，牽扯資料面跟流程太廣，擁有可還原資料的紀錄點可幫助解決影響層面與資料太廣的問題
      3. User site能提供VNC服務的話，可以降低UAT駐點人數
      4. 問題單上使用wink記錄User site，問題發生的操作過程
         1. 可與user site的資料結合，快速還原與釐清問題
4. 呈現
   1. 一般按鈕使用圖檔按鈕
      1. 好處
         1. 美觀
      2. 壞處
         1. request會影響一點點效能
         2. 較無彈性
      3. 可以改進的地方
         1. 改用一般button+css漸層來達到美化效果
   2. 可以改進的地方
      1. 未來可以搭配jQuery或AJAX control toolkit來達到整理頁面的效果
         1. 如HoverMenu、CollapsiblePanel、Accordion
      2. 提昇效率
         1. 使用AJAX或jQuery的xmlHttpRequest搭配web service
            1. 如AJAX control toolkit的AutoComplete
5. 自動測試
   1. 於Business layer與Data accesslayer撰寫Unit Test
      1. 好處
         1. 可以讓開發人員及早發現自己設計的盲點
         2. 透過daily build可達到迴歸測試的效果，避免牽一髮動全身
         3. 提高各程式基本品質
      2. 壞處
         1. 額外的開發成本不低
         2. 修改頻率頻繁
      3. 可以改進的地方
         1. 想辦法提早獲得相關的test case
         2. 問題單上的test case回補至unit test
         3. 多人同時開發時，測試DB的設計方式
6. working model
   1. 可以改進的地方
      1. User site應該要有程式過版的能力
         1. SVN的更新
         2. 檢查目前測試機版本與問題單對應版本的能力
      2. 線上視訊會議效果不彰
         1. user site通常網路品質不穩
      3. 跨功能模組時的分析與設計
         1. 如跨SA設計的功能規格可能會有互等的deadlock情況，或是矛盾的情況發生
         2. 跨PA的功能設計，溝通上的情況可以改進，避免發生重複開發的情況
      4. 測試腳本
         1. 如果可以在規格上補上測試規格與測試腳本(包含test case)，可讓開發人員更能瞭解該功能目的與提升程式品質
   2. feedback
      1. 每週review進度使用excel瞭解整個專案的進度、milestone、人力情況，徹底反應現實專案情況
         1. 數據化的呈現更能讓leader掌握進度跟提早解決問題
      2. SA帶領PA，PA帶領一組PG的方式，在開發上速度較快，但可能有開發人員面對跨SA設計的規格時，維護上適應的轉換成本