我曾经说过，做“架构”最重要的就是平衡一事，比如要注意团队的理解能力和技术的先进性之间的平衡。
昨天老板回滚了我的代码，因为Flex里面有一个Bug，而他也读不懂我的代码。简单讲就是说有很多个DataGrid，这些列有些时候是完全没有任何值的。而这些DataGrid可能会有派生类，这些列有的直接用DataField绑定，有的用labelFunction，还有的自己写了各种Renderer。（没错，Flex……）这么多写得各种奇葩的类（DataGrid和Renderer），我都不想碰，主要是老板说Don't touch it，那好吧算啦那就。
我的解决方案是弄了一个辅助类，所有需要这种自动隐藏无内容列的DataGrid，只需要在onCreation事件上绑这个类的一个公开A方法就好。A方法会自动监听DataGrid的事件，一旦数据发生改变就自动遍历所有的列，自动判断是否应该显示。你看这样挺好吧，只要是个DataGrid就能应用，还不用改那些DataGrid和Renderer，简直就是即插即用。
问题是Flex里面有Bug，导致某些情况下有些元素会挂在上面不消失……昨天正好有事情没时间改，老板就给回滚了。大概是写得太好太容易回滚了吧……
现在你们知道了吧，如果你的团队成员里面有人达不到那个水平，就会各种的退化。（没错，这个Flex代码里面好多的Copy Paste，两个项目里面大量完全相似的代码。还有各种的if else来判断不同品牌下面逻辑如何，简直就是一锅粥。）
然后今天呢，老板站身后问我在干啥，我就耐心解释了一下现在遇到的问题是什么。可惜呢，老板改东西的思路属于标准的散弹枪，根本没时间听你解释：你有问题A啊，那就直接试试这个吧。什么？还有问题B？先不要管他，这个改好了再说。不凑巧今天的问题是A->B->C->A这样的问题，改好一个就会导致另一个出问题（代码奇葩不许笑）。说了半天老板以为我没有听明白，于是就开始给我pair coding了。“呐，你应该这样这样，如此这般这般……你看好了吧！” “嗯嗯（卖萌无耻）” “好，现在我们来改问题B……咦？”
就这样，我坐在边上看他折腾了大概3个小时。从A改到B，然后改到C，然后又回来折腾A。中间还改错了几次，以为改好了一测发现还是错了。后来到1点多了，老板说你去吃饭吧，然后就剩下他默默的坐在我的电脑前面噼里啪啦。
吃完中午饭回来一看，老板说改好咯，我一跑还是错的。然后老板摊手，“我要接女儿了。”跑了。我很淡定的坐下来，花了大概10分钟，改好了。
其实本来如果给我3小时，说不定都足够我想好一个很好的解决方案并重构好了。结果这么一折腾，去你奶奶的，老子随便了。于是各种违反单一职责、高内聚原则的代码piapia一贴，收工。
这也不能怪我啊，老板这三个小时里面代码一顿眼花缭乱的腾挪闪移，比如在一个Data ValueObject里面保存了UI的状态，我怎么能删掉这样的代码这么不给面子呢？那啥，顺着老板思路很重要的。你们晓得了吧？
好了，撒完气了。
