专题需求总结

一.专题下发流程

二.流程规范

1.需求理解

(1) 业务代码了解不深，基础。
专题按照自营内容去写：专题和自用内容下发逻辑差不多，但是在结构方面有区别，不能全部生搬硬套。
套用UC专题的设计。
(2) 需求理解不到位，边做边理解需求。
一开始需求不能完全理解，想着边做边理解，但是这样做的结果就是到测试的时候会留下特别多的逻辑漏洞，花大量的时间改bug，非常不合算。

(3) 忠于原型，不能根据想象做需求。 Image 6.png
Image 5.png 专题名称颜色一开始写了个颜色选择器，可以选择多种颜色。但是产品想要的效果是：专题颜色只能在这6种颜色中选择。

2.设计

1. 代码或逻辑上的设计几乎没有，只设计了数据库。
   recoid得分榜排行，专题-频道-资讯关系，编辑启用禁用操作等都应该提前设计，有个设计文档的输出。
   文档不一定很正式，也可以是在纸上画出来的个逻辑流程图。

3.测试(自测)

1. 自测报告。自测是必要的，一方面可以保证需求上的细节不会被漏掉，另一方面可以保证保证功能正常。但是这时候bug比较多，时间比较紧，所以，对着需求文档写自测报告是一种比较好的方式。
2. 给产品经理看功能，让产品在这个阶段把关。

4.复盘与改进(自测)

1. 需求做完，必须要有总计和反思的过程，而且要有输出。
2. 改进。 Image 7.png
   

   一键测试在启用或禁用的状态下都可用。

三.BUG问题

1.由需求不理解带来bug
2.由技术基础不牢固带来的bug

//set塞入
hset(1,2,3)
hset(1,3,3)
//del删除
hdel(1,2,3)

HDEL key field [field1,field2 ...]

加强基础技术的积累。
3.由思考不严谨带来bug

敏感词过滤导致专题不能连续下发：
recoid1-->recoid2 ==null ?recoid1:recoid2
recoid1找到了新内容，但是敏感词给过滤掉了，这种情况也应该下发recoid2

4.NullPointException！！！只要可能出现空对象的地方都加个空指针异常。

四.技术积累

1.linux基础命令
2.服务器压测部署

五.其他

1.调试：尽可能的本地调试
2.尽善尽美的做事情