论当用与否

标签:
css3transition权衡重构陈在真it |
分类: 项目分享 |
介于实在有点忙,打2013.10.30更新项目优化总结文章到现在,中间情节波澜起伏,动人心魄,有悲伤郁闷到想轮椅子砸人过,也有兴奋激动到想轮椅子砸人过,其实我并不是大家所想的那么具有暴力倾向的动不动就轮椅子砸人的不良少年,至于为什么呢,‘少年’用词错了,应该是不良青年哈...
这个不良青年介于今晚要发页面版本,而又刚好解决了一天的bug坐等发布不能离席的时刻,对于最后碰到的一个联调bug展开了无限遐想,首先,说下话题的起源,是什么bug:

新版的好莱坞是有两个宽度版本根据浏览器宽度切换的,然而在播放页的评论这里,有个bug,当窗口由宽切到窄的时候,评论框宽度会有个transition 动画过渡,而在chrome,会出现渲染问题,性能稍微差点的机子,可能就会出现,而调这个,其实也很简单,就不要transition呗,你是这样想的,对吧?当然,我也是这样想,不过这个模块,是引用别人的代码过来嵌套的,套在iframe里面,已经封装过,所以只能找代码提供方修改,于是,通过联系,找到了该同事,然后他说,这里只对高度进行transition变化,宽度没写啊,看了看:

好像确实没错啊,只写了height,然后我也就没话说,先改其它的bug去了,等到其它的bug都排查fix掉了之后,心里老觉得变扭,铁定是这里出的问题,不知道你有没有发现问题?我端倪一阵,发现怎么多了两个逗号,写法应该都不会没看过才对的,还是第一次看到这种,于是我自己写了个demo把它的这句css3套进去:

于是乎,问题出现了,我只是修改它的宽度,它还是有动画过渡效果,但是理论上,应该是没有效果的,直接唰一下就跳过去才对,接着我删了后面的变成 -webkit-transition: height 0.6s; 然后运行,就是预期的效果,然后改成:-webkit-transition: 0.6s; 只保留时间,又会出现过渡效果,所以其实,这里,浏览器在读的时候,‘,’就是一个小分句,后面会覆盖前面的,所以读 ‘height 0.6s’意思就是 对高度进行0.6s的过渡动画,而读 ‘0.6s’的时候,其实就是‘all 0.6s ease 0s’对所有元素进行0.6s的过渡动画,浏览器会把漏了的用缺省默认的补上,所以上面那句的浏览器会这样读:

你问我为什么不是直接打出来,而是截图,我只能说你问的好,不单只是会看,会想才是最重要的,然后我会告诉你我在Firefox截的,哈哈...
于是乎后来就让该同事用这句 -webkit-transition: height 0.6s ease; 简单明了的修改了下,妥妥的...
至于一个小bug 为啥要这么大费周章写个文章出来叻,这个确实是个小东西,不过我好久没写文章,手痒不给啊...
从这个问题,可以间接反映出一些其它的问题:
代码模块管理,代码封装提供接口供人调用,然而提供出去的代码触发了问题,该怎么解决?
调用别人封装代码,出现了问题,该怎么解决?
是否该调用别人的代码,调用之后后续维护成本多高?
怎么调用别人代码,降低后续维护成本?
这些就不是小问题了吧?
把‘点’放大到‘面’来看问题,看到的就不单是表面上的问题,而是项目整体,自身专业水平到哪个档...
我是一个搞页面重构的,之前头儿跟我聊的时候,问我重构是什么,我当时紧张也是,投机也是,就说 页面仔,然后我就被谆谆教导了一番,当时 举杯邀明月,基友成三人 的场面仍记于心,而在做 好莱坞影院 一年有余将近两年的现在,我又发现,其实,我真的做的就是个 页面仔,需求-交互-设计-重构-开发-发布 一条线,每个部分我都参杂了点,单把屁股擦干净,只做重构的东西,其它的不管,那是不可能的...就‘接稿’而言:
产品让设计给稿重构,重构说:哦,好,马上做,然后就开搞...
这是重构,他懂的效率办事,兢兢业业...
产品让设计给稿重构,重构说:哦,好,我看看先,评估下时间,然后开搞...
这是重构,他懂的安排需求排期时间,按序进行...
产品让设计给稿重构,重构说:哦,好,不过我这周已经排满需求了,具体安排了XX需求,你看下,我按紧急重要的先搞,后面的顺延...
这是重构,他懂的分析需求的轻重缓急,按序排期进行...
产品让设计给稿重构,重构说:哦,好,这样设计的话,预期是一天完成,不过看设计稿,可以做一些特效创意,让页面更鲜活有趣,能否在加多半天,特效搞起...
这是重构,他懂的评估时间,优化建议,并且能将加码做超出预期的工作...
产品让设计给稿重构,重构说:哦,好,不过,这里设计是否有点问题,它色调跟整体不搭,模块跟通用模块有差距,设计整体看起来好搓,看下是否有优化必要,让设计师优化一下这些细节后,我再开搞...
这也是重构,他懂的站在产品角度,去看待接手设计,并且能提出细节优化意见,从项目优化统一着手,懂的拒绝次品需求,并推进前面的流程优化...
‘接搞’感觉很简单的事,其实可以放射出这么多的问题,看出接稿的人水平档次大局观,其实不单对于个人,对于整个项目流程,都起了很大影响,在意了细节,减少了没必要的联调;拒绝了次品需求,减少了没必要的版本迭代,这些都是减少加班,提高工作效率的体现,并不是每个不加班的人就不努力,而是他懂的把自己精力用在拳头上,用拳打的猛,杀球杀的狠...
而前阵子碰到了一位同事,跟我说,某个工具很好用,工作效率提高比用之前有了提高,而对于自己,当用与否? 需要怎么考虑?
在之前的文章的时候,我提炼出来的观点是:根据项目本身的特点,制定合适的方案,强搬硬套只会把自己搞残,带着问题两面性去权衡将采取的方案,尽量保证站点可控。对项目优化的前提是对项目有一定的认知,对涉及页面能把控到位,在此基础上再谈优化。
同样,对于引用新的工具,应当有所尝试,别人说好的未必对于你自身就好,就像别人对我说,某种减肥药多牛逼,一下减去100斤,我只能冷冷的回答道:哥 增肥ing...
应当抱着问题两面性去权衡,引入之后是否会带来副作用,副作用是什么,表现在什么方面,怎么处理这些副作用,副作用带来的弊端能否盖过效率提高带来的利端,两者权衡之后,再问自己要不要用这货儿,避免不必要的后续维护麻烦...
好吧,好像扯的有点儿远,这赤裸裸就是一个transition引发的发思,看懂的应该都有体会,不懂的过多一年欢迎再来翻翻吧,我相信一篇好文章,会值得别人去看多几遍,而且每次看,都能看出新的体会...
最后给那些没看懂的同学总结一下,那个transition bug应该这样处理:-webkit-transition: height 0.6s ease; 谢谢大家,哈哈...
这个不良青年介于今晚要发页面版本,而又刚好解决了一天的bug坐等发布不能离席的时刻,对于最后碰到的一个联调bug展开了无限遐想,首先,说下话题的起源,是什么bug:

新版的好莱坞是有两个宽度版本根据浏览器宽度切换的,然而在播放页的评论这里,有个bug,当窗口由宽切到窄的时候,评论框宽度会有个transition 动画过渡,而在chrome,会出现渲染问题,性能稍微差点的机子,可能就会出现,而调这个,其实也很简单,就不要transition呗,你是这样想的,对吧?当然,我也是这样想,不过这个模块,是引用别人的代码过来嵌套的,套在iframe里面,已经封装过,所以只能找代码提供方修改,于是,通过联系,找到了该同事,然后他说,这里只对高度进行transition变化,宽度没写啊,看了看:

好像确实没错啊,只写了height,然后我也就没话说,先改其它的bug去了,等到其它的bug都排查fix掉了之后,心里老觉得变扭,铁定是这里出的问题,不知道你有没有发现问题?我端倪一阵,发现怎么多了两个逗号,写法应该都不会没看过才对的,还是第一次看到这种,于是我自己写了个demo把它的这句css3套进去:

于是乎,问题出现了,我只是修改它的宽度,它还是有动画过渡效果,但是理论上,应该是没有效果的,直接唰一下就跳过去才对,接着我删了后面的变成 -webkit-transition: height 0.6s; 然后运行,就是预期的效果,然后改成:-webkit-transition: 0.6s; 只保留时间,又会出现过渡效果,所以其实,这里,浏览器在读的时候,‘,’就是一个小分句,后面会覆盖前面的,所以读 ‘height 0.6s’意思就是 对高度进行0.6s的过渡动画,而读 ‘0.6s’的时候,其实就是‘all 0.6s ease 0s’对所有元素进行0.6s的过渡动画,浏览器会把漏了的用缺省默认的补上,所以上面那句的浏览器会这样读:

你问我为什么不是直接打出来,而是截图,我只能说你问的好,不单只是会看,会想才是最重要的,然后我会告诉你我在Firefox截的,哈哈...
于是乎后来就让该同事用这句 -webkit-transition: height 0.6s ease; 简单明了的修改了下,妥妥的...
至于一个小bug 为啥要这么大费周章写个文章出来叻,这个确实是个小东西,不过我好久没写文章,手痒不给啊...
从这个问题,可以间接反映出一些其它的问题:
代码模块管理,代码封装提供接口供人调用,然而提供出去的代码触发了问题,该怎么解决?
调用别人封装代码,出现了问题,该怎么解决?
是否该调用别人的代码,调用之后后续维护成本多高?
怎么调用别人代码,降低后续维护成本?
这些就不是小问题了吧?
把‘点’放大到‘面’来看问题,看到的就不单是表面上的问题,而是项目整体,自身专业水平到哪个档...
我是一个搞页面重构的,之前头儿跟我聊的时候,问我重构是什么,我当时紧张也是,投机也是,就说 页面仔,然后我就被谆谆教导了一番,当时 举杯邀明月,基友成三人 的场面仍记于心,而在做 好莱坞影院 一年有余将近两年的现在,我又发现,其实,我真的做的就是个 页面仔,需求-交互-设计-重构-开发-发布 一条线,每个部分我都参杂了点,单把屁股擦干净,只做重构的东西,其它的不管,那是不可能的...就‘接稿’而言:
产品让设计给稿重构,重构说:哦,好,马上做,然后就开搞...
这是重构,他懂的效率办事,兢兢业业...
产品让设计给稿重构,重构说:哦,好,我看看先,评估下时间,然后开搞...
这是重构,他懂的安排需求排期时间,按序进行...
产品让设计给稿重构,重构说:哦,好,不过我这周已经排满需求了,具体安排了XX需求,你看下,我按紧急重要的先搞,后面的顺延...
这是重构,他懂的分析需求的轻重缓急,按序排期进行...
产品让设计给稿重构,重构说:哦,好,这样设计的话,预期是一天完成,不过看设计稿,可以做一些特效创意,让页面更鲜活有趣,能否在加多半天,特效搞起...
这是重构,他懂的评估时间,优化建议,并且能将加码做超出预期的工作...
产品让设计给稿重构,重构说:哦,好,不过,这里设计是否有点问题,它色调跟整体不搭,模块跟通用模块有差距,设计整体看起来好搓,看下是否有优化必要,让设计师优化一下这些细节后,我再开搞...
这也是重构,他懂的站在产品角度,去看待接手设计,并且能提出细节优化意见,从项目优化统一着手,懂的拒绝次品需求,并推进前面的流程优化...
‘接搞’感觉很简单的事,其实可以放射出这么多的问题,看出接稿的人水平档次大局观,其实不单对于个人,对于整个项目流程,都起了很大影响,在意了细节,减少了没必要的联调;拒绝了次品需求,减少了没必要的版本迭代,这些都是减少加班,提高工作效率的体现,并不是每个不加班的人就不努力,而是他懂的把自己精力用在拳头上,用拳打的猛,杀球杀的狠...
而前阵子碰到了一位同事,跟我说,某个工具很好用,工作效率提高比用之前有了提高,而对于自己,当用与否? 需要怎么考虑?
在之前的文章的时候,我提炼出来的观点是:根据项目本身的特点,制定合适的方案,强搬硬套只会把自己搞残,带着问题两面性去权衡将采取的方案,尽量保证站点可控。对项目优化的前提是对项目有一定的认知,对涉及页面能把控到位,在此基础上再谈优化。
同样,对于引用新的工具,应当有所尝试,别人说好的未必对于你自身就好,就像别人对我说,某种减肥药多牛逼,一下减去100斤,我只能冷冷的回答道:哥 增肥ing...
应当抱着问题两面性去权衡,引入之后是否会带来副作用,副作用是什么,表现在什么方面,怎么处理这些副作用,副作用带来的弊端能否盖过效率提高带来的利端,两者权衡之后,再问自己要不要用这货儿,避免不必要的后续维护麻烦...
好吧,好像扯的有点儿远,这赤裸裸就是一个transition引发的发思,看懂的应该都有体会,不懂的过多一年欢迎再来翻翻吧,我相信一篇好文章,会值得别人去看多几遍,而且每次看,都能看出新的体会...
最后给那些没看懂的同学总结一下,那个transition bug应该这样处理:-webkit-transition: height 0.6s ease; 谢谢大家,哈哈...
前一篇:好莱坞影院 项目优化分享