远程访问是我日常开发工作流的一部分。典型的一天可能包括通过 SSH 连接到 Linux 服务器，使用 RDP 访问 Windows 机器，通过 VNC 检查远程桌面，以及偶尔处理仅暴露 Telnet 或串行接口的网络设备。
当所有这些协议成为同一工作流的一部分时，挑战就出现了。macOS 是一个出色的开发环境，但管理许多不同的远程工具很快就会变得碎片化。
多种远程协议带来的日常摩擦
大多数开发者从特定协议的工具开始。
对于 SSH，macOS 已经包含了 OpenSSH：
ssh 用户@服务器
它可靠且功能强大，但完全基于命令行。对于管理许多服务器的开发者来说，记住连接细节并在终端之间切换可能会变得不便。
对于 Windows 机器，远程桌面需要 RDP 客户端。VNC 需要另一个应用程序。网络设备可能需要 Telnet 支持。硬件调试可能涉及通过 USB 适配器进行的串行连接。
典型的设置很容易变成：
- 一个用于 SSH 服务器的应用程序
- 一个用于 Windows 远程桌面的应用程序
- 一个用于 VNC 会话的应用程序
- 一个用于串行调试的应用程序
- 另一个用于文件传输的工具
每个应用程序单独运行都良好，但整体工作流变得更难维护。
统一的远程管理方法
另一种方法是围绕设备而不是协议来组织远程连接。
这个想法很简单：开发者思考的是“我需要管理的服务器”，而不是“我应该先打开哪个协议应用程序”。
统一的远程管理工具可以将不同类型的连接集中在一个地方：
- 用于 Linux 服务器的 SSH
- 用于 Windows 桌面的 RDP
- 用于图形远程会话的 VNC
- 用于网络设备的 Telnet
- 用于硬件调试的串行连接
- 用于远程资源的文件传输功能
这减少了上下文切换，使远程环境更易于组织。
构建多协议客户端的经验教训
在开发 DartShell 时，我注意到支持多种协议只是工程挑战的一部分。
更大的挑战是在非常不同的系统之间创建一致的体验。
SSH 用户关心终端性能和身份验证方法。RDP 用户关心显示质量和输入响应速度。串行用户关心稳定性和设备兼容性。
良好的远程管理工作流需要在隐藏不必要复杂性的同时，在开发者需要时提供高级控制。
一些重要的设计考虑因素包括：
- 保持连接配置有序
- 使环境之间的切换快速
- 支持不同的身份验证方法
- 提供一致的文件管理
- 避免工具之间不必要的重复
选择合适的工作流
对于只管理一两台服务器的开发者来说，单独的协议工具可能就够了。
对于在许多环境中工作的开发者，尤其是那些使用 macOS 作为主要工作站的开发者，统一的远程访问工作流可以节省大量的脑力开销。
关键要点是，远程管理正成为一个与工作流相关的问题，而不仅仅是一个协议问题。你管理的系统越多，一致的连接体验就越有价值
免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。
