第四次需求总结

第三次需求（开团分享多砍一刀蒙层优化）

1、发版流程

每次需求在本地测完没问题了后，merge完master，push到gitlab上，点击merge request里的，source选择自己的分支，target选择当天的dev分支，打上WIP和label标签，将链接发送到群里组内review，resolve discussion后，在命令行合入当天的htj分支，找人发一下htj环境，发好了之后告诉测试测htj，当htj测好了，再把htj分支发一下盘多多环境。测试没问题了之后，移除WIP打上绿色label，等车等待发到盘多多环境，盘多多发好了再测一下，没问题之后就会发布线上，线上再测一下就ok了。

需要注意的是，发布到盘多多环境有两种方式：

（1）从htj分支发到盘多多。（htj的盘多多）

（2）从dev分支发盘多多。（线上的盘多多）

在此处的盘多多环境本质是相同的盘多多环境，因为发到盘多多的方式不同，一般叫做htj的盘多多，线上的盘多多。建议自己需求上线的时候一定要走dev分支，因为大佬帮你上线的时候发的都是dev分支，在盘多多环境的htj分支会被dev覆盖，那样你的代码就没了，所以一定要走dev分支，htj的盘多多一般用于组内自测就可以了。

2、灰度

当上线一个新需求时一般不会全量上，都是先切一小部分流量看看效果，如果效果好的话会逐步放大流量，直到所有人都能访问到这个需求（效果不好就是改喽）。

例如需求要求新功能上线10%灰度，意思就是所有用户中，只有10%的人能够看到这个新上线的功能，剩下90%看到的还是老功能。怎么判断你是否是灰度内还是灰度外呢，当然是代码中的灰度文件了哈哈哈（我真是废话）。灰度文件会根据用户uid来决定你是灰度内还是灰度外，而不是根据用户请求（防止你这次是灰度内下次就不是了，影响用户体验还不好判断数据）。线上要测试但无法测试是否是灰度内还是灰度外，可以添加白名单，白名单内的人一定是灰度内。

若在原有灰度文件上进行修改，则要查询此灰度文件是否在别处也引用了，避免改一处影响十处的后果。。若影响文件比较多，可以写一个新的灰度文件来控制。而且第一定要注意将灰度写在前、全量写在后。而且不要把人家的代码拿过来就不管了，即使它们99%的相似度。（这次就是少加了个v3把测试都烦死了）

3、ui迭代

若ui迭代需求最好不好再同一个文件里修改，不仅代码会比较乱而且万一哪天产品突发奇想想回到最初一版呢？参见这次的v1、v2、v3。

4、css样式

真的是要死了我好讨厌调css了（虽然基本上锅都在我），谨记教训，以后写css的时候按照设计图量着来写，就算是文字宽高他也是和设计图一样的，有什么问题及时找设计师沟通。这次真的。。ok我死了。

5、低版本手机

有些样式在低版本手机上可能出现不兼容的问题，所以本地测得时候拿低版本手机连代理先自测一下，少用transform。（如何孝敬父母？回家给父母升级一下手机系统，不仅会用到更多新功能，而且在逛app时也觉得华丽好看哦~）

6、在文件里获取图片时将代码提到组件外面，看着更清晰。

7、若涉及到z-index问题，可以调整dom顺序。例如这次蒙层问题，蒙层也是有z-index的。

8、当需求写完时，要检测页面是否有无用代码，删除无用代码。

9、先review再合htj！！！！！！！！！

10、每次有打点需求时都要在network里的.gif文件看一下打点情况，避免打点重复或者打不上点（参见店铺优惠券，在最外层曝光时写了打点参数，里面的包裹的logdiv点击不用写参数）。去c端打点系统手动校验一下日志。

11、灰度文件注意congif引入是否正确，不要因为代码相似粘过来就不管了！！（还在模仿他人写代码的阶段）

12、设计图一般不会垂直居中的，因为顶上有kjmfn的头，若垂直居中会看起来比较偏下，还是top：固定rem比较好。