# 分析需求
需求的提出 --- 实现xxx功能
需求原型 --- 简单的布局
# 需求宣讲时注意的问题
- 参与产品功能讨论
- 理解解决什么问题
- 理解产品功能的价值
- 考虑用户体验
# 考虑的问题
- 需求的完整性
- 需求的合理性
- 需求的一致性
- 需求的兼容性
- 需求的性能要求
# 初步分析将来的需求
- 了解同类系统的功能
- 了解产品的定位
- 咨询专业人士
# 分析复杂的需求
- 分拆需求
- 画出业务流程图
# 挖掘需求的本质
- 分析业务用例
- 抽象业务的本质
- 概要设计套路
# 性能分析
- 估计当前产品用户量
- 估计最大高峰时的请求数
- 获取新的阅读项的性能问题
- 答案图片加载速度的问题
# 基于需求本质的详细设计
# 实体的设计
- 定义实体对象的属性和数据类型
- 统一的命名规范
# 轻量的数据访问层设计
- 基于业务层接口的设计，设计数据库访问层的接口方法
- 统一的命名规范
- 接口保持轻量化
# 敏捷开发中的详细设计任务
- 业务接口的定义
- 领域模式的定义
- 数据持久化层接口的定义
- 数据库表的存储设计
- 关键业务设计模式的选用
- 关键业务模块的设计方案
- 关键方法的实现算法
# 详细设计对产品的好处
- 更快的产品迭代
- 更好的用户体验
- 更少的用户投诉
- 为构建高并发、高可用和高扩展的应用打下良好的基础
- 在产品迭代中，“越跑越快”
- 有效降低程序，“推倒重来”的概率
- 减少产品运行中的事故
# 详细设计对个人的好处
- 更加清晰、严谨的逻辑思维能力
- 良好的面向对象设计能力
- 提高个人成就感
- 越来越喜欢写代码，更加轻松、自行的工作
- 更多的Offer、更多Money
软件在能够复用前必须先能用
# 如何学习详细设计
优秀程序员的特质
拥有学习的热情
优秀的自律性和主动性
发现问题、分析问题（重点）、解决问题
良好的编码习惯
严谨的程序思维
具备一点产品思维
优秀的详细设计，是在业务场景、开发周期、技术架构等因素综合考虑的结果。
要具备以下能力
- 成为一个优秀的程序员
- 良好的面向对象思维
- 懂得如何在设计思路、开发周期、业务需求之前的取舍
- 熟悉产品技术架构模式
- 深入了解产品行业，熟悉业务的细节，并能洞察业务的未来
初学者的学习思路
- 具备成为一个优秀的程序员的潜质
- 从每个方法、每个类起一个好的名字坐起
- 培养实现代码前，做详细设计的习惯
- 让总结成为一种习惯
推荐书籍
- 代码整洁之道
- 重构-改善既有代码的设计
- 敏捷软件开发：原则、模式与实践
- 设计模式
- 高效程序员的45个习惯
大部分好的程序员编程不是为了钱或名望，而只是因为纯粹的乐趣。
# 纤细设计纵横谈
详细设计，永远吧“解决当前问题，放在第一位”
纤细设计中，好的设计终究会被采用
欢迎“拿来主义”，优先考虑使用市面上成熟产品。节约成本。单无法实现个性化服务。
优秀的判断力来自经验，但经验来自于错误的判断。
# 如何表达设计
- UML（不适合追求简单，快速，拥抱变化的设计中来表达设计）（适用于系统设计、详细设计交流，设计评审、系统设计文档）
- 文档（文档维护成本较高）（试用与经验继承，经验交流）
- 白板（容易忽略细节，实际代码和讨论可能有偏差）（适用于设计方案的实时讨论）
- 代码（敏捷开发中的纤细设计）
在敏捷开发中，我们提倡设计即编码。（定义方法、参数，注释功能，但不去实现）
在详细设计过程中，产生如下具体的产物：
- 设计实体类
- 设计前后端调用方式以及数据格式
- 设计业务接口
- 设计数据库访问接口
- 设计数据库表结构
基本命名规范
- 驼峰命名法（小驼峰（方法）、大驼峰（类、接口））
- 具有正确的业务含义
- 避免误导
- 避免使用复杂的单词
- 借用类型表达含义
- 基于约定的命名（框架的约定）
- 按技术含义命名
抽象类，AbsractXX
自定义异常类，XXException
测试类，XXTest
设计模式，XXFactory，XXVistor
队列，XXQueue
后台任务，XXTask或XXJob
网友评论