平时开发流程

需求分析：一般是需求把要求给我们，先告诉我们要做什么，有什么盈利点。然后我们再讨论需求的重要程度，然后给出初步的排期。
需求评审：然后根据前面初步的排期，每周五的下午开会，大家一起确认，这周所有的需求的排期是否合理，然后上报上一级。
设计方案：先让产品给出具体的原型和基本的文字逻辑。根据时间开发自己初步的讨论一下可以开发到什么程度。是否需要分为一期，二期来做。然后开始设计底层的数据结构，并拉需求一起讨论后期可能的拓展性。
功能设计：根据数据结构确认功能设计的哪些模块，然后分配到具体的开发人员和开发任务。并初步确认需要哪些接口。
非功能设计：一般确认了接口，我们会需要讨论一下这些接口哪些可以复用，哪些接口需要注意什么，用来提高代码的复用性和健壮性。比如：是否需要考虑性能问题，是否需要考虑内存问题，是否需要考虑异步处理，是否需要用订阅的方式实现，是否需要使用些设计模式。
拓展性设计：这个一般是在开发过程中开发人员自己考虑，接口的封装程度。内核和外延的综合考虑，确认接口的出入参。然后根据前面讨论设计方案时的可能性，封装接口。
后期维护成本：维护成本一般都是用wiki记录好，然后后期维护自己看。
踩过的坑：

        1.需求不清晰，产品自己对需求的定义就不是很确定。只有一个大概，无法很好的对产品进行定位。然后后面一直改需求，这个一般都是排期到后面，让产品想清楚。如果时间又紧张，那么就会约定好最多的需求修改次数，后面除非是重大事故，否则轻易不改。不然开发时间严重不足，导致需要带bug上线更麻烦。

        2.时间紧急，导致加班、bug各种毛病。一般时间都是开发人员估计的1.5-2之间。不能轻易相信开发人员的评估时间，这是很重要。

        3.不爱写文档，不爱写注释。坑后面的人，代码没人敢接手。（定期代码评审，轮着来。一般都会2个月轮到一次，然后为了到时候不尴尬，一般都会写注释，写逻辑。不至于代码太乱，接口参数乱来）

        4.产品说的逻辑最好有文字，不然后面有问题，呵呵。。。