从错误中学到更多

开发进行到尾声了，但 bug 仍然层出不穷。总的来说，算是一个比较失败的项目，原因很多，有外在因素也有我作为一个 SA 不可推卸的责任。正好借加班的时间写点总结，也算是在失败总吸取教训，从错误中感受更多吧。

首先是开发流程。我是 xp 的坚定支持者，但在项目中由于外界原因还是采用了传统的开发流程，没有迭代，就是需求 -> 设计 -> 程序员进场开发 -> 改 bug 。由于程序员进场时间较晚，一上来就开始开发，没有时间进行培训和团队的融合。然后开发中缺少沟通，就是一个人负责一块，开发完了再做其它。结果开发到现在，还有人不清楚我们项目的全貌，到底是为了解决什么业务。

然后是开发框架。使用了公司的框架，而我们作为 SA （我们是双 SA ），都是第一次接触，程序员也就一个人用过。我们最早是达成共识采用 SSH 的组合（我至少还算是了解吧，其它人也都用过），但由于上层因素没有实施（这也导致我好长一段时间进入不了状态）。开发前期大家都在探索这个框架（的确很难用，出错机制较差，配置文件很多，耦合较强 ... ），在一堆莫名奇妙的问题中摸索前行，花费大量的精力。而比较搞笑的是，在大家开始学习这个框架之时，我作为 SA ，因为要写一堆只为应付客户的设计文档（后面就没人看过），错过了和大家共同进步的机会，后面总是感觉“低人一等”。

在业务方面也存在很多问题。很多业务逻辑并没有以很好的载体保存下来，在需求文档中很多逻辑并没有体现。我维护了一套 pd 的业务模型，从概念模型 -> 物理模型 -> 数据库，这解决了后面的一些沟通问题，但由于更多体现的是静态的实体及关联，对于一些动态的业务流程没法体现。我们 SA 之间有时在一些问题上的理解还存在分歧（讨论过也达成过共识，但没有记录下来，后面可能就忘了），程序员就更是无所适从。谈到这，我更感受到 DDD 这本书的价值，他所提倡的开发人员参加模型的讨论，形成项目的模型语言，并不断随着业务进行演化。。。好多理念都是项目经验的结晶啊。

在开发管理上我也是无所作为。 Junit 都没有推广下去，更别说 TDD 了，这也与框架相关，它就没提供写 test case 的地方，等我搞明白一堆配置文件，做出脱离 web 容器的 test 框架，都开发一大半了，说起 test 的好处，大家也表示不理解（或者表示理解但没时间 = 没理解），就让他们慢慢 debug 吧！代码的质量也没有保证，程序员不明白代码的味道，更别说理解重构的意义以及进行恰当的重构了。一个函数写上 100 多行，什么逻辑都混在一块，但由于时间较紧，我也只好睁一只眼闭一只眼“功能完成就行吧！也不是我一个人在管”，到现在很多代码混成一团，展现层直接调用 dao （又是框架惹得祸），相同的逻辑 copy 到 n 处，我也是后悔莫及。

今天先写失误，明天写从中学到的东西，从错误中学到的也许更多！