项目过程分解
通过本次消息中间件系统的全程参与，对于软件项目从无到有的生产过程有了较深入的了解，尤其对于架构设计的决策过程和依据，有了全面的认识。整个项目过程从无到有依次可以分解为九个过程，下面一一道来。
（一）背景分析
主要是要分析清楚三个问题：
1. 这个项目的诉求是在什么业务现状下产生的？
2. 最终要解决什么问题？
3. 有什么价值？为什么要做背景分析呢？
1. 更透彻的分析需求
所有的需求分析过程都要围绕这上述三个问题来，不能偏离。
2. 更主动的做事；
当你做一件事情的时候，如果不理解为什么要做，只是单纯的做事的时候，其实是缺少主动性的
3. 获得上级的支持。
有了上级的资源（人力、时间）支持，项目能够更加的顺利。
（二）需求收集和分析
需求分为两类：
1. 功能性需求
功能性需求一般是项目组内分析得出的该系统需要具备的一些必备特性。对于消息中间件系统来说，如：发布消息、拉取消息、订阅……
2. 业务性需求
业务性需求一般是从潜在的系统用户（周边项目组）那收集到的一些业务特性和使用习惯，针对这些业务特性和使用习惯，分析我们的系统是否能满足。对于消息中间件系统来说，如：业务系统习惯主动推送消息，不希望拉取消息；业务系统熟悉MySQL，希望底层存储使用MySQL；业务系统现有方案的数据格式是JSON，不希望换数据格式。对于业务性的需求，我们要有所区分和取舍，不一定所有的业务特性都能够同时满足。
（三）业界方案研究
基于背景分析和需求收集分析，收集类似的实现或方案。通过对这些实现或方案的研究，了解其关键特性和主要适用场景。最终决定是自研，还是在某个业界实现上做二次定制开发。
（四）架构设计
架构设计就是是一系列的系统关键环节的技术决策。如：
- 通信协议
通信协议使用TCP还是HTTP？
传输格式采用JSON还是XML？
- 持久化
数据存储使用MySQL、SQLite还是Redis？
数据存储是否需要支持多种持久化方案？
- 交互方式
客户端和服务端采用同步交互还异步交互？
采用消息推送还是消息拉取模式？
- 日志方案
是否记录Binlog？
Binlog是否实现主从同步？每一个架构设计决策之间是互相影响甚至可能是互斥的关系，这个时候要有取舍，取舍的标准就是先看对与错，后看好与坏。对与错取决于方案的功能属性，好与坏取决于方案的质量属性。
方案的功能属性是指其基本功能点；而方案的质量属性是指：
1. 性能
2. 成本（硬件成本）
3. 可扩展性/可伸缩性
4. 可靠性
5. 复杂性
6. 运维
7. 其他 如：合规性、安全性……很多架构设计决策在后续的项目环节要进行验证和实现，经过进一步的验证和分析，很可能推翻之前的决策。
（五）需求管理
分析需求的优先级和依赖关系，规划版本，确定时间点。最好使用需求管理工具，便于跟踪。
（六）功能设计和开发
理清楚各个功能之间的逻辑关系，设计功能的关键逻辑，编写代码实现，最后自测验证。
对外提供的API要特别注意其易用性，对外暴露的越少越好，否则内部变动很容易影响使用方。
（七）功能测试
（八）性能测试
要特别重视性能测试，通过性能测试能够发现很多我们程序的关键Bug。
（九）资料编写
包括系统设计的关键决策过程、开发指南、部署指南、配置说明以及技术沉淀总结。
资料编写的过程也是重新审视整个项目的过程。
改进和提升
本次项目开发过程采用敏捷流程，从实践效果来看，总体效果不错。
1. 简短的项目晨会，却能够很清晰的反映项目组成员的工作进度和遇到的难题，及早暴露问题。
2. 每周一个冲刺版本，这样小版本迭代能够快速试错，也保证了开发和测试的同步进行，提升了效率。
3. 需求依赖分析和优先级分类，能够保证我们开发出来的版本总是一个可用的版本。
4. 每个冲刺版本的代码Review和评审会议效果非常好，不但能够让其他项目组成员熟悉代码，关键时刻快速补位；而且能够避免由于对架构设计的理解不一致，导致功能逻辑问题。
5. 发布版本的FMEA评估效果也非常好，能够发现很多异常场景下的逻辑漏洞，对于提升版本质量很有帮助。
改进点：
1. 对于每次项目会议，最好都有专人负责会议记录，避免一些关键决策过程遗失。
2. 项目组最好都是用统一的代码模板，这样看代码效率能提升不少。
3. 对于废弃的代码，坚决删除，避免保留和注释，这样能保证代码的清晰。
4. 在项目设计和开发之前，就要做好框架的知识储备，否则很容易因为不熟悉开发框架而延迟开发进度。本次项目就因为对于Netty没有提前熟悉，导致SDK第一个冲刺版本延迟。
5. 在设计和开发过程中，对于一些关键决策最好和项目组其他成员讨论评审一下，否则很容易返工。
6. 自测联调时，不能只关注是否调用成功，还需要检查数据有效性和业务逻辑性，否则会浪费测试人员时间，导致重新打包。
7. 性能测试要做好测试计划，提前熟悉测试工具，避免做很多无用测试。
8. 项目管理工具UAPD最好能够提供需求任务列表，能够让开发人员一眼看到自己负责的任务和完成时间。
9. 对外API在设计接口时，最好先和业务使用方进行沟通，尽量满足其使用场景；如果实在无法满足某个场景，可以采用高层接口和底层接口相结合的方式，即：高层接口更加便利，但是只满足部分场景；底层接口能够支持更加灵活的定制，使用起来相对麻烦一点。