郁闷的两天
由 sumtec 发布于 2014年03月04日tinyfool yuzhouwww 等2人欣赏。
我曾经说过，做“架构”最重要的就是平衡一事，比如要注意团队的理解能力和技术的先进性之间的平衡。
昨天老板回滚了我的代码，因为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的状态，我怎么能删掉这样的代码这么不给面子呢？那啥，顺着老板思路很重要的。你们晓得了吧？
好了，撒完气了。
老板给你钱，你要允许他浪费时间。如果你是老板，可以上来抱怨花钱请来的员工水平不够，但只要Boss给你钱，你不能抱怨Boss的水平和理解力不够。
我现在手上的一个项目，Boss每次来听技术汇报，就是听两句然后说：“我没听懂，这样，我把我的商业模式再给你讲一遍，叭啦叭啦，你看你做的技术跟我这商业模式一样么？一样，那OK，下次我们什么时候再开会汇报？“
2楼 @yangjie6020 本来想先回1楼的，后来觉得还是你这个比较简单。
你这句话没错，但不是在这个场景下面的，而且还少了最重要的几个字：正确的。
比如说，你会接受很迅速的把原来的三层架构搞成一锅粥，里面还错错得恰好对了的改正方式？或者Copy Paste代码？或者说你允许UI层的状态放到数据访问层里面解决，尽管看起来好像解决了问题？这些看起来快的方式，回头就是巨额负债。现在代码长这样，就是这种思路的结果。
只要代码改完之后“能够跑”，没事回过头来重新Review并改正的几率永远小于100%。通常抱有这种想法的队伍，通常几率不超过千分之一。既有纪律问题，也有猪队友问题。总之你要期望他不这么烂下去，是很难的一件事情。
我以前带队伍的时候，对于胡乱改对总是采取高压政策，根本就不会给你什么耐心——你丫这是在搞破坏知道不？而对于认真改错了，反而会尽可能讲解里面的细节，一起分析。（可惜是，大多数人的改Bug方式就是上面那种典型的散弹枪，随便轰一把中了就走人。）
好多次了，我都能预见有些做法后面会有问题，就不听，后来果然就问题一堆。这算什么呢？这种事情和过度优化、或早优化根本就不是一件事情。
你们看看Linus是如何处理和评价类似的事情的。
补充说明：严格来说，回滚我的代码没有任何问题。因为这只不过把之前解决的问题“不解决了”，但至少并没有产生新的问题。然而我要吐槽的重点并不是这个，这纯属被带歪楼了。我吐槽的点是：你不要以为一个好的设计就是好的，好的设计可能并不会被理解，然后因为不被理解而回滚，拆掉。这一次老板显然没明白这个东西是如何工作的，他认为那是我的代码里面的Bug，然后blahblahblah说了一堆为什么。我一听根本就不是那么一回事，解释了一下发现听不懂。于是算了就当他是对的好了。
1楼 @晓书生 你说的没错，所以我就卖萌啊。你那个老板说：我按我的说一遍，你听懂了吗？听懂了，好你实现吧。这跟我的故事稍微是有点不同的。
我说的第一个故事是：来雕个镂空玉器吧。好，我雕。雕完了那块玉内里有块瑕疵，老板内心：卧槽这么复杂我不会唉，算了砸了做个玉坠吧。
我说的第二个故事是：老板说了一遍他的解决思路，可是按他的来肯定不对啊。他亲自要上，那我就只好让他来了。
嗯，这第二个故事让我想起了以前亲历的一次项目经理和开发人员之间的争执：程序员A和产品人员B正在就一个问题进行讨论，产品经理C突然跑过来吼了一句说这里就应该怎样怎样这有什么好讨论的，你要做得了就做，做不了就换人。结果A也怒了：这TM不就是已经按照你的要求实现了所以现在才出了问题吗，不就是正在和你们部门的人讨论怎么擦屁股么？当时你说要这么做我也告诉你不行会有这样那样的问题，你不听那我有什么办法，就按你的来做咯。偏偏你的文档又没有对这些问题该怎么解决的说明，你现在还不让讨论了，你找别人做吧我不做了。关于产品经理的问题，以后（待会儿？）有时间我还会吐吐槽。
其实这种问题本身就是一个艺术活，根本就不是什么技术问题：明明是错误的想法，要么选择花点时间解释清楚然后用正确的方法做；或者如果领导只管结或者不验证过程，那就表面答应暗地里按正确的办法做；或者领导直接动手搞细节却不搞清楚、搞不清楚，那你只好等着他撞冰山，然后再按照正确的办法做。当然了，你可以选择明摆着发飚正面冲突，或者选择领导英明神武。
其实我也就是事后在这里发个牢骚，没想到还是……
还有，不是是个老板就是发工资的那个，找你那样想的话，以前那50来人大概都是我花钱雇的了。我真没这么多闲钱……
你们老板还主动敲代码，我们老板简直就是神码一通乱喷：就这样了，应该不难，其实有时候也不难。但他好像就没碰到他认为难的东西，但一到处理问题的时候，就歇菜了
23楼 @iamaflyingpig 程序员的价值不在于使用某种语言，而是解决问题的能力，然后随便翻译成哪种语言都行，哪种语言合适就用哪种语言，只有初学者才有语言偏见，还属于比较低的层次。