在与 Zed 的三位联合创始人 Nathan、Max 和 Antonio 的第三次对话中（阅读之前的对话），我想问问他们对协作的看法。 软件团队中的协作，特别是 Zed 提供的协作模式——现在和将来。 理想的协作模式是什么？ 你如何看待异步与同步工作？ 如果我们遵循 Zed 对协作的愿景，最终我们还会拥有 git、commits 和 pull requests 吗？
这次对话比之前的两次要温和得多。 不仅因为对于我和 Antonio 来说，现在已经是欧洲的深夜了，而且我认为，因为我们谈论的内容——人们如何一起工作，以及我们希望如何一起工作——是抽象的、个人的，甚至可能比我们进行的技术对话更加微妙。 但即使这次对话可能更温和，但这仍然是一次非常有趣的对话，自从上周我们录制以来，我每天都在回想它。
以下是长达一小时的对话的编辑后的记录。 我尽力保留了意图和含义，同时去掉了嗯、喜欢、你知道、停顿和方向修正，这些构成了深入的对话。
（您可以在我们的 YouTube 频道上观看完整的对话。）
Thorsten：协作是 Zed 愿景的重要组成部分。 你们从头开始构建它，想法是在 Zed 中拥有 CRDT 和协作文本编辑。 所以我的问题是：我们今天拥有的工具缺少什么，使得你们想要改进协作？
Max：我想到的问题是，我一直设想的一种工作流程，它比我们今天拥有的更流畅：pull requests、Slack 和屏幕共享——当今协作工具的三驾马车。
为了举例说明：我想在咖啡店里，独自编写代码，专注于某些事情，然后意识到我需要你的帮助。 我不确定你现在是否在，而且我不想离开我的编辑器，我想留下一个评论，大致解释我对 Thorsten 你有什么问题。 “你能解释一下这里的代码吗？” 我不必去 GitHub 上找到与该代码对应的 git blob。 没有那种跳转。 然后我可以继续我正在做的事情。 然后，如果你在，比如说你同时在咖啡店里，你想用文字回复，你可以直接跳进来，说，“哦，我们改变了这个 API。 现在你需要这样做。” 你和我一起编写代码一秒钟，你把这些输入到聊天中。 这是一件轻量级的事情。
然后我意识到，“等等，我对这个问题有更深入的疑问。 我需要和你谈谈。” 我说，“嘿，你能谈谈吗？” 然后，嘟嘟，你就在我的编辑器里，我们在聊天，我们在结对编程。 你会说“好的，我们在这里改变这个，这里是这个，这就是为什么这里是这个。” 我带你参观一下，我们进行一些密集的协作，然后我们分道扬镳。
显然，你没有看着我的屏幕。 这对你和我来说都是一种流畅的体验。 然后在未来，有人来了，看到了这个变化，说，“嗯，这段代码发生了什么事？” 他们看到 Max 和 Thorsten 在这里有过对话。 他们可以大致看到文本互动，追溯到他们进行对话时代码的样子。
这就是我想要的。 我觉得我们现在已经构建了其中一个非常重要的部分，但缺少异步的部分。
Thorsten：我可以说，你提到的 Slack、Zoom、GitHub 等都可以实现所有这些。 但你提到的流畅性似乎很重要，你不必去 GitHub 留言并查看你的电子邮件回复。 相反，你仍然在你的代码中。 所有这些都在一件事情中。
Max：是的，让我们倒带一下这个故事，谈谈今天可能但痛苦的事情。 今天，在我意识到我对你有个问题的那一刻，我想，好吧，我如何链接到这段代码，以便能够引用它并与 Thorsten 谈论它？ 我现在就在代码中。 我的分支已经改变了。 我有一些没有推送的东西。 我需要做出决定。 要么我推送一个正在进行中的提交，以便 GitHub 上有一些我可以链接给你的东西，要么我倒带并找到该代码存在于另一个分支上的位置，并使用 GitHub 的代码浏览界面来找到该代码并链接到它。 然后我切换到 Slack 并说，这是链接。
所以也许到那时我已经决定了：算了，我不打算这么做。 在我决定甚至值得这么做之前，我会稍微忍受一下这种痛苦。
所以这是一个时刻，非常非常开始。 然后，假设你刚刚收到了我的消息，说我需要帮助。 今天，你将会收到一个 GitHub 的链接。 同样，它可能是一个指向一些代码的链接，这些代码与我正在处理的代码并不完全相同，只是因为我没有办法告诉你我正在处理的代码是什么。 所以你会有这种摩擦，“好的，我在我的代码编辑器中。 我很可能正在处理同一个项目。 但我将跳转到 GitHub 上查看这段代码，因为这是你发给我的链接。 我必须使用 GitHub 的代码导航或 Sourcegraph 的代码导航或其他代码编辑器来查看这段代码。 所以也许在那个时候，你会说：“我不会太深入地调查我给出的答案，因为这样做很痛苦。” 这是第二个时刻。
而最大的是，如果我决定，“好吧，这种来回的文字有点效率低下，我想现在和你谈谈。” 今天，使用 Zed 之前的工具，你通常会使用类似 Slack huddle 的东西。 Slack huddle 很好，但代码部分，共享你的屏幕，那是最重要的部分。 你现在正在看我的屏幕，你感觉，“哦，我怎样才能摆脱这个屏幕共享？ 我必须看这个像素化的屏幕，这不是我的主题。 我什么也做不了。 让我们结束它吧。” 所以也许在那个时候，你会反弹。 不值得这样做。
最后，那些想要在以后了解这次对话的人，因为他们遇到了相同的代码。 我想说，这可能是最糟糕的部分。 假设 Antonio 稍后查看这段代码，遇到了我发现的一些类似问题。 我的意思是，如果是今天的我，我会做的是，对文件进行 git blame，但对话不在 git 中，而是在 GitHub 上。 从 git blame 中获取 SHA，将其粘贴到 Web 浏览器中，看看这是否是 pull request 的一部分？ 这里的对话在哪里？ 也许我可以找到，转到 pull request，但没有对话。 哦，这里引用了另一个问题。
现实情况是，我可能放弃了，我决定自己推理，因为不值得找到它。 或者我在 Slack 中搜索关键字。 但两者都很痛苦。 所以对我来说，所有这些时刻你都可以用今天的工具交换信息，但有很多地方不值得今天这么做。 为了值得这么做，问题必须有多么困难才能行。
我认为我们想做的是让它始终值得这么做，通过拥有不会阻碍你的工具。
Thorsten：谁想在这里补充一些内容？ 因为我有很多后续问题，但我也想听听其他人的意见。
Nathan：对我来说，一个共享环境是我想要的地方。 一个包含代码开发过程的完整生命周期的共享环境。 所以使用 git，你有一种共享环境。 环境是存储库环境。 但我认为 commit 的粒度确实扭曲了我们围绕代码进行沟通的行为。
什么是 commit？ Commit 是一个静态的时间点快照。 而现在，你真正能谈论的只有 commit。 但如果你只能谈论某个时间点的快照，那么随着时间的推移，对话的相关性就会流失，对吧？ 因为你谈论的是过时的代码块。
这意味着我们倾向于只谈论新代码，但实际上应该有很多代码值得进行对话。 只是链接到它们真的让人头疼。 我可以推送一个“WIP” commit 并链接到该快照并进行对话。 但是，同样，随着时间的推移，对话的相关性将会流失，因为它锚定在旧代码上。
因此，能够将对话向前推进，实际上将对话链接到一段代码，而不是一段代码的快照，实际上将锚点放到一个字符上，并且只要该字符存在，就能够将其随身携带并看到有与其相关的对话——这对我来说是一个很大的缺失。
Antonio：最重要的是，我觉得每个人都有过这样的经历，我不知道…… 我经历了很多次，我会处理一些事情，创建一个分支，推送一个 PR，典型的流程是你请求审查，通常，PR 越长，审查就越糟糕。 PR 越长，你越有可能收到“看起来不错，发布吧”，而不是越小，人们就越有可能吹毛求疵。
而现在 PR 的问题，我真正不喜欢的是，如果你很厉害，你就会非常擅长编写提交信息，对吧？你会非常完美地描述它们，并且最终在 PR 描述中写一个总结，对吧？但是那个总结仅仅是你对事情经过的回忆。但是从你写下第一个提交到你写下那个总结之间，可能已经过去了一个星期。所以这是一个问题。
另一个问题是，你在看一个 diff，但是当你阅读那个 diff 时，它是按字母顺序排列的。这不是我会向另一个人展示我的 diff 的方式。我会告诉他们，嘿，你知道，这些是重要的部分，然后...
Nathan：向他们展示一个叙述，而不仅仅是一个 diff。
Antonio：你知道，Max 描述的那些互动，它们确实在你编写代码时发生过，因为也许你确实有过屏幕共享会话，或者你和你的同事交谈过，对吧？能够捕捉到那些对话并让它们与代码一起存在——这些对话和代码一样重要。
这几乎就像代码是那些对话的产物。它是那些知识的产物。而现在这两件事是脱节的，它们分散在几个数据库中——GitHub、Slack、人们的头脑中。
能够统一它们并捕捉所有这些知识似乎——好吧，当我们谈论协作以及 Zed 能做什么时，我对此感到非常兴奋。
Nathan：有很多关于代码的对话并没有发生，我认为如果我们有更好的工具支持，这些对话就会发生。总的来说，我发现 Pull Request 的氛围有点像对抗性的对话。就像你试图让它通过审查，人们设置这些障碍让你清除和解决。而且确实有它的位置，特别是如果你们已经达成共识，并且主要是一些调整或其他什么。
但如果比这更深入，我更喜欢一种更具协作性的动态，我们只是在一起工作。我的意思是，Zed 现在做得很好。还有改进的空间，但它正在从那种对抗性的动态转变为协作性的，真正协作性的。
Thorsten：听起来你们都认同某些关于协作的价值观。你认为理想的协作是，我们都坐在办公室里彼此相邻，而不是发送消息，而是直接指着屏幕，然后说，“嘿，Nathan，过来看看这个。”你认为这将是理想的情况，而我们正在讨论的问题仅仅是由于远程工作造成的吗？或者你认为，例如，在办公室里五个人围着一个屏幕进行 Mob 编程，并且所有内容都直接提交到主干，那也不是理想的？
Nathan：不，我不认为所有内容都直接提交到主干的 Mob 编程是合理的。对我来说，能够拥有独立的同步开发流似乎是合理的。但我要说的是，我在 Pivotal 花了很多时间在办公室里进行结对编程。我更喜欢拥有自己的屏幕、自己的键盘和自己的显示器，但坐在旁边的人自己的屏幕旁边。因为那样我可以独立地导航。我们不必争夺键盘。
因此，我认为，在本地环境中，我们可以真正地看着对方，看着别人的肩膀，并在共享环境中讨论代码，这并不是那么重要。但在远程环境中，我们需要一个共享环境。而现在，我们的共享环境是 GitHub，它有这些限制，你必须拍摄快照并将其推送上去，并且共享该特定环境涉及很多摩擦。
或者还有其他像 Slack 这样的工具，它们不是为代码设计的。或者各种形式的屏幕共享，它也不是为代码设计的，所以它是像素化的，并且只有一个人可以操作。
所以在远程环境下，我不知道人们是如何在远程团队中生存的。我的意思是，我确信它确实发生了，但我只是觉得，因为我们实际上能够——不是 100% 的时间，但至少在某些时候——一起工作，所以我们作为一个团队的运作更好。
Thorsten：回到 Max 刚才说的话，他在咖啡馆里，你会给我发消息并等待回复。如果我们坐在办公室里彼此相邻，你不会在有问题时直接拍我的肩膀，你仍然会注意不要打断别人，对吧？
Max：如果我必须在坐在办公室里某人旁边或仅在 pull request 中进行异步交互之间做出二元选择，我会选择前者。但我认为我们正在构建的东西比两者都更好。
仍然有这种能够专注于自己的时间，只异步地与其他人打交道，但随后你可以在需要时跳入同步交互。
Thorsten：我听到的是你重视协作。对你来说，协作不仅仅是“我需要别人在 pull request 上给我打个勾，然后我就把它提交出去”。你想要与其他人一起工作。你想要一起工作，你认为作为一个团队与他人合作很重要，并且你认为软件的历史很重要，它是如何发展到今天的。这来自哪里？是你在大型公司工作的背景吗？是你在小型公司工作的背景吗？还是开源并与众多贡献者合作？还是你们三个人一起工作了 10 年，看到了它的效果？
Antonio：对我来说，与其他人一起编写代码更有趣。我在智力上更受刺激。当然，我对我们正在构建的产品感到兴奋，但我与其他人一起构建它会获得同样的快乐。这是我在编写代码时获得乐趣的一部分。而且我也认为这会导致更好的代码。
我通过与他人一起编写代码结交了朋友。在我工作过的每一家公司。这两个人[Max & Nathan]显然是一个很好的例子，但在其他公司也是如此，与所有我结对编程和一起工作的人，我建立了关系。
我认为这作为人类非常重要。这就是我真正兴奋的事情。与其他人一起工作，与他们成为朋友，并一起构建你能构建的最好的东西。
Nathan：如果你们有一个团队，你迟早要和这些人交谈。这只是一个时间和方式的问题。因为是的，你可以独自一人去编写大量的软件，但如果你有一个团队，大概你拥有一个团队的原因是因为要编写的软件比一个人自己可以编写的更多。所以这意味着总体的软件将是多人编写的软件的组成，很抱歉，但你将要进行沟通。所以现在的问题是如何沟通。对我来说，GitHub 协作模式一直感觉像发送电子邮件。它是异步的流程。这适用于某些问题。但是其中的一些，我不知道，比如我们今天早上正在解决的关于绘制顺序的问题，就像...我不会以电子邮件的速度与他人讨论它。我要么独自一人坐着思考，要么我在一个能够围绕它进行更细粒度沟通的工具中。
Thorsten：所以如果我们完全按照你的愿景，今天工具链中还剩下什么？我们还有 pull request 吗？我们还有 Git 吗？我们还有 Git 提交、分支吗？
Nathan：我的意思是，从长远来看，让协作比使用 Git 更方便会很好。
我的意思是，我认为我们会有分支。因为同样，分支是一种促进异步工作的工具，这仍然是一种重要的工作方式。你必须能够，即使是两组人在同步地处理两个独立的事情，但相对于彼此是异步的。这是一种根本上重要的工作方式。
但我认为，当 GitHub 出现时，异步是一种革命，因为在那之前，在 SVN 上进行分支是一件痛苦的事情。所以我仍然认为分支将会存在，异步工作流程将会存在。我只是认为它将是你可以用来编写代码的潜在交互方式的一个点。而你选择该点，不是因为它只是唯一可用的工具，而是因为它对于你所处的情况来说是最有意义的方法。
Thorsten：那么这种开发方法在多大程度上是一种文化的东西，又有多少是真正的工具？为了解释我提出这个问题的缘由，看看过去 15 年的 DevOps：有些人说，“哦，一旦我们有了云，并且有了不可变的基础设施，那就是 DevOps 发光发热的时候。” 而另一些人则说，“这是一种心态。这是一种你如何思考开发以及如何让其他团队参与的方式。” 你们三个人对协作有着共同的理解。你认为如果我们构建了支持它的工具，其他人也会接受它吗？或者你认为这也是一种文化的东西，其他人也必须拥抱这种团队构建软件的方式？
Nathan：我一直希望通过大幅减少以这种方式进行沟通的摩擦，我们可以让人们在文化上朝着这个方向发展方面获得成功。
我们都受益于在 Pivotal 进行结对编程，Max 和我，这只是当时的工作方式。每个工作站都设置为结对编程。整个世界都围绕着你将要进行结对编程的假设而设计的。我们学会了与他人实时合作有多么酷。我不知道如果我没有那段经历，我是否能够克服屏幕共享或我们在构建 Zed 之前所做的任何事情的麻烦。
Antonio：我的意思是，我没有在 Pivotal 获得那种经历，对吧？在加入 Atom 之前，我没有和任何人结对编程，对吧？我认为我真正深入结对编程的第一个人是 Nathan。我的意思是，我记得那些最初的会话，我就像是，哦我的天，这太激烈了。现在仍然如此。以一种好的方式。所以，我想 Nathan 和 Max 将我暴露于那种文化，你可以这么说，但我认为对我来说，从第一天起就很有感觉了。它在技术层面上对我来说很激烈，但在情感或人际关系层面上却从未激烈过。从第一天起它就更有趣了。我不是在独自完成这件事。我在与他人一起完成它。
我觉得... — Thorsten，我们已经结对编程了，在过去的，嗯，你加入多久了？
Thorsten：五、五、六、五个星期，我想。
Antonio：我觉得如果我没有每天和你结对编程，我就永远无法在远程情况下与你建立关系。它根本不在同一水平上。
所以，是的，这里涉及一些文化，但与此同时，这并不意味着人们没有进行对话。人们确实会使用工具来进行这些对话。所以我认为这里存在需求。我认为，是的，拥有一个工具可以让你进行更多的对话，或者只是简化你已经拥有的对话。是的，我们会做得很好。
Max：是的，我认为结对编程有一种含义。人们认为它有点小众或之类的。它与所有这些事情有关，连接到计算机的两个键盘，与它相关的工具，因为有人想输入，你必须停止输入，因为输入将进入同一设备。
人们会说，“我不希望有人在我编写代码时盯着我。” 我认为这是我听到的。但是就像 Antonio 刚才说的，除非你只是在处理非常简单的问题，否则你必须与某人进行一些对话。你必须有一个可以交谈的团队。所以这只是一个时间和方式的问题。
我认为，一旦我们采用了这种[Zed的协作方式]，可能就不再需要那么多“配对”这个术语了。 这只是一种非常自然的合作方式。 它不像双键盘那样，也不像两个人共同完成一项工作那样，也避免了人们在谈论配对时所说的效率低下的问题。
因为我们实际上可以同时修复同一个缓冲区中的编译错误。 所以我认为我们可能不再需要“配对”这个概念了。 一旦我们完成了，我认为它就会像你在Slack中一起聊天一样自然——我们不会说我们正在“配对编写文档”。
这只是一种协作的方式：你可以实时协作，可以单独进行，可以在不同的缓冲区中，也可以在同一个缓冲区中。 这只是更短暂的状态，更多在共享环境中进行的协作方式。
Nathan：我想说一点，我们已经谈了很多关于配对或实时协作的内容，我认为这是有道理的，因为这是我们在Zed中构建的第一个东西。 这就是现在Zed所支持的。 但现实情况是，尤其是在我的角色中，我只是说很多话。 有时我只想——说起来好笑，我只想不跟任何人说话，保持安静，这就是我为什么对CRDB[在数据库中存储代码和CRDT的想法，更多信息请参考这里]和注释感到兴奋，这是一种基于文本的与人交互的方式，也是实时的，但我不需要说话，至少不需要马上说话，我可以就在我的代码中提问。
Max早期提出的事情，我仍然对此感到非常兴奋。 成为这个协作编辑器的创始人之一，有时我只想安静地听听音乐什么的，这听起来很讽刺。 但这是真的。 而且我认为这没什么不对。 但我也不想为了用文本简单地讨论代码而必须提交一个WIP commit。 所以这是我们的下一个阶段。
Thorsten：作为一名不提问者，我想插一句：我认为你说的关于它在一个光谱上的说法是最重要的，它不是非此即彼的，不是在办公室里坐在彼此旁边和邮件列表之间做出选择。 过去10分钟我一直在想，当我开始我的第一个软件工程师实习时，我做了很多配对。 那是我第一次做。 当我第一次听说配对时，我认为这太疯狂了，但后来我做了，你拥有的带宽和吞吐量以及共享的理解——如果你从未经历过或者从未构建过这样的软件，很难传达出来。 当我加入我的下一家公司时，我仍然是一名初级工程师，我经常被一位高级工程师拉着，他会让我坐在他旁边，然后他说，今天我们要编写SQL查询，你会喜欢的。 然后在那之后，这些年配对越来越少，但我始终知道这是一种可以使用的模式，比如“嘿，我们来打个电话，或者我们一起做这件事。接下来的三个小时，你和我来做这件事。” 所以我确实认为知道这个光谱的存在，它不是一个二元的东西，是一件非常强大的事情，而且你实际上可以每天和别人一起工作五个小时并进行协作。 嗯，我没有问题，对不起。 但这是否反映了你的想法，你想让从一种模式切换到另一种模式变得无缝？ 有时协作意味着异步，有时意味着同步，有时我想独自一人。 但它始终触手可及，没有摩擦。
Nathan：是的。 而做好这件事的唯一方法，也是我们想构建Zed的一个重要原因——不是唯一的原因，我想构建Zed的首要原因是只是想构建地球上最好的代码编辑器，就是这样——但至少在早期，另一个重要的理由是，我真的认为要进行软件协作，你必须把它放在你用来编写软件的工具中。 这是一种沉浸式的体验。 所以这是一个有争议的观点。 而且我知道，要真正推销这个观点，这个编辑器必须非常出色。 对吧？ 我不会为了协作而使用一些糟糕的编辑器。 它必须是我已经想使用的编辑器，因为它很棒。 但是，如果我可以直接将代码视为这种共享的产物，作为体验中固有的无缝组成部分，那我就成功了。
Thorsten：你为什么认为这是有争议的？
Nathan：嗯，这意味着为了将Zed用作协作工具，你需要在团队中“all in” Zed。 但我认为，我不知道，我认为这很好。 有些人只会以更单人玩家的模式使用Zed，或者他们可能会更有选择性地使用Zed，与正在使用它的团队其他成员一起使用，但也许整个团队都没有使用该编辑器，他们仍然使用传统的异步协作工具。
但我确实认为，例如，VS code 中存在的模式是，一个人采用了它，然后整个团队逐渐对其进行标准化。 但这是一件大事，这就是它有争议的原因。 我认为这种想法就像是苹果公司的方法，垂直整合。 我们将拥有整个体验。
Antonio：是的。 我完全可以想象未来会出现这样一种景象：这种协作体验被提供为……比如，Zed 不是唯一一个与之集成的东西。
就像 Nathan 所说的那样，构建编辑器的重要原因之一就是它是垂直整合的。 这意味着我们可以真正创造我们想要的用户体验。 比如我们不需要被 VS Code 或 Atom 中扩展程序的制作方式所限制。 我们曾经尝试过一次，对吧？ 在 Atom 中，我们尝试构建Teletype。 而 Teletype 作为一款插件，其最大的问题在于编辑器的核心数据结构不是协作式的。 所以我们有了这个扩展，它基本上复制了整个缓冲区。 它是缓冲区的并行版本，而且…… 你可以做很多事情，但你肯定可以感觉到其中的局限性。
所以构建编辑器的重要原因是不受这些限制，但我完全可以想象，我们构建的这种协作框架可以与其他编辑器交互。 只是不会是头等体验。
Nathan：或者也许可以，但我们想构建一流的体验，而做到这一点的唯一方法就是构建它。 但是，如果有人不想使用我们的 GPUI 界面来获得我们最终构建并最终标准化和推广的协作体验，那也没关系。 但要实现这一点还需要一段时间。
Thorsten：你认为为什么大多数软件世界仍然依赖于 pull request？ 在过去的几年里，人们一直在说，“我想要更好的代码审查，这不是它，让我们使用其他工具。” 然后人们尝试不同的东西，但它并没有真正流行起来。 那么你认为这是为什么？ 我们是否达到了局部最大值，或者是因为技术缺乏，或者是因为其他原因？
Nathan：我只是认为其他任何替代方案都不够好。 我们使用 pull request。 去看看 Zed 的仓库。 大量的 pull request，包括我们团队成员打开的那些。 现在，那里的许多提交可能有两个作者，但我们仍然使用它们。 因此，对于这种异步模式，让我们看看差异，留下一些评论，我的意思是，也许你可以稍微完善这种体验。
但现实是，GitHub 对该工作流程的呈现对大多数人来说已经足够好了，以至于不值得为了切换到一些不太熟悉的工具或代码没有托管在其中的工具等而增加额外的开销。
但 Zed 今天所能实现的，以及当我们完成我们正在努力实现的目标时所能实现的——我想我仍然在一个 Zed 频道中广播整个对话。
Thorsten：哈哈哈。
Antonio：哈哈哈
Nathan：好吧，让我离开。 是的。
我们试图完成的事情根本不可能用快照来完成，对吧？ 我们正在谈论更多以操作为中心的 CRDT，或者只是更细粒度的交互。 在我看来，这些替代的 pull request 审查工具或分支审查工具并没有真正从根本上改变范式。
Antonio：而且 pull request 有很多优点。 我认为 GitHub 上的快照展示效果很好，而且 PR 还附加了很多东西，对吧？ 有 CI，对吧？ 这也是其中很重要的一部分。
Nathan：我并不反对 pull request，我会继续使用它们，或者，你知道，最终如果我们决定将它引入 Zed，我将继续使用异步工作流程。 只是，我认为我们迫切需要同步的。
Thorsten：Nathan，你提到了整个软件开发生命周期，按照其常见的定义，通常包括部署、调试，甚至事件等等。 但到目前为止，我们只谈论了一起编写代码的实际过程。
Nathan：是的。 然后代码之后会发生什么？
Thorsten：是的。 在你的愿景中，你也会改变其他部分吗？ 我们如何调试生产软件，我们如何一起查看事件等等？
Nathan：是的，我的确有这个想法。虽然不多，但是Antonio和我深入研究 Zed 之前，曾经考虑过一个想法——GitHub 过去使用 Hubot，在 Slack 频道中进行运维。我想，如果有一个协作终端，一个共享终端，它是一个 shell 环境，你可以在里面聊天，是不是会更好？就像把聊天带到 shell，而不是把 shell 带到聊天。所以这是我非常想做的一件事，拥有这种协作的战情室/运维/共享终端类型的东西。
关于开发生命周期的其他部分，我还有另一个想法，就是让你的编辑器成为很多东西的指挥中心。但我还没有认真地思考过这个问题。我的意思是，我梦想着使用一些锚定功能，比如将代码几乎用作数据库。这样，当异常开始涌入时，你可以几乎将它们写入代码库，作为“在生产环境中发生了一个异常”，这是一种漂浮在一切之上的元层。然后在编辑器中显示出来。因此，真正开始使用代码库本身作为基础，所有关于生产环境中发生的事情、性能信息、抛出的异常等信息都可以被注释，然后呈现给开发人员，在那里你可以看到它。你打开一个文件，你会看到，不是在这个确切的代码版本中，而是在生产环境中，昨天，这里抛出了一个异常。这难道不有趣吗？所以更像是将它们整合在一起。
这当然不会在下周发布，但我真的很希望看到它。
Thorsten：最后一个问题，我之所以提出这个问题，是因为我改变了看法。所以，当我加入时，我说：“Nathan，我们什么时候在 Zed 中添加视频通话？我需要在 Zed 中进行视频通话。” 但现在我不确定我是否想要视频通话，因为当我不用担心我的外表或我的手和脸做什么时，很多事情都会改变。而且只用电话和别人交流真的很好。你认为这很重要吗？这是一种快乐的意外吗？因为你只是没有抽出时间来做视频通话，但现在它就是这样工作的。或者你认为我高估了音频通话相对于视频通话的重要性？
Max：我和你的感觉完全一样，Thorsten。我觉得它更轻松，至少在默认情况下视频没有打开的时候。看到大家的面孔也很不错。所以我还没有形成一个固定的哲学，但我很享受我可以，我不知道，一边吃着墨西哥卷饼，一边查看别人的代码，并且...
Nathan：对我来说，添加它似乎没什么问题。它不会增加太多的复杂性。所以我们可以添加它。只是这不是一个优先事项，因为我们不需要它。
Antonio：这周我和我的治疗师进行了一次谈话，我们谈到了当你去接受治疗时，那里有一把椅子，你叫它什么？沙发？是的，是的。基本上，她向我解释说，不看着治疗师，只是盯着虚空，会让你进入意识流模式。
我想我喜欢没有视频的这一点。我可以盯着某样东西，然后滔滔不绝地说出想法。
Nathan：但我要说的是，我弄到了一个 Vision Pro。我可能会把它退回去，因为我觉得它太重了。我可能会留下它。我不知道。我正在努力决定。但我想要的是如果我能在我周围放一个虚拟办公室。我想要一种情境感知，我不认为视频真的能提供。我在寻找别的东西。
我记得在 Pivotal 的时候，他们会有很宽的办公桌，他们会把四个，有时是六个办公桌放在一起，形成一个大的小组。你们一起工作，你就能感受到周围人的能量。你会听到这边，人们在谈论什么。因此，了解人们在做什么和他们在哪里是很重要的。
我们正试图在频道面板中重现一下这种感觉，你可以在那里看到面孔。
我不认为 Antonio 的脸的视频对我真的有用。我只需要 GPtonio 的代码输出，你知道吗？但如果我能看到 Max 和 Conrad 或者你和 Julia ...
Antonio：...吃着墨西哥卷饼。
Nathan：...那种近似的感觉会很酷。但是，你知道，让我们先尝试让 Following [Zed 协作模式中的一个功能] 正常工作。