Developer Experience

《Developer Exception Engineering》

SWYX 认为社区在过去讨论 Developer Experience 的角度稍稍狭隘了。

• 能效提升：提高代码效率、自动化、代码生成器、开箱即用...
• 富文档：起步文档、代码示例、可交互示例、API清单、最佳实践、可搜索...
• 开发者工具：脚手架、编辑器插件、代码片段、代码展示、版本控制...

这些东西对开发者来说时“友好的”，但是也很“简单”。也许是时候主动跳出站在开发者的角度思考 DX 的舒适区，开始转向终端用户。也许可以尝试保证这些东西：

• 服务可用：产品数据页面和报错页面会说谎吗？...
• 反馈有效：是否及时有效的解决了客户反馈？...
• 功能完整：是否发布了不完整甚至需要返工的功能？...
• 产品路线完整：对产品路线的规划是否清晰合理？...
• 计价合理：用户会对你的报价产生疑惑么，它是否是可计算和比较的？...
• 兼容性：废弃的API是否合理？...
• 报错优雅：出错后是否可调试？...
• 访问控制：客户有审计日志或访问控制的权力吗？...

正如面对漏水的桶下雨解决不了问题，如果只是一直站在开发者的角度思考 DX，对解决品牌满意度下降、客户流失这些“异常”没有办法带来帮助。此外，根据康威定律，一个不合理的 DX 会反映出公司的组织架构的不合理之处，这值得引起注意。