開發進行到尾聲了，但
bug
仍然層出不窮。總的來說，算是一個比較失敗的項目，原因很多，有外在因素也有我作為一個
SA
不可推卸的責任。正好借加班的時間寫點總結，也算是在失敗總吸取教訓，從錯誤中感受更多吧。
首先是開發流程。我是
xp
的堅定支持者，但在項目中由于外界原因還是采用了傳統的開發流程，沒有迭代，就是需求
->
設計
->
程序員進場開發
->
改
bug
。由于程序員進場時間較晚，一上來就開始開發，沒有時間進行培訓和團隊的融合。然后開發中缺少溝通，就是一個人負責一塊，開發完了再做其它。結果開發到現在，還有人不清楚我們項目的全貌，到底是為了解決什么業務。
然后是開發框架。使用了公司的框架，而我們作為
SA
（我們是雙
SA
），都是第一次接觸，程序員也就一個人用過。我們最早是達成共識采用
SSH
的組合（我至少還算是了解吧，其它人也都用過），但由于上層因素沒有實施（這也導致我好長一段時間進入不了狀態）。開發前期大家都在探索這個框架（的確很難用，出錯機制較差，配置文件很多，耦合較強
...
），在一堆莫名奇妙的問題中摸索前行，花費大量的精力。而比較搞笑的是，在大家開始學習這個框架之時，我作為
SA
，因為要寫一堆只為應付客戶的設計文檔（后面就沒人看過），錯過了和大家共同進步的機會，后面總是感覺“低人一等”。
在業務方面也存在很多問題。很多業務邏輯并沒有以很好的載體保存下來，在需求文檔中很多邏輯并沒有體現。我維護了一套
pd
的業務模型，從概念模型
->
物理模型
->
數據庫，這解決了后面的一些溝通問題，但由于更多體現的是靜態的實體及關聯，對于一些動態的業務流程沒法體現。我們
SA
之間有時在一些問題上的理解還存在分歧（討論過也達成過共識，但沒有記錄下來，后面可能就忘了），程序員就更是無所適從。談到這，我更感受到
DDD
這本書的價值，他所提倡的開發人員參加模型的討論，形成項目的模型語言，并不斷隨著業務進行演化。。。好多理念都是項目經驗的結晶啊。
在開發管理上我也是無所作為。
Junit
都沒有推廣下去，更別說
TDD
了，這也與框架相關，它就沒提供寫
test case
的地方，等我搞明白一堆配置文件，做出脫離
web
容器的
test
框架，都開發一大半了，說起
test
的好處，大家也表示不理解（或者表示理解但沒時間
=
沒理解），就讓他們慢慢
debug
吧！代碼的質量也沒有保證，程序員不明白代碼的味道，更別說理解重構的意義以及進行恰當的重構了。一個函數寫上
100
多行，什么邏輯都混在一塊，但由于時間較緊，我也只好睜一只眼閉一只眼“功能完成就行吧！也不是我一個人在管”，到現在很多代碼混成一團，展現層直接調用
dao
（又是框架惹得禍），相同的邏輯
copy
到
n
處，我也是后悔莫及。
今天先寫失誤，明天寫從中學到的東西，從錯誤中學到的也許更多！