我们的系统有一个功能模块，在实现的时候遇到了一些分歧。经理的方案有他的道理，但是从我的角度看，那是一种逃避的策略，把一切都推给用户，难道系统不负责处理数据的逻辑错误?想了很久也不能接受。我倒是有一种比较直接的解决方法，但是肯定要修改数据库，涉及到几个表的变动，会影响很多已有代码。我不太敢动，动一下就意味着集成时间不得不再次退后，我对老师没有办法交待。只好硬着头皮去糅合各个方面的特性，经理是头头，做出的东西得他满意，但是我不能黑着眼睛完全服从他得建议，那种实现方案太龌龊。而已经形成的代码真的不好意思让大家重写。

形成这种局面是必然的，因为经验的缺乏，我们还在学习中实践，在摸索中前进。最开始的时候，师兄带着做的时候根本没有设计数据库，随时用随时加，加的一塌糊涂，甚至出现了数据不一致等很多问题。于是被经理批评我们不会用数据库。这次被要求先做数据库的优化，我们用建模工具，完整的建立了整个数据库，通过了以后被告知，数据库不动了。再后来几个业务要求变更了，数据库设计有点“过时”了，而当时我们还有比较好的解决方法就没有去改变数据库，谁也不想承担修改数据库带来一系列改变的责任。于是积累下来，本应该早做改变的地方没有改变，使得业务实现十分棘手。

于是我开始反思我们的这次的设计过程，因为被批评只是拿数据库做存储数据的工具，我们着重了对数据的考虑。但是这不是主要原因。主要的原因是我们再设计的时候，看到了数据，就马上被吸引到考虑数据库中记录规划和字段结构以及关系模型上面去了。我相信这种欲望很多学生派都难以抵御。但是我们真的应该这么做么？

因为过早的确定了数据库的设计，所有的业务设计都要围绕着数据库来进行。所有的功能模块不再是用例本身的实现，而变成了对数据的操作。于是按职责和场景进行分析设计离开了我们的视线，我们的眼里只有数据和关系。这使得我们的程序完全的和数据库不可分离，而当我们发现现有数据关系不适应新的变化的时候我们只有两条路，改变数据库和当前所有的相关代码，使用极其复杂的手段使变化能适配在现有数据关系上。两条路都不好走，而无论走哪条路，在面对新的变化的时候都会越发增加系统的脆弱性和牢固性，臭味十足。于是我开始考虑，设计初期就确定数据库的做法应该是错误的。

巧合的是，在晚上看《敏捷软件开发》的时候看到了Bob大叔这样一段话（P174）：

首先生成数据库模式的应用程序中，数据库成为了关注的中心。
数据库是实现细节！应该尽可能地推迟考虑数据库。有太多的程序之所以和数据库绑定在一起而无法分离，就是因为一开始设计时就把数据库考虑在内了。请记住抽象的定义：本质部分的放大，无关紧要部分的去除，（在初期迭代的时候）在项目的当前阶段数据库就是无关紧要的：它只不过是一项用来存储和访问数据的技术而已。

如果我早一两个月看这本书会有什么效果？或者挽救我现在吃力不讨好的境地，或者无动于衷？也许不经历这次阵痛我不会有这种意识吧。更值得我震撼的是，就当我考虑到这个问题的时候，在书上看到了同样的忠告。我想这种印象将是永久而深刻的。

顺便说一句，对敏捷开发来说，就是一个不断适应变化的过程，换句话说就是不停的运动。源代码就是设计，而从来没有其他的确定的设计。不要怕改变，需求变化是软件开发的必然现象，是伴随软件开发整个过程的“最佳”伴侣。只有不停的变化，才能让自己的项目减少痛苦。

想想，如果我在最开始发现问题的时候就采取果断的行动，现在可能整个情况会好不少。真是长痛不如短痛啊！

Trackback: http://tb.donews.net/TrackBack.aspx?PostId=614553