1. 个人经验总结

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