工作小结-2018七月(2)

本周完成了盒子2.1.0的绝大多数功能，等着周一上架。

这次开发遇到了巨大的问题。在上上周一根据时间计划安排来确定了时间，结果噩梦般的产品后续大概全面改版外加更新了接近100%的内容，然而deadline没有变。

第28周的工作压力特别大，每天搞到9点多，周末还来加班，总算紧赶慢赶赶完了。

总结一下工作遇到的内容。

首先是功能开发，本次更新了整个流程，因此开发了不少新功能和新需求。

盒子页面直接取消，变成了一个常驻的view，如果此时使用单独的view区域的话，工作量比较大，因此改成了单一的popupwindow，不过是常驻的，每个使用的地方直接发一个eventbus即可。

订单流程的更改，做了实时订单更新的操作，由于需要与盒子同步，因此直接使用了cartutil中的更新类来实时更新，比较取巧。

另外写了一些单独抽出来的页面，对于页面之间的回调，反转等写了较多的操作。

遇到的问题除了一些比较小的之外，有印象的特殊的有2个。

一个是妆容算法功能丢失问题，新的版本发现妆容无效了，debug发现妆容文件丢失，切release版本之后发现妆容有但是仍然无效。检查了一通之后发现是新的登陆流程简化把妆容也给简化了，导致妆容一直没有初始化。同时由于debug版本不会执行妆容文件的压缩，导致debug即使添加了登陆流程，也依旧无效。总结下来这个地方当时是2个不确定点，而且运行环境不同，也算一个不确定点。

解决这个问题并没有花费太多时间，修改了初始妆容的地方，然后单步调试到了jni，发现native代码没有执行，之后对比编译脚本，发现是debug包不会打包压缩妆容的步骤。但是因为这个原因和leader产生了一些争执，他认为单步调试可以解决一切。但是事实上单步调试一般只会用在有唯一一个变量或者变量串行的情况下，而在变量并行的时候，如果看不懂流程，而是光调试，那是毫无作用的。

还有一个问题，是关于和产品的交涉。由于第一版给的设计图基本上就是一个原型图，过于草率，当时开会大家过目之后觉得还可以，就这么做了。导致后期交涉十分无力。产品一天能改三版，设计又不懂逻辑，没版都能缺个七八个点，导致那边越改，我们这边越麻烦，火气也越大。

事实上对于产品来讲，他们并不会意识到我们在做什么，他们很直观的认为某个功能不麻烦，于是一系列不麻烦的小功能凑成了一个大麻烦。这在前期还好，可改动的机会比较多。但是后期房子都起好了再让我们打个壁炉基本上就需要砸墙了。砸墙的时间是个巨大的问题。所以关于这种情况，我们理智沟通一下其实还是可以的，明确告知这个需求和那个需求或许会有冲突，如果非要加的话需要时间，而且不排除会有很多bug。这样产品也会为了项目周期的稳定性而进行必要的取舍。事实上很多需求，他们也不知道应不应该加。

这周的工作大致如上。