不论团队大小，接到项目需求后，一定会对需求进行分解，进行相应设计，系统编码，上线运行等几个环节。在各环节中，需要进行相应的评审，在实际研发过程中，以笔者自己亲身经历，由于缺乏评审，导致项目上线后吃相很难看，客户满意度也不高。以下分享一下各环境的评审内容。
一、系统需求评审。
从客户或者产品经理那拿到需求后，组织项目组人员，架构师，质控工程师等进行需求评审。这个环境可能需要反复进行，因为有的需求需要细化，有需求需要技术细节讨论，是否存在技术障碍等。最重要的是要让系统开发人员真正的理解需求，在这一环节中，宁可多花费一些时间反复确认，可以通过做原型图，UML建模的工具等和需求提供方确认。避免需求是打井而研发理解成造烟囱的尴尬局面。
二、系统设计。
在理解需求的基础上，可进行需求分解形成WBS，各研发小组根据负责模块进行具体概要和详细设计。这里可以请质控工程师和架构师共同参加评审，在形成概要设计说明书和详细设计说明书后，可以由质控同学进行设计确认，并请架构师进行系统结构梳理。
三、系统编码。
在真正进行代码研发前，有技术经理与各研发人员进行存储和数据库设计。此时，尤其重要的是需要进行数据库设计，通过预估未来几年的系统数据存储量来考虑数据库设计，怎么做查询效率更高。在不影响效率的前提下，有效避免资源浪费。尽管随着NewDb和NoSQL等各种存储百花齐放，关系型数据库依然是当前应用系统的存储大头。因此做好数据库设计是一件特别重要的事情。其次是合理的开发语言选择，现在有了微服务架构，各组件可以综合考虑自己的性能，选择最优的开发语言。在选定开发语言后，需要针对性的进行架构选型，模块调整，具体编码的话遵守行业基本规则基本没有大的问题。
四、代码评审。
在正式上线前，各模块代码编写结束，质控同学也完成测试工作，准备发版上线，此时可以组织代码上线评审。由富有经验的开发人员组织，主要用于发现代码中可能存在的缺陷，比如明显的性能缺陷，漏洞，安全风险等问题。保证上线后可以正常安全平稳的运行。
五、上线评审。
需求开发完成后，经测试确认可以上线。此时工作的重点将转换为运维部门。需要研发团队和运维同学确认系统运行指标，与需求提供方反馈研发成果，确认开发与需求的对应关系。
软件开发工作是一项系统工程，不论采用的是瀑布开发模式，还是敏捷开发模式，亦或者螺旋模式。不论哪种模式，目的都是完成交付，满足项目预期。在项目开发过程中，需要各团队充分合作，对各环节的成果进行充分评审。以上内容仅来自于笔者自己研发中所采用的方式，肯定存在不足之处，欢迎各位交流讨论。同时欢迎提供贵司在降本提效方面的良好实践。
