坏设计下的烂代码无法应对变化

关于成本的系统，之前的结构，我是指数据部分还是有点儿复杂的，为bug埋下了伏笔，但最初期待的功能很多并没有实际作用，后面补充的需求却给这个模型带来了麻烦。是时侯砍掉那些多余的需求了，其实事情本没有那么复杂。之前我们用了类似视图的功能来做，对于查询我们可以无缝集成，不论sql还是代码，但对于插入和修改就必须跟踪数据来源，这仅是麻烦之一。当我们试图去操作excel这个平面结构的时候，操作excel本身就不同于sql，我们根据sql的数据来控制excel，这就存在对数据库的操作以及对数据指令的操作，严格上说我还应该保持二者的事务性，即便这一点已然被忽略了剩下的工作量也并不小。同样是因为excel，自动化测试并不容易做。因为excel是平面的，数据库也是，留下的部分其实都只是一些操作，所以也是我始终不接受所谓的面向对象的方式来做，务实点，这个底层并不适合，起码意义不大。2.0如果要做就一定涉及到领域对象和领域计算（规则），首先业务不简单，要学习，其次，一定要有一套能够支撑计算的计算框架，或者称为计算模型，这完全不同于增删改查，和流程也不是一回事，是个数学模型。如何做我并没有想好。我现在其实比较期望的是简化版的1.1而不是2.0。