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

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

如何用单元测试避免版本升级隐患

当我们的网站，在运行的时候，你是否考虑过做系统升级？OK，那些安全相关的漏洞，通常不会给你带来太大的影响，但是一些类似.net framework之类的，还有一些第三方的dll，则可能带来严重的问题。你的程序可能有意想不到的后果。虽然Microsoft在版本向下兼容方面做过了大量的测试，但也不见得就能保证你的正确性。你的所有问题，都变得连你自己都不知道了，你只有期盼上帝不要引爆那个炸弹。
单元测试，原本是用来保证代码正确，推动项目前进，描述用户需求的有效工具。但你想，如果你的项目对绝大多数的分支都做到完美的单元测试，你还害怕更换dll吗？版本升级，对你的影响是可控的，你可以重新运行所有的单元测试，并决定是否更新版本。
------------
本文因为篇幅较短，内容较散，所以列入该博客，大家笑笑就是。