1. 任务分类
   1>feature
   2>bugfix
   3>polish

   实际分类，新功能，一般是不会在发布日左右提出的，所以ban
   主要的是bug修复和部分polish
   我将其分为

   1. 逻辑bug
      1> 影响主流程的bug（比如搜索内容清空之后，再次搜索就没有内容了，这就属于卡住的业务流程，需要重点关注）
      2> 看起来很怪异的bug （比如搜索之后，没有清空上一次搜索渲染的内容，虽然没有卡流程，但是也是明显错误，次要关注）

   2. 逻辑与样式交融的bug
      1> 因为目前框架是逻辑和表现是有交融的，所以很多样式问题其实也会映射到逻辑上，三级重视

   3. 样式bug
      1> 样式崩坏的问题，比如说本来应该在一行内展示完的文字，换到两行展示了，比如说页面中内容部分覆盖到了侧边栏部分了，这都属于比较严重的样式问题，同样三级重视
      2> 设计感上的样式问题，比如说该在同一行的内容，看起来不在同一行，页面中有些部分字体大小不太符合，这些其实发布了可能用户也看不太出来，但是不得不说这一项最好修改

      个人排序：理论上来讲，这些内容时间允许的话是都需要修改的，但是时间不允许，他们的优先级就会自上而下排序，首先可以放弃的是设计感样式问题，如果时间有问题，三级重视问题也可以考虑放弃，但是重点是不要被看出来有问题，前两种问题基本是都确定要修改的。
      当然还有一个时间安排问题，因为优先级高的问题，其实难度很高，所以可如此安排，一级问题如果一小时内没有明显进度，可以暂时放弃，列为讨论范围；二级问题，如果半小时内没有明显进度，列入讨论范围，三级问题以下，十分钟内没有明显进度，列入讨论范围内

2. 质量问题
   这也是我需要改善的问题，也是整个team需要不断考量的问题，分为以下两类
   1.产品质量
   该问题说起来感觉不是很重要，而且难以思考，因为大多时候，我们程序员，尤其初级程序员更多的关注这个功能是否能够执行，而不是是否可以优秀的执行。故主要有以下两个观点
   1> 不断思考，锻炼产品思维，用户思维。很多时候，需要有一种体验感，这种体验感可能在紧急开发功能的时候是没有必要的，但是在开发完功能的迭代时间中是有必要的，比如说体验某些按钮是否用的舒服，点击进入某种状态之后，怎么退出这种状态等等
   2> 讨论，询问。可以多和产品交流，多和潘哥交流，多和设计交流。很多优化，其实也不是我自己思考出来的，也都是设计，产品，cto讨论或者建议的，我觉得都是很优秀的建议，而且希望要主动，不要总说没人对，没人管，然后最后提交的时候发现还能做诸多优化。
   2.代码质量
   这是一个更难思考的问题，因为每个人都有不同的代码风格，每个人也有不同代码思考，是使用if ....elseif.....else，还是使用if return....if return等等，每个人都有不同的选择，但是在这些个人风格之上，我们还是得有一些求同存异的必须统一
   1> 命名问题
   尽量减少重复命名，如果有，也尽量语义化，并且让命名符合词性。比如，代码中需要描述一个列表，在各处都有与之相关的内容出现，我们在上下文绑定了一个渲染变量，noteList，可能api也会返回一个noteList，这比较难以控制，所以也可以接受。但是其他地方使用的时候，除非是获取了他本身，比如
   const noteList = this.noteList，
   否则，不要再轻易使用noteList这个名称，如果临时我们整理了一个同样类型的值要放入上下文中，请不要

        let noteList = api.noteList
        noteList = fn()
        this.noteList = noteList
   

这样的代码很容易让人疑惑，当然这可能也跟后端的返回有关，但是无论如何还是希望引起重视
2> 逻辑问题，每一个模块都是一个状态机，我们要用代码去实现各个状态的变化，在状态变化之中，我们肯定会有很多变量来控制这些状态的来回，当然，每个状态之间的变化可能也有多条路径，这些我们都要控制好，在状态变化的过程中，在每一条路径控制好必须要变的变量，同时注意每一条路径各自独立的变量