Stephen Cleary是Stack Overflow的
前100名用户之一。 主要是由于它在.NET中的异步答案。 他的生活不仅限于编程：在Twitter上，他首先写自己是“基督徒”，然后才是“开发人员”。
现在，与异步流的出现有关，他的知识尤为重要：作为该主题的报告员，斯蒂芬的身影就是这样。 不久之后，他
会在DotNext上讲述它。 同时，我们向他询问了所有这些问题：宗教，堆栈溢出和异步。
人物传记
-第一个问题很简单：告诉我们您的职业传记。-我很早就对编程感兴趣，当时我7-8岁。 然后在学校里，我能够用徽标语言编写一个小程序，这是我的第一次编程经验。 后来，当我12到13岁时，我保存了第一台计算机。 当我进入大学时选择计算机科学时，这是一个非常明显的决定：我已经对计算机产生了浓厚的兴趣。
1998年，我大学毕业后，就职于一家本地公司，从事由工业和其他工厂自动化车辆自动控制的输送机。 七年后，公司搬到了底特律，但我不想搬到那里，从那以后，我设法在不同的公司工作。 自2013年以来，我在Faithlife进行了为期一年半的远程工作。
-有趣的是，您从Logo开始，而现在在一家主要产品为Logo的公司中。 那你到底在做什么？-后端：徽标和公司其他产品访问的Web服务。 Faithlife有一系列与教会相关的产品。 徽标-用于圣经学习。 此外，还有Proclaim，专为讲道的人（帮助幻灯片等）而设计。 Faithlife过去曾为牧师生产产品，但现在他们正在添加对普通人有帮助的产品。
我有后端，我经常不得不处理ASP.NET Web API，现在我正在使用Docker。 现在，我们有一部分在云中，一部分在本地，有些东西根本不应该转移到云中，但是我们想在那里转移一些东西，而我正在这样做。
宗教信仰
-您通常不会遇到一家生产“教堂”软件的公司，所以我想澄清一下：在后端工作看起来像其他地方一样，还是有自己的特点？ 开发人员通常是信徒，自己使用公司的产品吗？-工作上没有根本的区别：您需要尽可能多地考虑API的正确设计。 我们的某些产品（尤其是台式机产品）已经存在很长时间了，我们必须处理旧的API。 在开始使用Docker时，考虑向后兼容性非常重要。 总的来说，我们与其他人有同样的担忧。
尽管Faithlife为教会生产产品，但它不是一家基督教公司。 要到达这里，您不需要成为基督徒：首先，这样的选择会违反美国法律（在雇用时会受到宗教歧视），其次，公司也不会这样做。
但是，对于开发人员使用公司产品的方式，我们采取了各种鼓励措施。 例如，最近度过了关于徽标使用的培训日。 我们也有许多内部工具-在这种情况下，我们建议每天在使用您的工具的部门亲自上班，看看情况如何。
-在生物领域的Twitter上有“基督徒”和“开发者”两个词。 您身份的这两部分是否以某种方式相交？-我会说他们是分开的。 我一直试图将工作生活与家庭分开，而不是在业余时间做工作（尽管有时并不总是工作）。 教会是我个性的重要组成部分，我的大多数朋友都来自那里。 在工作中，我很少交朋友。
“好吧，您的简历还说：“沉迷于编写OSS”，并给人们免费软件听起来无私和基督教。 在这种情况下，没有相关性吗？-嗯。 我认为，从哲学的角度来看，您确实可以看到开放源代码和基督教之间的关系：在这两种情况下，重点都在于您提到的“献给人民”。
还有一种“人道主义”类型的开源。 我本人不参与其中；我有通用库。 但我知道基督徒开发人员免费为某些直接影响他人生活的事情工作，特别是在穷人的地方。 例如，允许您确保火灾警报器正常工作的软件。 当然，这里存在相关性。
-您还积极参与Stack Overflow-这也是您无私奉献给社区的一种方式吗？-我不会这么说，对我来说，这更像是“教学”。 尽管“教学”也可以与基督教联系起来……我的家人有很多老师，我以自己的方式继续做这件事-不是作为一种职业，而是借助Stack Overflow和会议的帮助。 所以我满足了我的需求。
堆栈溢出
-关于第一个古怪的堆栈溢出问题，我们还有很多问题。 您最近在此处收到了徽章，以获取Windows Phone 8的答案：
在2019年，您如何获得关于即将失效的技术的答案的徽章？ 有人还在问关于她的问题吗？-要获得徽章，通常需要至少一定数量的答案以及一定数量的投票。 我想我之所以得到这个徽章，是因为现在有人投票支持我几年前发布的答案，并最终获得了正确的投票数。 这很有趣，因为我已经很长时间没有看到Windows Phone 8的问题了！
（笑）-在SO上，您的声誉为320,000-这是传奇人物John Skeet声誉的四分之一以上，尽管您给出的答案比他小一个数量级。 你是怎么得到的？-我不太确定。 对于那些比其他人都先访问该网站的人来说，获得声誉很容易，尽管我是最早采用该技术的人，但我来的时间仍然比许多人晚。 我开始回答问题-首先是每天1-2，离John Skeet太远了。 专注于异步/等待以及并发和多线程的主题-仅仅是因为它实际上成为了我的专长。 很多年前，我已经从事异步工作，那时候很痛苦。 因此，当异步/等待出现时，我立即看到了它们的含义。 所以我在正确的时间在正确的地方，我的“老师的鲜血”以人们能理解的语言帮助解释了一切。 而且在Stack Overflow的情况下，我原来是本地异步/等待专家。 约翰·斯凯特（John Skeet）-嗯，他没有直接说出来，但我想它是-有关异步/等待的大部分问题都留给了我。 但是，他当然比我回答得更多，他无法追上他！
-从声誉的数量来看，很容易想到“一个人花了一半的生命来回答”-您实际上在SO上花费了多少时间？“不是很多。” 我每天检查几次堆栈溢出，通常回答1-3个问题。 对于几年前留下的答案，我得到了大多数赞成票。 SO就是这样帮助早起的人：他们是多年前第一个回答问题，获得投票的人，声音使这些答案更加明显，最终他们获得了新的选票。 这是雪崩效应，鼓励旧的答案。
在我看来，这会引起一些问题，因为有时会有新的答案引用更现代的技术，因此会更好，但是旧的答案不会更新。 但是，总的来说，我会获得旧答案的大多数票，但我仍然每天都在尝试新答案。 我并没有花太多时间，只是多年以来我一直在不断地这样做。
-当John Skeet在DotNext上飞向我们时，我们向他询问了Stack Overflow的当前状态以及他认为该站点存在的问题。 比较有趣：您对此有何看法？“我认为SO正在改善，尤其是在去年。” 他们现在正在非常努力地提高问题的质量。 通常，人们首先在该网站上提出问题时，并不熟悉如何正确提出技术问题。
这是Internet上一直存在的问题。 在90年代，当每个人都在新闻组中时，她也在那里。 十年后，邮件列表和Google网上论坛都发生了所有事情。 现在，有关堆栈溢出编程问题的新资源。 但是一直存在关于编程的问题，如何提出一个好的问题一直是一个问题，以及如何维护一个友好的社区。 这些问题也许永远无法彻底解决。 我并不是说我们不应该为此而努力，我们绝对应该这样做。 但是，如果回顾过去，事实证明，即使在90年代，也已经有关于如何提出技术问题的书面教程。
堆栈溢出有两个新问题。 您可以从一个事实开始，他们中的许多人在问他们的第一个问题之前从未问过别人。 因此，在许多情况下，他们根本没有意识到问题中必须呈现的所有内容，以便可以对其进行回答。
然后，想象您正在执行一项任务。 您在代码中举足轻重，这一切使您满脑子。 您会看到一些无法以任何方式发挥作用的特定事物。 这是大型系统的一小部分具体细节，通常您会问：“我怎么做这件小事？”而没有意识到自己拥有所知道的所有上下文，但是没有将其放入问题中。 通常，“如何制造X”这个问题的正确答案是“不做X，做Y”。 这是人们在编写第一个问题时经常会陷入的陷阱。 他们没有意识到他们目前的回答是“无反应的”。
除了问题的质量问题之外，还有一种趋势-特别是在Stack Overflow上，每个人都在争分夺秒，试图尽快回答-快速关闭问题或迅速草拟并非最令人愉快的答案。 我并不是说“恶意”，多年来我很少看到坦率的恶意评论。 相反，它们是苛刻的，对于问题的作者，这被视为不友好。
堆栈溢出已采取一些简单的步骤来解决此问题。 现在，当人们第一次提出问题时，该网站会告诉您要包含的内容。 他们以前添加了“看看这些类似的问题”，这是一个很好的第一步。 现在，第一个问题需要完成一个完整的系统，这有助于更好地构成它。
它们还会为写答案的人添加提醒。 就像“这是一个新手，很友好”，这是提醒您大多数人第一次写的问题不好的好方法，这是完全正常的。 总的来说，他们正在努力。 这个问题会彻底解决吗？ 我对此表示怀疑。 但是进步是可能的。
异步性
-在专门针对iPhone 10周年的帖子中 ，您写道其外观影响了异步编程，因为移动应用程序必须具有响应能力。 您能为那些刚刚开始发展并且没有异步/等待就没有看到世界的人提供异步发展的一般历史背景吗？-异步编程一直都是可能的。 我认为他们在60年代就已经这样做了。 长期以来，他具有相同的优势：响应速度更快的UI和更可扩展的服务器部分。 支持一直是一个问题：维护异步代码非常困难。 最初，它是基于回调构建的。
我认为最大的一步是Promise的问世。 这就是他们在JavaScript中所说的，在C＃中是Task或ValueTask。 这是向前迈出的一大步，因为现在我们有了一个表示操作的对象。 您可以监视其进度等。 异步/等待任何语言本质上只是Promise的语法糖。
我会说Promise的出现是对异步代码影响最大的事件。 在异步/等待的情况下，为您创建状态机非常重要。 在过去，当我们使用回调时，我们必须自己制造自己的状态机。 这总是很困难，因为您不可避免地忘记了某些条件或过渡，而没有任何效果。 而且调试起来非常困难。 异步/等待并没有带来编写异步代码的能力，而是带来了可以支持的编写代码的能力。
-现在您是否看到局势得到了缓解，还是新的变化即将在等待着我们？-我认为现在一切都很稳定。 异步/等待看起来是革命性的-但仅适用于以前从未进行过异步编程的用户。 对于那些工作的人来说，这很自然。 但是，总的来说，这是一件大事。
现在，.NET Core 3附带了另一个事件。尽管它们实际上是异步枚举，但它们执行每个人都称为异步流的操作。 我认为这会让人们感到困惑，因为已经有与异步流无关的Stream类型。 通常，会有更多的增量改进。 我们会看到与异步/等待第一次宣布自己时一样大的东西吗？ 我不这么认为。
如果您想进行新的范式转换，总有可能基于角色的系统。 或类似goroutine的东西，其中所有异步都是隐式的。 我认为这些事情有些相似。 问题在于，在.NET中添加起来并不容易。 我认为.NET对此有太多限制，因此这不太可能发生。 如果我们看到向Actor世界或Goroutine世界的大规模过渡，那么并发的方法将不同于当今的多线程，那么这将需要全新的语言和运行时。 .NET是不值得的。 而且我不认为整个编程会取得如此飞跃。 也许我错了，但我目前的职位如下。
-更重要的是，随着时间的流逝，一切都会改变多少。 许多编程书籍都已迅速过时，但变化少的地方，它们的寿命更长。 您在C＃Cookbook中的并发情况如何，需要多少更新？-好问题。 我刚刚发布了第二版，第一版于2014年问世。 也就是说，已经过去了五年，而我们已经是第二版了-对我来说，这看起来像是一个快速的发展。
我认为这仍然取决于书的写作方式。 我试图写，以便它不会尽可能地过时。 您只需要尽量不要引用Windows Phone 8之类的东西，但是无论如何它都将不可避免地变得过时。 异步流之类的东西出现了，我想在书中包含这些东西。 结果，有些东西已经过时了，但是大多数材料没有更改就迁移到了新版本。
而且，当然，这完全取决于这本书是为谁而写的。 当然，有关使用Visual Studio 2008的书很快就会过期。 但是，我认为真正的经典之所在。 我认为《代码完整》是世界上最好的编程书籍之一。 它写了多长时间？ 我什至不知道 几十年前。 这仍然是一本很棒的书！ 其中有些过时了，但总体来说还是不错的。
-最近，在Twitter上进行了有关异步/等待的调整 ，这始于沃恩·弗农（Vaughn Vernon）的推文，沃恩·弗农（Vaughn Vernon）发了几本有关DTD和演员模型的书：
他不喜欢异步/等待重要性-在他看来，这遍及整个代码并可能导致线程阻塞。 您如何看待？ 设计其他东西值得吗？-是的，也许异步/等待在整个项目中蔓延是最常见的抱怨。 我想在这里提几点。
首先，为了实现真正的异步，异步代码要求每个调用它的人都具有异步性。 而且它不会绕开。 无论您使用哪种范例（甚至是旧范例之一），最终都会遇到它。 我有一份报告，按时间顺序浏览了所有范例，并说明代码如何变得越来越清晰。
有两种不同的方法来避免异步/等待的广泛支配地位。 首先是将所有输入/输出隔离到单独的对象中。 您可以使用端口和适配器之类的设计模式：这允许您包含业务逻辑之外的所有I / O，然后完全不需要任何异步/等待。 最近，我看到了一份有关如何通过重构项目来防止“无处不在”的报告，以使业务逻辑从不处理I / O。 我会推荐这种方法。
还有另一种方法来处理异步/等待的优势，但在.NET中不可行。 在我看来，Go尝试使用goroutine做到这一点。 实际上，一切都在那里-这是一个可靠的异步/等待状态。 您可以通过将async / await添加到所有内容并使其隐含来从该语言中删除它。
没有其他办法了。 当异步/等待出现时，有人（我不记得确切是谁）说这就像僵尸病毒：一旦您的代码的一部分被感染，就开始分发。
-一些开发人员使用actor模型，通过简化流控制来解释这一点（actor实际上是单线程的）。 您是否认为通过选择正确的库，开发人员可以摆脱编程并发的复杂性？“嗯，不完全是。” 因为即使使用参与者模型，问题仍然存在。 您不会遇到像多线程程序中那样的竞争条件，但是您将遇到友谊困难。
例如，消息延迟或异步消息的问题。 通常，它们对于防止角色模型中的死锁是必需的。 但是，任何使用异步消息的参与者模型也可能导致死锁。 异步消息也可能创建自己的协调问题。 通常在这个级别上，还必须处理幂等性。
而且，将参与者与异步消息一起使用可能会使状态管理非常混乱，除非它完全发生在消息中。 即使在这种情况下，最终的一致性也将给您带来困难。 一般来说，从我的角度来看，参与者模型无法解决所有问题。 我将以这种方式描述它：它只能更改确切出现问题的位置。
“您被称为捐助者，但是您使用诸如TypeScript之类的其他语言。” 当您尝试使用它们时，如何看待C＃和.NET？ 您在那遇到了您想在C＃中看到的东西吗？-好问题。 C＃从其他语言中获得了很多收益。 他从中受益匪浅的其中之一是Python。 我喜欢。 我已经多年没有使用Python编写过代码，但是我认为这是一种设计精良的语言。 我真的很感谢C＃从Python借用的枚举器块。 Python是最早出现Async流的人之一，因此我们可以说C＃从那里获得了它。
我用不同的语言喜欢不同的事物。 我通常更喜欢静态类型，因此最近我没有使用Python，并且出于同样的原因，我使用TypeScript而不是JavaScript。 JavaScript的优势仅在于其单线程。 例如，如果您查看Reactive Extensions的相关性，您会发现在.NET中这不是特别被接受。 在JavaScript中，随处可见Rx。
-最后两个问题是关于您在DotNext上的报告。 您将在那儿谈论异步流-您能简要地告诉.NET开发人员什么期望以及为什么该报告对他们有用吗？-因此，我关于异步流的报告：为什么将它们添加到语言中，以及它们的主要使用场景是什么。 我会非常务实地处理此问题，并且不会深入探讨正在发生的一切。 , async streams, , , async streams, .
— . — DotNext?— , , , . , : , .
, , , . - async streams , , , . , DotNext.
DotNext 2019 Moscow 6-7 . , — .