读程序员的README笔记13_技术设计流程(上)
1.读程序员的README笔记19_读后总结与感想兼导读2.读程序员的README笔记01_学习如何学习3.读程序员的README笔记02_软件的熵与技术债4.读程序员的README笔记03_变更代码5.读程序员的README笔记04_防御式编程6.读程序员的README笔记05_日志、监控与配置7.读程序员的README笔记06_测试(上)8.读程序员的README笔记07_测试(下)9.读程序员的README笔记08_依赖管理10.读程序员的README笔记09_代码评审11.读程序员的README笔记10_软件交付(上)12.读程序员的README笔记11_软件交付(下)13.读程序员的README笔记12_On-Call
14.读程序员的README笔记13_技术设计流程(上)
15.读程序员的README笔记14_技术设计流程(下)16.读程序员的README笔记15_敏捷计划17.读程序员的README笔记16_构建可演进的架构(上)18.读程序员的README笔记17_构建可演进的架构(下)19.读程序员的README笔记18_职业生涯规划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. 进一步阅读资料
合集:
读程序员的README
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】凌霞软件回馈社区,博客园 & 1Panel & Halo 联合会员上线
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】博客园社区专享云产品让利特惠,阿里云新客6.5折上折
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· [翻译] 为什么 Tracebit 用 C# 开发
· 腾讯ima接入deepseek-r1,借用别人脑子用用成真了~
· Deepseek官网太卡,教你白嫖阿里云的Deepseek-R1满血版
· DeepSeek崛起:程序员“饭碗”被抢,还是职业进化新起点?
· RFID实践——.NET IoT程序读取高频RFID卡/标签