读程序员的README笔记14_技术设计流程(下)
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-Call14.读程序员的README笔记13_技术设计流程(上)
15.读程序员的README笔记14_技术设计流程(下)
16.读程序员的README笔记15_敏捷计划17.读程序员的README笔记16_构建可演进的架构(上)18.读程序员的README笔记17_构建可演进的架构(下)19.读程序员的README笔记18_职业生涯规划1. 撰写设计文档
1.1. 设计文档以一种可扩展的方式来清楚地传达你的想法
1.2. 写作的过程会使你的思维结构化,并凸显出薄弱的环节
1.3. 把注意力集中在最重要的变更上,牢记目标和受众,练习写作,并保证你的文档是最新的
1.4. 文档持续变更
1.4.1. 并非每一项变更都需要设计文档
1.4.2. 3个标准来决定是否需要设计文档
1.4.2.1. 该项目将需要至少一个月的工程时间
1.4.2.2. 变更将对软件的扩展和维护产生长期的影响
1.4.2.3. 变更将显著影响其他团队
1.5. 了解撰写文档的目的
1.5.1. 设计文档是告诉别人某个软件组件是如何工作的
1.5.2. 设计文档的用途超越了简单的文档
1.5.2.1. 设计文档是一种工具,可以帮助你思考、获得反馈、让你的团队了解情况、培养新的工程师,并推动项目规划
1.5.3. 即使是在反馈很少的情况下,分发设计文档也能让团队了解情况
1.5.4. 传播设计知识将帮助其他人保持对系统的工作方式拥有准确的心理认知
1.5.5. 设计文档对于刚加入团队的工程师来说特别有帮助
1.5.5.1. 阅读大量的设计文档则要有效得多
1.5.6. 管理者和技术负责人使用设计文档进行项目规划
1.5.7. 如果一个项目是跨职能的,有了具体的设计文档,就更容易与其他团队协调
1.6. 学会写作
1.6.1. 写作拥有一种暴露你不知道的东西的能力
1.6.1.1. 编外:在这一点上我深有感触,非常同意
1.6.2. 写作作为一项技能,是通过实践来进步的
1.6.3. 写得清晰会让你的生活更轻松
1.6.4. 写作是一种有损的信息传递方式
1.6.4.1. 你把你的想法写下来,而你的队友则在他们的头脑中不完全地重建你的想法
1.6.4.2. 好的写作可以提高这种传递的还原度
1.6.4.3. 好的写作能力会为职业生涯添砖加瓦
1.6.4.4. 一份写得好的文档很容易被传阅给大团体,包括高管,而优秀的写作者不会被忽视
1.6.4.5. 你是否理解并不重要,重要的是他们是否能理解
1.6.5. 文档要简明扼要
1.6.5.1. 为了帮助你获得读者的视角,你需要去阅读别人写的东西
1.6.5.2. 想一想你会如何编辑他们的文章:哪些是多余的,哪些还需要补充
1.6.6. 不以母语为交流语言的开发者有时会对书面交流感到畏惧
1.6.6.1. 不要让语言障碍使你对撰写设计文档望而却步,不要担心语法是否完美,重要的是清楚地表达你的想法
1.7. 保证文档是最新的
1.7.1. 在从提案到文档的过渡过程中,有两个常见的陷阱
1.7.1.1. 第一个陷阱是提案文件被废弃了,再也没有更新
1.7.1.1.1. 实施过程中出现了分歧,而文档会对未来的用户产生误导
1.7.1.2. 第二个陷阱是,文档虽然被更新了,但提案的历史记录却丢失了
1.7.1.2.1. 未来的开发者无法看到那些导致设计决策的讨论,可能会重蹈覆辙
1.7.2. 务必保证你的文档是最新的
1.7.2.1. 如果你的设计提案和设计文档是两个独立的东西(比如Python PEP[插图]和Python文档),你需要使文档与已实现的方案保持同步,确保有其他人在你进行代码评审之后同步更新文档
1.7.3. 你需要对你的设计文档进行版本控制
1.7.3.1. 一个优秀的技巧是将设计文档与代码放在同一个库中进行版本控制
1.7.3.2. 代码评审也可以作为设计内容的评审意见,这些文档也可以随着代码的发展而更新
1.7.3.3. 请保留文档的整个历史记录,也包括讨论的内容
2. 协作设计
2.1. 与你的团队进行建设性的合作将产生更好的设计,但合作并不总是容易的
2.2. 理解你的团队的设计评审流程
2.2.1. 设计评审通知架构师即将发生的大型变化,并给潜在的使用者一个提供反馈的机会
2.2.2. 架构评审委员会和“请求裁定”(request for decision)是两种比较常见的方式
2.2.3. 不要等到最后的批准才开始写代码,要花时间实现原型和概念验证的“尖峰”,以增加对设计的信心,并给你一条更短的生产路径
2.3. 不要让人惊讶
2.3.1. 你需要有礼貌地并且渐进地让人们了解你的设计方案
2.3.2. 反馈会议不需要是正式的,也不需要专门来安排
2.4. 用设计讨论来进行头脑风暴
2.4.1. 头脑风暴会议的规模从2人到5人不等
2.4.2. 当一个问题特别多元或有争议时,要选择更大、更有包容性的头脑风暴会议
2.4.3. 设计讨论会议需要安排大块的时间,一般为两个小时左右
2.4.3.1. 思想需要时间来发展,尽量不要缩短讨论时间,让人们没有想法,或者只能疲于应付
2.4.4. 可能需要多于一次的头脑风暴会议来得出结论
2.4.5. 不要强加太多的条条框框在会议本身,思想需要“跳来跳去”才能探索想法
2.4.6. 在头脑风暴会议期间,做笔记可能会分散注意力
2.4.6.1. 白板也是一个“记录员”,你可以在讨论过程中拍照
2.4.6.2. 如果使用虚拟板,则可以保存中间的状态
2.5. 为设计出力
2.5.1. 你应该为你团队的设计工作贡献力量,而不仅仅是你自己的
2.5.2. 运用我们为代码评审提供的相同的指导,对设计进行全面的思考,考虑到安全性、可维护性、性能、规模等,要特别注意设计是如何影响你的专业领域的
2.5.3. 沟通要清晰,要尊重他人
2.5.4. 提出问题和给予建议一样重要,问题会帮助你成长
2.5.4.1. 你可能不是唯一对某项设计决定感到疑惑的人,所以你的问题也会帮助其他人成长
合集:
读程序员的README
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】凌霞软件回馈社区,博客园 & 1Panel & Halo 联合会员上线
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】博客园社区专享云产品让利特惠,阿里云新客6.5折上折
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· [翻译] 为什么 Tracebit 用 C# 开发
· 腾讯ima接入deepseek-r1,借用别人脑子用用成真了~
· Deepseek官网太卡,教你白嫖阿里云的Deepseek-R1满血版
· DeepSeek崛起:程序员“饭碗”被抢,还是职业进化新起点?
· RFID实践——.NET IoT程序读取高频RFID卡/标签