1. 个人经验总结

需求评估
- 确认清楚流程中的每个细节、依赖点、逻辑不合理的地方、漏洞、含糊不清处、技术实现不了的或者难点。
设计
- 分为概要设计和详细设计
- 考虑性能、安全等非功能性需求
- 可扩展性
  - 平衡好近期可扩展性和长期可扩展性。没有必要为了很久以后或者不大可能出现的情况预留可扩展性设计。
- 先想要要成什么样子和效果，再考虑方案，不然会白做的。
- 由于软件经常要升级，所以要考虑新代码逻辑对旧代码和数据的兼容（比如删除了一些菜单选项），避免出错。即使是web应用，也有缓存会导致问题。
工作量评估
- 先实事求是的细分任务，并各自给一个比较有把握的工作量，单位不用很细，以半天为单位即可。
- 要考虑到技术难点。
- 不要考虑大的可能的需求变动，太大的需求变更就要另外谈时间和工作量了，甚至要不要做。
- 加在一起后，最好留个百分之二三十的buffer时间，避免意外的技术难题、不大的需求变更、请假等。
- 可以这样建task break down
  - 按功能划分成多个相对独立的task
    - 最好工作量至少在一天以上的，太小的可以合并成一个task，起一个“其他”或者“优化”之类的名字。
    - 如果一个大功能在多个release中分步完成，可以在task名字中加上“Phase 1 - ”之类的前缀。
  - 单元测试
  - 修复code review的comments
  - 修复测试中发现的问题
文档
- 设计文档
  - 序列图。描述业务流程逻辑、微服务之间交互关系。
  - 数据库设计，如表（表及字段的划分、表名、字段名、字段类型及长度）、主外键关系、索引等。
  - RabbitMQ等消息队列设计。
  - Redis等缓存设计。
代码
- 代码整理重构可参考1. 个人经验总结 - 代码整理重构
- 代码审查（Code Review）。
  - 互相之间要大概了解做的需求。
  - 代码基本完成（包括开发者自己做的单元测试和代码重构）后再做。
  - 提前发出Pull Request请求，审查者要在基本了解需求的基础上，提前看下代码和准备想法。
  - 如果改动不太大或者人不在一起的话，可以不用开会，直接提comment或者私聊。
  - 大改动可以开会一起看。
其他
- 不论是前端还是后端开发，首先要逻辑清楚，条理清晰。
  - 比如前端开发时，如果要实现刷新数据时保留滚动条位置等特殊功能，一定要先想好在哪里、在什么时机保存滚动条状态、恢复滚动条状态是合理的，是逻辑上没有漏洞的。