开发者也是用户!
在构建系统时把开发者作为第一用户,不仅可以让开发顺利进行,提升开发者的开发体验,还能及时发现设计中的问题,少走弯路。


产品要服务于所有用户

在设计和构造系统时,我们很容易忘记最终发布的产品需要满足五花八门的用户需求。

以常见的系统设计面试为例,大部分用户都喜欢使用网址(URL)缩短器,于是不少人就想当然地以为,使用 URL 缩短器和需要把缩短的 URL 变回完整 URL 的用户是同一批用户。

但事实并非如此,我们面对的用户可能是:

  • 广告商
  • 网络可靠性工程师
  • 付费客户
  • 客户支持人员
  • 销 售

即使把用户范围考虑得再周全,也很容易忘记开发者自己也是用户。


以开发者为用户来设计产品

开发者与 URL 缩短器的日常交互是:

  • 编写和阅读代码
  • 在发布前进行测试和验证
  • 与同事和相关人员就具体项目进行沟通
  • 修复故障、增加新功能

当然,这些交互是由外部工具(编辑器、源码控制系统、代码审查平台和敏捷工作流程)提供的,开发者通过编写代码来使用和增强这些工具。

在进行系统设计时,我喜欢先列出用户想要的互动,尽量不考虑技术因素,只了解用户的个人需求。

开发者用户可能会有下列需求:

  • 作为开发者,我想知道上一个 beta 版本中开发的组件发生了多少错误,然后将这些错误与我的拉动请求关联起来。
  • 作为开发者,我希望能对我的软件进行负载测试并分享结果。
  • 作为开发者,我想与其他用户分享我当前使用的工作版本,并收集其他用户的反馈意见。
  • 作为开发者,我希望能收到用户反馈的功能故障报告。
  • 作为开发者,我希望能启动处于生产环境的本地副本,回放导致错误的事件序列。

如果我们用产品思维来处理这些互动,就能产生协同效应。

传统的用户体验设计方法比如用户故事、线框图、故事板、领域建模和原型等效果都很好。

以开发者为用户来进行设计有很多优势。我们可以使用复杂的软件,比如命令行工具、Python 笔记本和 excel 导出,这些对开发者来说都很简单,而且重点是开发者可以根据他们的的想法进行设计。


命令行工具是核心

对于以开发者为中心的产品设计,命令行工具是核心。我喜欢命令行工具,这些工具可以让开发人员从开发和生产系统中快速获取有价值的信息。

在过去的七周里,出现这种情况的频率是多少?发送给 beta 版客户的每个版本中分别缩短了多少个 URL?你能快速部署一个分支并分享其 URL 以进行测试吗?

命令行工具通常只是实际代码库前面的一个小层,命令行工具的设计对代码架构有深刻影响。

  • 能够快速收集与特定 git 修订版和特定源码组件对应的错误日志,我们需要做适当的结构化记录。
  • 与其他用户分享并行工作数,我们需要建立和拆除暂存环境的快速方法。

用命令行工具取代人工流程的优点在于,可以对它们进行编排。只要开始遵循某些准则,流程就更易编排。

  • 数据以结构化格式(CSV、JSON、YAML...)输出。
  • 数据以不可变的形式存储在云中,通过 id(或基本的分析 hygiene)来引用。因为数据不变且稳定,所以可以跨机器复制报告,确保其他用户可以查看和复制。

命令行工具还提供进入代码库的“索引”。不仅可以让用户通过传递 -help 标志了解可以做什么,还能让开发者了解存在哪些 API 以及如何使用,因为脚本只是代码库的表象。


具体实例:生成负载测试报告

假设我们正在研究下列故事:

“安娜是一名开发人员,她想创建一个与两周前的生产相匹配的暂存环境,并模拟“ 黑色星期五”的流量对其进行综合测试负载。”

我们要大概描述下这个脚本在 shell 脚本中的样子(不是安娜如何把这个脚本及其附带的 black-friday.yaml 交给她的同事鲍勃,然后鲍勃运行负载测试版本,得到不可变的报告数据):

RELEASE=$(./tool query -version -date='2 weeks ago' -target production)
DEPLOY_ID=$(./tool deploy -staging -version=${RELEASE})
TEST_ID=$(./tool load-test -target ${DEPLOY_ID} -template black-friday.yaml)
REPORT_ID=$(./tool generate-report -type load-test -from ${TEST_ID})
REPORT_URL=$(./tool get-report-url ${REPORT_ID})
echo "Load test report for ${RELEASE}: ${REPORT_URL}"

这样操作可以相对直接地实现必要功能。

大家可能会觉得这对于那些 shell 脚本都可能被攻击的系统来说不易操作,其实这对于不能快速创建暂时环境的系统来说都不简单。但是一旦操作成功,在项目的整个生命周期内,你都能从中获益。所以,快来尝试吧!



原文作者:the scapegoat dev
原文链接:https://the.scapegoat.dev/you-the-developer-are-a-user-too/

推荐阅读
相关专栏
开发者实践
182 文章
本专栏仅用于分享音视频相关的技术文章,与其他开发者和声网 研发团队交流、分享行业前沿技术、资讯。发帖前,请参考「社区发帖指南」,方便您更好的展示所发表的文章和内容。