前面的工作持续了几天，貌似一切都还好，经过近一周的努力，数据库基本管理起来，在底层数据方面，做到了对变更的良好的管理，算是一个阶段性的成果。虽然说软件的设计得站在用户的角度上，底层的数据是为上面服务的，但我想，特殊情况得特殊对待，像我们这种一天几变的小系统，就得找到一个好的方法，让他在变化种保存相当的稳定，就像建房，根基牢固了，上面就稳定了（这是我个人的一点经验，可能理解得不对，还忘得到指点）。

并且，我也站在一个用户的角度，对该系统的功能点进行了整理，希望借此逐步理清系统流程。

就在昨天，技术组长希望我对他们的底层代码进行整理，这是一个比100多个数据表更难的工作，不说模棱两可的注释，就是这不停的变动，就让人吃不消。

变动，还是变动，得想个办法管理变动了。

我做的第一步，就是找技术组长商量，说了我的想法：不能从代码入手，我希望从变动的根本入手，我希望将所有的流程记录下来，统一一套不变动的标准，或者说相当稳定的标准，从根本上减少变动。可是，这如何做呢。

变动的根本是不稳定的流程、规则。

不稳定的流程又来自哪里？来自不稳定的需求；

那不稳定的需求又来自哪里？

我们？用户？

我们是谁？开发者；

用户是谁？还是开发者（领导），或者说是领导虚拟出来的用户。

看来是个棘手的问题，还得从需求入手，可是，我怎么获得需求呢？找领导吗？就算领导支持，可我能从他那里得到什么呢？因为变化的根源就在他那里，他对整个系统也只是一个构思，在见到实物之前，他也不确定。

好了，该怎么办呢？将现在的系统作为原型吗？

如果作为一个原型，那我们现在的开发是不是开发得“过”了呢？其他的人能同意不？因为他们一直对这套系统报有很大的期望，如果告诉他们现在的系统只是一套原型，以后要全部重新构建，他们会怎样呢？

看来，也不是那么简单。是不是得用另一套方法，或许，对于一个这样的小系统，需要有不一样的方法。

在我脑海中已经有几套方案，先试下，以后再接着写，今天就到这了………………….