今天完成的事：今天主要的事情是把修复好的bug发布到dev环境，然后给测试人员演示，由于有两个地方有做修改，一个是在导航地方，由于有多种情况，从线上学习进到个人主页，从学习资料进到我的主页，进到日报等这些地方的时候，带的参数出现了重复的情况，然后导航栏就同时高亮了。然后我在修改的时候，直接图简单，

<li ng-class="{active: $state.includes('skill.school')||vm.schoolDaily}" ng-click="statusJudge()">
    <a ui-sref="skill.school({uid: userData.id})">我的学院</a>

在判断的地方直接在影响的数据后面加了&&！学习资料高亮的条件。  虽然达到目的了，但是，一是没按照逻辑来，二是判断的不全面，即使这种情况下达到了目的，但是还存在隐患，就是其他条件没有考虑进去，

看师姐理清思路，将职业殿堂，线上学习，我的学院，学习资料，一条一条列出来，然后查看在哪些功能下面属于哪个模块。好好学习了一波，代码还得再自己研究一遍，自己过一遍。

还一个就是 ，由于之前是前端跨域验证现在修改成了接口验证，修复之后Nginx以及新接口部署，也是需要流程的一个步骤，一方面想的太简单了，以为就是将修改好的Nginx步上去就好了，所以没有重视，在dev环境上面发现该问题会导致地址验证栏会验证失败，然后让后端人员部署到了dev环境，然后晚上在测试环境测试的时候，将后端返回的数据都检查了一遍，发现有问题还让后端部署了一下。然后就是没有检查提交任务的地址栏验证。这个，，属于工作上的过失。检查不仔细导致的明天上线时间需要往后推迟，

          觉得吧，每个环节都是很重要很重要的，都是不能忽视的，否则都会造成影响，这要是要交付给客人的话，已经造成了很严重的后果了。

因为之前一直在本地和dev环境上面没有问题，然后测试环境上面检查到自己的数据和后端修改的一个参数都有更新上去了，就忽略了最重要的一个验证。

收获：也不能只自责不补救，还是要好好反省一下。总结一下，把整个流程自己写下来，然后下次在执行的时候对着流程来一步一步执行，修复bug之后，要每个bug都检查到位，不能想当然，就像，不能相信用户输入的任何东西一样~~

明天的计划：对着wiki将字段全部添加上去，然后在有时间的情况下，写假数据，或者用同类型的其他字段进行添加。将指派的任务全部写出来等待接口和ui。