开发经验记录, 设计的蝴蝶引起的代码地震, 小品文.

 

这是一个阳光明媚的下午, 我写了一个可以将DataTable作为数据源, 并且完美的生成树的TreeViewTools, 倒杯咖啡, 轻松的躺在椅子上准备从我们的数据持久层拿到一个DataTable做为源, 嗯, 世界就是这么完美, 哦, 来看看, 稍微指定几个条件, 咱们的数据持久层就能返回来了一个DataEntity组成的Ilist, 品口咖啡. 嗯, 好喝, 但是等等, 我需要一个DataTable, 但我手里只有一个Ilist. 哦, 这太简单了, 在回头更换咱们设计和把Ilist转换成DataTable两者选择一下就好了. 嗯, 想了想觉得无论听着摇滚磕着药丸也会睡着的回头设计是个hell一样的生活, 为什么不试着把Ilist转换成DataTable呢? O, Yeah!

 

半个小时之后…..

我瞪着眼睛盯着程序从20个Entity的属性中反射出了我要的表, 嗯, 很温柔, 就像我预想的那样, 一切像水流过斜斜的石板那样顺利. 这时候我只需要把IList中得到的数据插入进去表中就好了.

 

10分钟过去了……

将一个Entity填充在了DataTable, 然后看着后边还有似乎无尽的Entity等着我, 决定写一个通用方法解决.

 

一个小时之后…….

发现找不到办法通过反射得到目前Entity内部的数据….. 继续想, 是否用hashTable预读存储…….

 

3个小时之后…..

哦, Yeah, 从显示器前抬起了蓬乱的头, 伸个懒腰, 终于写好一个HashTable和一个存放在Value中的Entity Data Struct解决了存储值的问题并且插入组成了我想要的DataTable, 世界又一次变的美好了~ 我已经开始幻想着以后还可以给它加入depend和数据库保持同步..

 

10分钟后, 喝着水开心的审视刚刚写的程序, 自我陶醉的天花乱坠~~~ 真是天才之笔, 奋进的大脑慢慢冷静下来… 有一点不详的预感…

 

嗯, 大脑冷静下来了… 于是我打开数据持久层, 加上了一个函数……

return ds.Tables[0];

 

10秒钟后…. 我拿到了自己想要的DataTable, 扣扣鼻孔看着天, 今天的天气真好呐. 

 

 

从头思考这个白痴一样的错误.

 

 

额错咧，额真滴错咧，额刚一开始就不该嫁到这儿来，额不嫁到这儿来，额滴夫君就不会死，额滴夫君不死，额就不会沦落到这个伤心的地方……  

 

额错咧，额真滴错咧，额刚一开始就不该这儿样设计treeviewtools，额不这儿样设计treeviewtools，额滴IList就不用变成DataTable ，额滴IList不变成DataTable，额就不会沦落到用反射和HashTable处理这个问题………  

 

嗯, 一点反悔的意思都没有…..>_<

 

顺着最后的重大失误追溯向上, 发现这个无边地狱的起源就是一个设计上一个小的错误. 我不愿意去维护不是我写的并且毫无注释无边复杂的数据持久层, 也不愿意推翻自己的设计, 于是决定把IList转换成DataTable.

 

于是: 我设计的TreeViewTools中一个数据源类型的错误, 引起了之后一整个下午的代码地震.

 

 

于是这时候在想,

 

如果当出现设计错误的时候, 去正视它, 下午可以继续喝着咖啡去看窗外.

 

如果当察觉的一丝不妥的时候, 重新思考它, 下午还可以继续喝着咖啡看窗外.

 

如果发现解决方案太复杂不容易控制的时候, 重新设计它, 蝴蝶效应还是可以避免.

 

并且如果遇到一个问题, 先从你能接触到的后台开始考虑它, 世界会更温和.

 

如果你像我一样被有趣儿的编码吸引, 那也许等会儿咱们就可以一起扣着鼻孔看蓝蓝的天了…..

 

设计上一个小小的错误, 在继续的编码里, 就是蝴蝶效应, 虽然身轻, 但是足以改变人类整个历史.