读程序员的README笔记13_技术设计流程（上）.png

1. 行为准则

10-行为准则.png

2. 设计过程的螺旋式上升

10-设计过程的螺旋式上升.png

2.1. 圆锥体中的箭头进一步螺旋式上升

2.2. 你现在更确定你理解了问题空间

2.3. 你的原型为你的解决方案提供了越来越多的信心

2.4. 随着每一次迭代，设计文档变得更加清晰和详细

3. 技术设计流程

3.1. 当被要求对系统进行修改时，大多数入门级工程师会直接跳入编码环节

3.2. 技术设计流程可以帮助每个人就某项大型变更的设计达成一致

3.3. 正确地完成、参与和领导技术设计工作是很有意义并且有价值的

3.4. 单独的深入思考和协作的小组讨论

3.4.1. 研究、头脑风暴和写作构成了深度工作

3.4.1.1. 外界干扰是深度工作的“杀手”

3.4.1.2. 避免所有的交流方式

3.4.1.2.1. 关闭聊天

3.4.1.2.2. 关闭电子邮件

3.4.1.2.3. 禁用电话通知

3.4.1.2.4. 换个地方坐

3.4.2. 设计讨论和对设计文件的评论构成了合作的部分

3.4.2.1. 有形产出是一份设计文档

4. 设计的思考

4.1. 设计漏斗的基础是从探索开始的

4.1.1. 在制定设计方案之前，你需要了解问题空间和需求

4.1.2. 探索既是一项个人运动，也是一项团队运动

4.2. 定义问题

4.2.1. 首要任务是定义和理解要解决的那个（或那些）问题

4.2.2. 需要了解问题的边界，以便知道如何解决它，并避免构建错误的东西

4.2.3. 用你自己的语言向利益相关者重述问题，询问你的理解是否与他们一致

4.2.3.1. 如果有一个以上的问题，询问哪些问题是最优先的

4.2.4. 完善的问题描述将导致一份与原来截然不同的解决方案，工程师可聚焦在问题上并列出优先事项

4.3. 着手调查

4.3.1. 不要从问题定义直接就过渡到“最终”设计

4.3.2. 考虑相关的研究、替代的解决方案，以及权衡各方案的利弊

4.3.3. 你提出的设计不应该是你的第一个想法，而应该是你若干想法中最好的那个

4.3.4. 网上有大量的资源，看看别人是如何解决类似问题的

4.3.5. 行业大会是另一种可供检查的资源，幻灯片或录音通常会在网络上公布

4.3.6. 不要忘记学术研究，利用论文末尾的参考文献部分来寻找更多的阅读材料

4.3.7. 与你正在探索的问题领域的专家交流

4.3.7.1. 注意与外人交流时不要泄露公司的专有信息

4.3.8. 批判性地思考

4.3.8.1. 一个特别常见的错误做法是将一个与你的问题相似但不完全相同的解决方案全盘复制

4.3.8.2. 你的问题不是谷歌的问题（即使你在为谷歌工作），尽管它们看起来很相似

4.4. 进行实验

4.4.1. 实验会让你对自己的想法增长信心、暴露出设计上的权衡，并澄清问题空间

4.4.2. 不要迷恋你的实验性代码

4.4.2.1. 你要尽可能快地学习到更多的东西

4.5. 给些时间

4.5.1. 好的设计需要创造力

4.5.2. 设计需要深入思考

4.5.3. 你不会在你锁定的整段时间内进行“设计”

4.5.3.1. 你的大脑需要时间来放松

4.5.3.2. 休息一下，给自己一个呼吸的空间

4.5.3.3. 允许你的思想放松和游荡

4.5.3.4. 去散步、泡茶、阅读、写作、画画

4.5.4. 设计是一种每天24小时都在进行的工作，所以要有耐心

4.5.4.1. 你的大脑总在酝酿着各种想法，创意想法会在一天内随机出现（甚至在你睡觉的时候）

4.5.5. 轻松的设计方法并不意味着你可以永远这样做

4.5.5.1. 设计尖峰(design spike)是管理创造性工作和可预测的交付之间的紧张关系的一个好方法

4.5.5.1.1. 尖峰是极限编程(extreme programming，XP)的术语，指有时间限制的调查

5. 使用设计文档模板

5.1. 概要

5.2. 现状与背景

5.3. 变更的目的

5.3.1. 软件团队往往拥有超过他们能同时应对的极限的项目

5.4. 需求

5.4.1. 面向用户的需求

5.4.1.1. 从用户的角度定义了变更的性质

5.4.2. 技术需求

5.4.2.1. 包括解决方案必须满足的硬性需求

5.4.2.2. 技术需求通常是由互操作性问题或严格的内部准则引起的

5.4.2.3. 服务水平目标也可以定义在这里

5.4.3. 安全性与合规性需求

5.4.3.1. 确保安全性的需求得到明确的讨论

5.4.3.2. 数据保留和访问政策通常包括在这里

5.4.4. 其他

5.5. 潜在的解决方案

5.5.1. 撰写这部分内容对你和读者来说都是一种工具

5.5.2. 目的是迫使你不仅要思考你的第一个想法，还要思考其他的想法和它们之间的利弊

5.5.3. 描述合理的替代方案，以及你为什么拒绝它们

5.5.4. 描述潜在的解决方案将预先解决“为什么不做××？”的评论

5.5.5. 如果你因为错误的原因而否定了某个解决方案，评论者就有机会发现其中的过错，甚至可以找出你没有考虑过的替代方案

5.6. 建议的解决方案

5.6.1. 描述你所确定采用的解决方案

5.6.2. 要比概要中简短的描述更加详细，并且可能包含突出变化的图示

5.6.3. 如果你的建议包括多个阶段，请解释该解决方案是如何从一个阶段发展到另一个阶段的

5.7. 设计与架构

5.7.1. 系统构成图

5.7.2. UI/UX变更点

5.7.3. 代码变更点

5.7.4. API变更点

5.7.5. 持久层变更点

5.8. 测试计划

5.8.1. 不要事先定义每项测试，而是去解释你计划如何去验证你的变更

5.9. 发布计划

5.9.1. 描述你将使用的策略，以避免复杂的部署顺序需求

5.9.2. 记录你需要设置的特性开关，以控制新版本的展开

5.9.3. 想一想你将如何发现你发布的变更是否生效

5.9.4. 在发现问题时你将如何回滚

5.10. ⑩遗留的问题

5.10.1. 明确地列出设计中尚未回答的紧迫问题

5.10.2. 征求读者意见的一种好方法，并说明你的“已知的未知”

5.11. ⑾附录

5.11.1. 加入额外的令人感兴趣的细节

5.11.2. 添加相关工作参考

5.11.3. 进一步阅读资料