任何情況下不能吞異常，一般使用logger,哪怕只能用e.print... 也是有補救措施的，而吞掉便無從知曉。
* 配置多資源時，各種公用的內容沒有提取，導致修改時非常麻煩，推薦使用include方式
* 子資源要能使用父資源的指標值,也就是父子要有繼承關系
* 國際化時不應該再另起一個模型，這樣會使同一修改改動很多文件
* 任何會導致特殊字符危險的方案不能用，比如
  - 在解析命令時會解析參數 /o ,后來有一個目錄叫"/opt/home" ，導致解析不成功，非常隱蔽而且危險
* 打日志時要盡量的全，哪怕是trace，調試時很方便。不需要的可以不配置，需要時不必再次修改代碼。
* cc 的文件名長度有限制，非常不便
* 做配置時，某個對象的屬性集中一處配置，哪怕是include,不可分散至引用處重復配置,比如現在原型的資源類型的 disporder
* log4j 要做動態加載
* 打日志要規范，利用解析，使用多logger輸出
* 隊列要集中管理，分配
* 線程要集中管理，分配。無論是線程池還是獨立線程的創建。
* 模塊化工作的敵人是建一個模塊的工程時很麻煩，所以要從架構設計時解決這個問題，因為這個而導致今后結構不清晰，很不值得
* 大數據量的刪除操作很慢，約幾個小時的時間。所以需要在批量插入的時候判斷是否需要刪除部分數據
* 用URL返回本地文件路徑時，注意URLDecode.decode(path,"UTF-8"); 來轉換特殊編碼
* 真實環境的壓力測試(尤其是異常測試)很重要，未經此測試不要出售，會帶來很大的維護壓力
* socket 連接重試一定要有間歇，不然會把服務器搞宕
* 用到線程時，線程要繼承一處，并作統一創建和管理，以便于在內部設置路標。并且在線程內要及時寫入路標。設置路標時，參數以map形式添加，讀取時再格式化成字符串。
* 對于多線程程序，線程池分配時，分配策略要可配置以調節性能
* 2008-6-13 06:34下午 今天開發時，A改過的東西 我們B不知道，他在本地修改因為版本已經凍結，導致嚴重問題復現。今后采用為某個現場環境建立一個hotfix版，在這個版本上記錄更改歷史
* 給現場安裝不知該分配多大內存時，要有一個自動修正功能，設置內存在一個范圍內遞增。捕獲oom 異常，讓監控線程關閉系統并修改內存配置重啟。但是前提是要保證數據的完整性受損是可接受，或者有解決方案的。
* 當一個小組成員分頭支持現場問題時，每個人解決問題后要全體知悉，便于積累經驗和對外表達一致
* Joel曾經說過：不要先去完成界面，因為在很多用戶看來，完成了界面，就等于功能也快完成了。而要讓功能和界面的開發保持同步最好。
* 開發軟件不能只顧自己開發時方便,還要考慮到運行維護時是否方便
* 模塊依賴api時，此模塊要把自己需要的api整理為一套adapter去適配，便于整理出對api方法的依賴，另外在api強行變動時，其他應用也有應急辦法
* 留下足夠的程序內部信息的監控入口，生產環境是不讓動的,xstream
* OOM, StackOverflow, JMX高負載后停止服務
* 系統中用到的環境變量名要集中使用常量管理
* io 遠程調用傳輸過程中，盡量合并攜帶參數 ，減小傳輸量。不要使用zip。
* 線程要提供一個暫停的方法，以便調試
* 使用需要持久華的緩存，注意與持久化及時同步問題
* 作小于判斷時，注意-0 是等于0 的，應該用<=來判斷。
* windows 2003系統中當開著服務控制臺啟動DaemonServer后不關閉mmc控制臺,向控制臺輸內容會導致阻塞。要自定義文件流，使他們保存至文件。
* 持續進數據的隊列 要對處理慢的情況有考慮，否則會oom
* 同步數據需要在一個事務內完成寫入,否則會導致界面的壞體驗
* 使用具體類來代替type類型區分，可以幫助在有性能問題時快速定位，只是有可能增加些代碼量，值得