1.行为准则

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

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.进一步阅读资料