这是第一次接触的较完整的开发任务，中间出现了一些问题，经过对这些问题的归类，大致包括这几类：排期、buffer、接口、测试。下面分开来说说遇到的问题与一些想法。
本次的主要开发任务是：品牌筛选与秒杀页面。
其中品牌筛选安排的排期为1d，秒杀页面前端实现为1.5d，联调2d。然而在开发过程中，实际的开发成本是：品牌筛选2d，秒杀页面2d。但是项目提测后，bug比较多，修复的时间比较长。
可见，每一个开发任务都有延期，并且延期也比较大。下面是我总结的一部分原因：
1. 自己没有把需求完全拆分，只是拆分的大层面，小层面没有注意到
2. 品牌筛选开发1d完成，但是后期后端进行接口调整，前端需要进行重新调整，多消耗0.5d
3. 品牌筛选后期，QA提需求，要求品牌筛选按钮一直显示在最顶部，又对品牌筛选的业务进行处理
4. 自己理解的只有一级分类切换品牌才会获取品牌，二级分类共享一级分类品牌，这个理解是错误的，导致后期又作了修改
5. 秒杀页面也是在自己定的时间内1.5d完成前端实现，主要是后期修改
6. 秒杀页面没有考虑到没有秒杀商品的情况，需要做处理，没有UI图
7. 秒杀的时间显示没有考虑到跨天显示的情况，需要做处理，没有UI图
8. 秒杀没有商品时，也不要显示秒杀规则，这个也没有提前弄清楚
从以上问题中可以看出来，大多数问题都是因为自己对需求了解不深导致的，很多问题没有在前期解决掉，导致后期不断的尽心修改。
下面针对自己对需求认识不深做出改进，比如：
每一个需求，多打几个问好，不要忘记极端情况，已秒杀页面为例：
1. 接口返回内容为空怎么办，页面如何显示？比如：品牌分类不显示、显示暂无秒杀商品
2. 如果内容为空，其相关内容该如何显示？比如：品牌按钮不显示、秒杀规则不显示
3. 如果内容返回的数据很多怎么办？需不需要分页或触底加载？
4. 内容过长、过短怎么办？内容为连续数字与英文该怎么显示？
5. 页面滚动时怎么办？要固定还是随内容滚动？
6. ...
以上从极端情况上手考虑该如何处理与如何显示，可以作为一种思路，依靠这种思路能解决掉之前遇到的一些问题。另外，这些需求一定要与PM进行沟通与讨论，而不是自己妄想来的，自己的妄想不能解决任何问题，要按确切的、有思想的、有验证的需求进行开发。
排期与需求紧密联系，对需求把握好了，就能安排好排期，个人认为大部分的排期不好或者delay都多数因为对需求的认知存在问题。
就比如我在上面遇到的问题，大多数都是对需求模棱两可，按照自己揣测的方案进行开发，导致最后出现了问题。
而且我的排期比较紧，自己认为会在这一段时间内完成，但是丝毫没有注意到可能受到的影响，一旦中间出现问题，我这个排期就扛不住了。扛不住就只能delay了。
解决方式（buffer）：
1. 留足前期buffer
前期buffer用于技术调研、业务代码学习、完成解决方案等
如果项目时间宽松可以考虑为2-3d，具体根据功能与需求来定
2. 项目开发过程中，也要有一些buffer
尽量自己的开发过程安排的宽松些，保证开发与自测的时间
3. 联调buffer
保证联调时间，可留的充分一些
4. 上线buffer
之所以留上线buffer，是要给自己一个总结的时间，上线完先不
要着急进行新业务的开发，要给自己一个buffer的时间进行总结与回顾。
虽然看上去buffer可以解决一切，但是这建立在对需求的详细了解上，以及对整个项目的掌控，同时，也要结合PM、RD、QA的时间进行调整，保证项目提测与上线。
开发解决方案：
我感觉这是很重要的一步，以后也会按照这个步骤继续进行下去。就是在前期buffer中，要制定一份解决方案，该方案包括项目中可能回到的技术点与解决方式，如果可能的话，也可以有测试用例。这样，把所有的难点在开发前解决，真正到开发阶段，只是对方案的代码实现，可以提高开发效率。
第一次遇到接口问题，在功能已经实现后，接口进行更改，并且不是简单的接口替换，而是完全的接口分离，这样前端必须进行调整。
问题出现的原因：后端人员在实现接口的时候没有向吴总确认，直接在原先的接口中一并返回的品牌分类。后来吴总说，这是两个功能，应该有独立的接口。
这个过程中暴露了一个问题：太被动！前端跟着后端的接口走，不能做到完全的分离，容易受后端接口影响。
如何避免这种情况？下面是我想到的一些方法：
// 沟通方向
1. 开发前，提前和后端（或其他端）沟通好，接口的内容
2. 该接口要得到确认，切实可行才可使用
// 规范方向
1. 由前端定义接口内容，这样不仅可以规范接口，前端还能脱离接口独立开发
2. 前端定义接口后后端确认，或者一起定接口。然后后端评估该接口，并进行确认
3. 尝试使用接口管理工具，并且该工具可以根据定义的接口形式自动生成测试数据
4. 或者前端建立统一的内部项目接口文档，涵盖该项目的所有接口，及时更新与维护
也没有想到其他更好的方法，但以后开发的时候会尝试先定义接口内容，然后向后端确认。接口需要考虑的内容主要为：
1. 请求方式、参数名称、参数类型、参数说明、参数示例、接口URL
2. 返回数据，返回数据格式、属性名称、类型
上述中，后端进行第一行的设计，前端可进行第二行的设计。然后开发的时候就按照该设计内容就行开发，做到规范统一。
以上暂时是自己想到的途径，后期开发会按照更规范的方向解决问题。
从刚开始透出的问题中来看，自己在测试方面做的还很不好，这也是后期出现bug多的原因。减少出现bug和弄明白需求其实是一样的。
自己在之前开发的过程中，为了减少bug的出现、测试的比较充分完全，自己尝试进行测试记录，比如：
开发完品牌筛选状态保存后，进行测试：
1. 从首页点击进入 正常
2. 从首页分类推荐进入 正常
3. 分类切换 正常
4. 品牌切换 正常
5. 分类切换后刷新页面 正常
6. 品牌切换后刷新页面 正常
7. 品牌筛选后，复制链接另外打开 正常
我觉得这是一个比较笨的方法，想方设法的找各种可能，常规的话，如果对需求了解的够深，基本上不会写出bug来。即使已经想了很多种可能，但是有时候还是会遗漏某一点，比如如果有与数据相关的时候，后台的数据也要进行多样化的测试，比如：所有的值是相同的，所有的值都是空的，一半空的、一半有值等。只能这样进行穷举似的测试。
这在以后可向他人进行请教，其他同学是如何进行自测的？如何写出健壮的程序来？
另外，也可以学习如何接入单元测试。比如：Mocha，之前没有使用过单元测试的框架，需要投入精力去学习一下。这样的话，可以每次先写测试，然后测试通过在进行开发，也可以先开发，然后之后进行测试。这一阶段目前只停留在想法阶段，后期会集中精力进行学习。
前端v1.5.1上线内容
1. 首页封闭：登录后查看商品及价格，策略服务器可控；
2. 支持秒杀活动；
3. 分类页支持品牌筛选，品牌支持后台配置；
4. 细节优化：
5. 去结算货到在线支付文案提示；
6. 购物车异常提示条UI优化；
7. ios活动页规则文案限制问题；
后台V1.5.1上线内容：
1. 秒杀商品管理，秒杀活动配置；
2. 分类页品牌配置；
3. 账号管理：查看账号优惠券明细；支持账号起送价（300/500）配置；
4. 订单管理优化：赠品在商品清单显示赠品标识。
评审时间：2016/4/14 提测时间：2016/4/28 预计上线：2016/5/10 实际上线：2016/5/13