通過這幾天的 框架學習我認為在處理乙個具體的業務模組的時候，我們可以考慮一下因素
日誌 跟蹤，除錯，資訊，警告，錯誤 如果能嚴格的按照這個 5個等級來，就能檢視出程式的任何錯誤，一段優質的** 80% 使用來處理錯誤，5% 是用來記錄日誌，真正用來做業務實現僅有 15%。
異常 程式出現異常 就會 涉及 異常處理
記錄異常
統一異常
重複執行，繞道而行
事務回滾
事務效能
同乙個資源被反覆讀取，沒有放入快取中。
簡單的問題，複雜化。
在**沒有任何多餘的情況下，硬體資源消耗的情況下，業務邏輯合理的情況下，考慮是否需要通過 分布式，集群方式實現
國際化驗證監控（可以通過 spring aop 實現）
將這個 業務的 每個任務執行的狀態（可以具體分為幾步） 記錄下來，每次執行完成都去改變狀態，那麼就可以動態通過網頁 監控這個狀態。
監控執行狀態
監控執行時間
監控異常
監控事務是否回滾
生命週期
ejb
考慮給業務模組乙個上下文
考慮業務模組是否能封裝成ejb, 通過mvc 的 控制層 與 ejb 互動。
會話bean
訊息驅動bean
bean
jms設計模式
乙個業務模組下,應當多從這 幾個 因數 出發想一想,不要立馬動手去做。目標就是能把**寫好,不用改bug,也不會出現任何問題。就算出現邏輯問題也能通過日誌看的清清楚楚。出現效能問題，也能通過監控看的清清楚楚。
我發現所有的框架都會，一下幾點相似
生命週期
會話 session
框架 bean
建造者，工廠，**…等等一些列的設計模式
gSOAP學習體會
include soaph.h 得到存根程式 include sendemailbinding.nsmap 得到命名空間對映表 include include include soapsendemailbindingproxy.h using namespace std int main int a...
git 學習體會
下午頭暈呀。學而不思則則罔，看了好幾天git，隨便寫寫來整理下思路。這幾天主要做了3個事情，一是寫了20多頁的ppt 準備交流，乙個是看了progit的中文件，還有乙個是在stackoverflow上提了幾個問題。對git也算入門了吧，熟練掌握常用命令的含義和用法 不帶參的 知道了git的儲存和資料...
UI學習體會
很多時候自我感覺做好的一件事情，往往並不會得到別人的認可 經不起別人的推敲，總是自己被澆的狗血淋頭 很多時候，我們都沒有站在另外的乙個角度去看問題 也許不是你要做多少多少事情，關鍵是你要別人承認你的價值所在 今天上完ui作業點評後，才發現自己可以去石化了 很多資訊不是我們自我感覺好了就ok了 我們程...