MAX定位为一个与政府深度集成的平台，但与此同时却未能向开发者提供基本的调试工具。在这样的条件下工作是可以的，但这总是需要借助临时的解决方案和耗费额外的时间。我向MAX团队提出：如果你希望有人为你的平台开发高质量的应用，就必须向开发者提供正常的工具。否则，我们最终得到的将不仅仅是一个强制性的、但又不便用的产品。
在俄罗斯目前正在积极推广 MAX 即时通讯软件作为 Telegram 的官方替代品。对用户来说这意味着又多了一个桌面客户端，而对开发者来说则又多了一个用于机器人和小应用程序的平台。
纸面上听起来很正常：统一平台，与政务服务集成，为企业提供小程序（你好，微信）。实际上会出现一个基本问题：如果没有正常的开发工具，如何开发并调试这个桌面客户端？
在这篇文章中，我将尝试解释看起来像什么 在 MAX 中调试小程序今天，它与 Telegram 中习惯的过程有何不同（是的，又是与无处不在的 Telegram 进行比较），以及为什么缺乏开发工具不是小问题，而是一个系统性问题。
我们通常如何在 Telegram 中调试小程序
如果你已经在 Telegram 中做过小程序，那么工作流程大致如下：
建立本地前沿，将其作为 Web 应用连接。
在 Telegram Desktop (Beta) 中启用实验性 webview 模式。
在微型应用中的上下文菜单中选择 检查或直接按 F12
熟悉的开发者工具打开：控制台、网络、源代码、性能、应用等。
在手机上可以通过 chrome://inspect/#devices 并获得类似的透明度水平.
这有什么好处:
可以看到真实的 initData /令牌以及客户端传递给webapp的格式.
直接在控制台中捕获错误，而不是通过日志.
查看对后端的实际请求、标题、响应代码。
分析性能、渲染、卡顿等
也就是说，小程序本质上是一个普通的网页应用，我们可以在熟悉的开发者工具中对其进行调试，只是它运行在Telegram的容器内。
MAX中的小程序开发看起来是怎样的
从前端角度来看，MAX中的小程序是一个非常相似的存在：
同样的HTML/JS前端
自己的用于与客户交流的 bridge.
自己的初始化方案.
自己的 UI Kit（一个单独的
bugurt话题）
相似之处就此结束，这似乎很合理，毕竟这是另一款产品.
在桌面版 MAX 中：
没有描述用于内置 webview 的 DevTools 启用模式。
没有单独的选项 检查 在界面中.
没有公开的说明如何调试客户端中的小程序.
结果我们有一个小程序，它运行在原生客户端内部，但无法查看网页部分实际发生的情况。这就像不打开引擎盖就修理发动机.
缺乏DevTools会导致什么
问题一旦尝试做比"Hello World"更复杂的事就会变得明显：
不透明的初始化: 如果初始化数据没有 我 在格式中，不 到底来不来 忽然改变 — 你会知道关于 在这个只能通过日志记录 服务器一侧或 思 借助条件 console.log 猜测和 前端。
抓住这个 地方，在 DevTools，不可能 — 这些工具根本就没有。调试错误变成了猜谜游戏： 任何奇怪的bug都需要通过逐一排查来复现：
我们尝试在网页版上复现。
添加临时日志。
发布新版本。
等待用户再次遇到bug并发送截图。
这已经不再是调试，而是巫术。 无法看到客户端在做什么 通过bridge的任何集成都是黑箱：
哪些事件真正到达？
客户端执行什么调用顺序？
导航/关闭/折叠时发生什么？
没有devtools你就看不到这些，只能根据间接迹象猜测。
习惯的开发流程因此中断 如果你在 Telegram 上开发，你习惯于：
同样的代码在浏览器、移动 Telegram 和桌面版中运行。
在任何情况下都可以打开 DevTools（直接打开或通过 attach）。
在 MAX 中，你不得不区分：
真实环境 — 桌面版客户端没有 DevTools。
调试环境 - 浏览器中的 DevTools web 版本.
并且希望它们表现一致.
辅助工具：如何在 MAX 中调试小程序.
目前没有合适的工具，我们就做我们最擅长的事：想辅助工具.
典型场景：
通过 web 版本调试： 通过 MAX 的网页版在浏览器中打开迷你应用。那里已经可以访问浏览器的常规 DevTools：
可以看到 network / console / storage。
检查基本逻辑、布局和状态。
至少调试常见的错误。
问题在于网页版和桌面客户端可能在以下方面有所不同：
User-Agent 和浏览器功能。
安全策略、标题、小玩具.
与原生客户端功能集成.
记录日志而非常规调试:
到处插入 console.log .
在后台日志中重复关键事件.
在某些情况下，我们会将诊断信息发送到自己的端点，以便尽可能了解用户发生了什么。
在某些情况下，我们会连接Sentry（或类似工具）并将前端错误和堆栈跟踪发送到那里，因为无法直接在客户端查看它们。
这虽然有效，但：
会增加日志噪音。
会增加支持成本。
使得能够充分利用 DevTools的“开箱即用”功能.
拉取第三方遥测数据.
在生产环境通过假设进行调试:
基于猜测插入一个修复.
等待，投诉数量是否减少.
希望没有在过程中破坏其他东西.
为什么这不是开发者的任性
对外部问题，人们很容易说：“没什么，DevTools” — 那又怎样？以前不也过得下去». 问题在于 那么：
小程序不是玩具。通过它们可以：
支付。
服务预约。
处理个人数据。
错误由于无法正常调试UI或 授权 — 这是金钱、时间、精力和风险。 用户。
平台不仅通过用户体验竞争，而且通过DX，而 DX 是指 定义：
做工作原型需要多少时间。
支持有多痛。
独立开发者会想和平台联系吗。
在Telegram DX已经相当不错：文档、示例、开发工具。
在 MAX 目前可以实现：做是可以的，但是 通过痛苦和拐杖».这会影响生态系统的最终质量 如果平台从上方强推，但对开发者不方便，就会发生经典情况：
做"仅仅" 能工作».
不投资于用户体验。
他们尽量减少任何改动——只要别碰就好。
结果用户受苦——得到那些虽然存在但使用起来不愉快的所谓 MAX 服务。
平台方面可以做什么
问题可解决。无需发明任何根本性新事物……只需采用已验证的方法：
在桌面客户端添加webview检查模式。 最小必要版本：
在设置（或通过隐藏标志）中启用开发者工具模式。
在迷你应用中右键点击会出现选项 检查。
按下F12会打开与特定webview绑定的开发者工具.
这个模式可以限制：
仅限dev版本或beta频道.
仅限开发者模式已开启的账号.
仅限本地或测试环境.
描述官方调试场景. 例如：
快速入门：如何通过网页版调试小程序。
进阶：如何连接桌面客户端的webview。
日志记录和诊断建议。
这能立即解决部分问题并减轻支持压力。
收集开发者反馈并优化开发体验。 开发者工具 — 其中之一。 最便宜同时也最强大的改善开发者体验并减少bug的方法是 这个主题在 社区中。
如果平台想要一个活跃的生态系统，而 不 只有“强制”实施 需求，没有 这没什么大不了的。
我为什么要写这个
本文的目的不是单纯抱怨，而是：
记录当前 MAX 的调试现状。
表明问题不在于懒惰的开发者，而在于缺乏基础工具。
提出最小化的改动方案，该方案：
不会破坏安全性。
不会需要巨大的努力。
但显著提升了DX和平台应用质量.
如果你也在为 MAX开发小程序并遇到 类似的问题 — 请分享你的解决方案和案例。具体案例越多，就越难假装 问题不存在.
P.S. 如果阅读后 您还有这种感觉， 这只是开发者的任性 — 尝试一周不使用 调试工具 在自己的喜欢的栈上。也许几天后你也会写一篇文章。