读程序员的README笔记14_技术设计流程(下)

这篇具有很好参考价值的文章主要介绍了读程序员的README笔记14_技术设计流程(下)。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

读程序员的README笔记14_技术设计流程(下)文章来源地址https://www.toymoban.com/news/detail-760611.html

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笔记14_技术设计流程(下)的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 读程序员的README笔记09_代码评审

    4.4.1.1. walk-through 4.4.1.2. 一种面对面的会议,开发人员在会上共享他们的屏幕,并引导队友了解正在进行的修改内容 4.4.1.3. 是启发想法和让你的团队适应代码修改的好方法 5.1.2.1. 如果紧急度不明确,请询问提交者 5.4.4.1. SQL注入攻击、敏感数据泄露和跨站脚本攻击的漏洞

    2024年02月05日
    浏览(50)
  • 读程序员的README笔记07_测试(下)

    2.5.2.1. 首先应该关注代码中的高风险的区域 2.5.2.2. 那些低风险或被废弃的代码并不值得测试 3.2.1.1. 如果网络出现问题,那么测试也会失败 3.5.2.1. 使用常数种子的随机数生成器的测试将总是通过或总是失败 3.7.3.1. 注入式时间戳将让你使用模拟来精确控制测试中的时间流逝

    2024年02月05日
    浏览(47)
  • 读程序员的README笔记08_依赖管理

    2.6.1.1. 版本不应该被重复使用 2.6.1.2. 永远不要在现有版本下重新发布更改的代码 2.6.2.1. 版本应该帮助人们和工具对版本的优先顺序进行推断 2.6.3.1. 版本信息区分了预先发布的代码和已发布的代码,将构建流水号与构件相关联,并设置了稳定性和兼容性的合理预期 6.2.5.1

    2024年02月05日
    浏览(48)
  • 读程序员的README笔记11_软件交付(下)

    1.3.5.1. 通过持续交付,人力被完全从部署环节中移除 1.3.5.2. 打包、测试、发布、部署,甚至展开环节都是自动化的 1.3.6.1. Puppet、Salt、Ansible和Terraform等现成的解决方案可以与现有的工具集成,并且它们是专门为了自动化部署而设计的 1.4.4.1. 只需再次指向旧的版本 1.5.1.1. 

    2024年02月04日
    浏览(59)
  • 读程序员的README笔记04_防御式编程

    1.2.1.1. 切记让你的代码安全而有弹性 1.2.1.2. 编写拥有良好防御性的代码是一种对那些运行你的代码的人(包括你自己!)富有同情心的表现 1.2.1.3. 防御性的代码较少发生故障,就算它发生故障,也更有可能恢复 1.2.1.4. 安全的代码利用编译时的校验来避免运行时的故障,使

    2024年02月05日
    浏览(56)
  • 读程序员的README笔记10_软件交付(上)

    3.1.1.1. 打包一个构件称为发布 3.1.3.1. 部署的软件还不能被用户访问 3.1.3.1.1. 只是被安装了而已 3.1.3.2. 一旦部署,软件就会通过将用户转移到新的软件上而进行展开 3.1.4.1. 交付过程是更大的产品开发周期中的一部分 6.10.2.1. 每季度或每年发布一次

    2024年02月04日
    浏览(156)
  • 读程序员的README笔记01_学习如何学习

    6.3.2.1. 错误是不可避免的。成为一名软件工程师的路途艰辛,我们有时会失败 6.5.4.1. 代码从不说谎。注释有时却会。 6.5.4.1.1. Code never lies. Comments sometimes do 6.5.4.1.2. 去读源代码,因为它并不总是与设计文档相吻合 6.5.4.1.3. 不要只读你自己的代码库,还要去阅读高质量的开

    2024年02月05日
    浏览(51)
  • 读程序员的README笔记18_职业生涯规划

    3.1.5.1. 他们的工作职责之一是管理他们的团队,而管理的一部分就是对你投入时间 3.1.5.2. 对管理者而言,反复取消一对一面谈可以是一个有价值的信号 3.3.2.1. 每个目标都附有3到5个关键结果,它们是标志着目标达成的具体指标 3.3.2.2. 不要把关键结果变成待办事项清单 3.

    2024年02月04日
    浏览(50)
  • 读程序员的README笔记05_日志、监控与配置

    6.1.1.1. 测量的是某个事件发生的次数 6.1.1.2. 通过使用计数器获得缓存命中数和请求总数,你就可以计算出缓存命中率 6.1.2.1. 一个基于时间点的测量值 6.1.2.2. 既可以上升又可以下降 6.1.3.1. 根据事件的大小幅度分成不同的范围 6.1.3.2. 每一个范围都会有一个计数器,每当某

    2024年02月05日
    浏览(51)
  • 读程序员的README笔记12_On-Call

    4.4.2.1. 回应不一定代表解决方案 4.4.3.1. 每次更新时,提供一个新的时间预估 4.5.3.1. 如果请求者没有回应,就说你将在24小时内因缺乏回应而关闭该任务票,然后真的这样做 5.3.1.1. 工程师必须找到问题,确定其严重性,并确定谁能修复它 5.3.1.2. 确认问题并了解其影响,以

    2024年02月04日
    浏览(41)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包