开发进行到尾声了，但
bug
仍然层出不穷。总的来说，算是一个比较失败的项目，原因很多，有外在因素也有我作为一个
SA
不可推卸的责任。正好借加班的时间写点总结，也算是在失败总吸取教训，从错误中感受更多吧。
首先是开发流程。我是
xp
的坚定支持者，但在项目中由于外界原因还是采用了传统的开发流程，没有迭代，就是需求
->
设计
->
程序员进场开发
->
改
bug
。由于程序员进场时间较晚，一上来就开始开发，没有时间进行培训和团队的融合。然后开发中缺少沟通，就是一个人负责一块，开发完了再做其它。结果开发到现在，还有人不清楚我们项目的全貌，到底是为了解决什么业务。
然后是开发框架。使用了公司的框架，而我们作为
SA
（我们是双
SA
），都是第一次接触，程序员也就一个人用过。我们最早是达成共识采用
SSH
的组合（我至少还算是了解吧，其它人也都用过），但由于上层因素没有实施（这也导致我好长一段时间进入不了状态）。开发前期大家都在探索这个框架（的确很难用，出错机制较差，配置文件很多，耦合较强
...
），在一堆莫名奇妙的问题中摸索前行，花费大量的精力。而比较搞笑的是，在大家开始学习这个框架之时，我作为
SA
，因为要写一堆只为应付客户的设计文档（后面就没人看过），错过了和大家共同进步的机会，后面总是感觉“低人一等”。
在业务方面也存在很多问题。很多业务逻辑并没有以很好的载体保存下来，在需求文档中很多逻辑并没有体现。我维护了一套
pd
的业务模型，从概念模型
->
物理模型
->
数据库，这解决了后面的一些沟通问题，但由于更多体现的是静态的实体及关联，对于一些动态的业务流程没法体现。我们
SA
之间有时在一些问题上的理解还存在分歧（讨论过也达成过共识，但没有记录下来，后面可能就忘了），程序员就更是无所适从。谈到这，我更感受到
DDD
这本书的价值，他所提倡的开发人员参加模型的讨论，形成项目的模型语言，并不断随着业务进行演化。。。好多理念都是项目经验的结晶啊。
在开发管理上我也是无所作为。
Junit
都没有推广下去，更别说
TDD
了，这也与框架相关，它就没提供写
test case
的地方，等我搞明白一堆配置文件，做出脱离
web
容器的
test
框架，都开发一大半了，说起
test
的好处，大家也表示不理解（或者表示理解但没时间
=
没理解），就让他们慢慢
debug
吧！代码的质量也没有保证，程序员不明白代码的味道，更别说理解重构的意义以及进行恰当的重构了。一个函数写上
100
多行，什么逻辑都混在一块，但由于时间较紧，我也只好睁一只眼闭一只眼“功能完成就行吧！也不是我一个人在管”，到现在很多代码混成一团，展现层直接调用
dao
（又是框架惹得祸），相同的逻辑
copy
到
n
处，我也是后悔莫及。
今天先写失误，明天写从中学到的东西，从错误中学到的也许更多！