就像伐木工人手上有各種各樣的工具一樣，程序員也需要有各種tools，伐木工人的工具會隨着時代的進步而進步，比如有斧頭到電鋸，程序員也需要適應時代的發展，能夠很快的接受新的知識和工具，比如shell，python處理文本，IDE開發，cygwin
元編程：---業務邏輯和業務規則等
儘可能的配置：把抽象放到代碼裏面，細節放到metadata裏面去，即數據庫或者配置項
不要蒐集需求，而要深挖需求
像用戶一樣和用戶一起想問題和需求
文檔化需求：用例
詞彙彙總
單元測試：要麼需要單元測試代碼，並需要內部運行關鍵狀態或者錯誤日誌
臨時耦合： ---時間
黑板：來協調完全不相關的情況和對象(即中介者模式)
寫軟件像建花園，而不是蓋大樓：因爲大樓受物理和現實世界的限制，軟件卻不受限制，需要定時重構，像花園需要時不時的修剪一樣
團隊：
破窗：團隊不能容忍破窗(產品的不完善的地方)，需要指定人修復，不能一直放着不管
溫水煮青蛙：個人和團隊假如一直在一個假設的環境或者需求或者條件下繼續下去，
就很可能像那隻可憐的青蛙一樣，或者定時的檢測下環境或條件或需求是否變化，或者團隊裏面專門有人來檢測
測試：
單元測試
集成測試
用戶驗證和確認
現實資源：內存，磁盤空間，cpu速度，時鐘週期，磁盤速度，網速，顏色，視頻分辨率，crash恢復
性能測試
可用性測試
迴歸測試:每次測試的結果數據對比，看看有沒有什麼變化，從而查看有沒有出現新的bug
註釋：
WHY？goal？ how 是不需要的，否則就違反了DRY原則
內部文檔和外部文檔都有DRY原則：
不要重複你自己，即任何東西都只有唯一的來源；
首先，比如說數據庫表作爲唯一的口子，
當數據庫表變化時，依賴於此數據庫表的各種程序怎麼樣才能做到動態變化？可以在數據庫表的註釋裏面增加依賴於它的模塊代碼文件名稱列表，這樣當以後維護時，假如數據庫表出現了變化，則可以依據此文件列表去通知依賴項，否則沒有通知到的就等着crash了；但是有個問題就是表的註釋有長度限制，所以可以給每張表建立一張依賴表，即給表abc建立abc_dependence,裏面就一個字段：依賴列表
依賴於此數據庫表的各種文檔怎麼樣才能也動態變化？可以用腳本語言動態生成文檔
比如說源代碼都有svn作爲唯一的入口和出處
寫代碼的註釋有doxgen來自動生成手冊
用戶手冊也要有唯一的口子，比如說用標籤書寫成普通文本，其他格式，比如說網頁形式，pdf形式等
或者word作爲唯一的出處，保存爲網頁形式
針對單元測試(甚至集成測試)的一些思考：
考慮自動化測試，即寫腳本程序測試，好處是自動化測試只需要實現一次，後續只需要run一次看結果就可以了
涉及到兩個方面：
1， 邊界和條件測試，比如說new_order,可以通過腳本程序去分析new_order的日誌，看看每個必須得tag值是否滿足給定的必須條件，比如說取值範圍，tag缺失
2， 迴歸測試，迴歸的意思是多次運行，比對結果，比如說，我們的一個模塊上線運行了，當有了新的修改後，假如同一天的輸入數據，同樣的下單邏輯，
需要把它的結果和上次運行的正常日誌對比下，看看有沒有變化，當然需要程序去對比，並把不同之處打印出來,如果有不同則代表引入了新的bug
針對數據庫表變化引起的未知bug的一些思考(有點類似DBA的角色機制---大家都依賴於這個人，每個用到的都註冊一把)：
當數據庫表變化時，依賴於此數據庫表的各種程序怎麼樣才能做到動態變化？可以在數據庫表的註釋裏面增加依賴於它的模塊代碼文件名稱列表，這樣當以後維護時，假如數據庫表出現了變化，則可以依據此文件列表去通知依賴項，否則沒有通知到的就等着crash了；但是有個問題就是表的註釋有長度限制，所以可以給每張表建立一張依賴表，即給表abc建立abc_dependence,裏面就一個字段：依賴列表
針對代碼變化了文檔沒有更新到最新的一些思考：
依賴於此數據庫表的各種文檔怎麼樣才能也動態變化？可以用腳本語言動態生成文檔
C++中的new在分配內存失敗時會拋出異常（std::bad_alloc）而不返回0（一些老的編譯器可能還在返回0，但這樣的編譯器實在“太老了”），這跟C程序員的做法很不一樣。而且，許多C++程序在使用new創建對象時也根本不檢查這種異常。這是一種什麼哲學呢？”
使用try catch的地方：
1， 調用數據庫，需要回滾時
2， 調用第三方庫，或者被調用的函數會拋異常
3， f1 catch調用f2,f2調用f3,調用f4 throw; f4惹禍，f1收場，中間f2和f3只是一臉無辜地把異常“透過去”
C++中的“new”還不只是分配內存那麼簡單。對於用戶自定義的類型來說，“new T;”相當於operator new再加上對T的構造函數的調用。由於類的構造函數完全可能引發異常，於是，就算內存分配一切順利，一條new語句還是可能產生異常。看來，需要catch的不止std::bad_alloc。
暫不考慮“哲學”因素，如果有人仍然覺得應該像C程序那樣嚴格檢查內存分配，可不可以呢？當然可以，畢竟它還能拋出異常麼，它能拋出我們就能捕捉。每分配一次內存都要包上一層try/catch，跟C中的針對返回值的if/else風格比起來凌亂多了。
