诗人的灵魂无法忍受默默无闻，他慷慨地分享了他的崇高思想。 （c）匿名
不久前，我写了三篇文章“针对手机游戏的建筑解决方案”，专门讲述我的梦想的架构：
•
第1部分：模型•
第2部分：命令及其队列•
第3部分：关于喷气推进的观点我什至曾想过将这种产品用于资产，但是在投票过程中，事实证明，对于人们而言，想法和讨论比完成的代码重要得多。 从那以后，我在两个游戏办公室工作，一个参与了，一个仍在从事台式机游戏，但是在两种情况下通过反应来组织用户界面的想法非常方便，几次加速了复杂界面上的某些工作，并使得实现界面成为可能以前似乎太复杂了。 所有这些表明，即使是第一个封闭Beta测试的阶段也不能太晚，以使项目变得更好。
我查看了各种YouTube编程报告，发现它们之间存在一定的共通性：即使是完全正确的想法，也很难进入那些最需要它们的人的脑海，有时由于故事中的代码很少而被误解了。 从这样的报告中得出的程序员只能坐下来开始写作，只要已经告诉他的内容对他几乎可以理解，而他只是没有时间为自己猜测。 在本教程的另一端，您好世界。 一般来说，悲伤。
这里有一个“最近发展区”的概念：它由一个人自己无法解决，但能够与已经采取这一障碍的人共同解决的那些任务的内容决定。 一个人最初在他人参与下可以访问的东西，然后变成他自己的财产（技能，能力）。 因此，与强大的领导者一起完成一个有趣的项目当然是最有用的。 但是我在哪里可以找到所有项目，甚至更多。
总的来说，考虑所有这些，我想尝试以不同的格式与人们分享：我将安排一个专门用于代码审查的流，我将展示我的代码用于响应性，并解释其中的那些想法以及为什么这样写而不是这样写否则。 流将持续一个小时。 在本文的这篇文章中，我将简要描述我想谈论的内容，然后在事实之后，我将添加时间安排，我设法讨论的问题以及从什么时候开始。
在此过程中，您可以并且应该提出问题，因为他们说代码的质量由每单位审阅时间的WTF量来衡量。 可以在评论中在此处提出任何更详细的问题，如果有一段适合答案的代码，我将在流程中尝试回答这些问题。
在此过程中，您可以并且应该纠正我并指出错误。 因为肯定会有某人特别是或一般而言更聪明，并且还因为当一个人查看自己的代码时，他似乎看不见代码的一部分，因此大脑已经有这样的“盲点”写成的意见，并且没有重新阅读它们。 就我所知，很多人在您再次对代码调用两只眼睛时，突然有一个局外人在您看不见的最明显位置注意到明显的错误。 对于不同的人，“盲点”以不同的方式落在同一代码上。
该视频流将于周三22:30开始（这是我的空闲时间，：：），并将在此处提供：
现在介绍流的内容。
通常，UniRX库中有一个很好的反应性实现，我强烈建议您熟悉它。 也许您会自己拿走它，或者只是从那里抹掉想法。 但我会展示我自己的自行车，是从头开始编写的。 这不仅是因为我爱骑自行车。 在UniRX中，实现标准的系统接口。 IObserver <输入T>和System.IObservable <输出T>。 而且在许多地方，ThreadSafe都会（并非总是正确地）在内部执行此操作。 也就是说，该库有很多额外的代码，并且对其进行扩展很不方便。 实际上，在三分之三的情况下，我需要扩展并适应当地条件。
此外，正如我们的技术总监Assetstore所说，时间会增加，但不会动摇。 如果您从那里写了自己无法写的东西，那么早晚您将this一口这段代码。
没错，我不会显示在游戏中真正起作用的应用程序代码，而是我的家用版本。 首先，这是不可能的，其次，更重要的是，我在家中有一个更实用的版本。
如果我们对接口使用反应性，那么完全不需要多线程。 我们要做的最终就是在UnityThred中移动屏幕组件。 其次，即使在某些地方我巧妙地使用了我们极异步服务器引擎的功能，我也为同样的事情编写了线程，在更困难的情况下，我花了五倍的时间。 要使代码在没有放纵的情况下实现整个合同，将花费更多。
另外，IObserver本身就是一个问题。 首先，对我而言，它完全是多余的OnError（Exception e）方法。 当您使用多线程时，这具有深层含义，包括将此操作转储到UnityThread中并且不会被忽略。 最初，该接口是为了处理经常出错的文件而发明的。 但是在单线程模式下，当您使用应用程序模型时，这无疑是一次额外的出血，我更喜欢用代码将警报确切地在它死的地方引发。
IObserver的第二个问题是我想要事务性更改。 试想一下，List是从一个来源获得的，而从另一个流中获得的则是元素的索引，我们必须从工作表中删除该元素并继续传递。 这里的索引指向最后一个元素，这里的一个元素被删除，索引减少1。最后，一切都会好起来，操作的结果也不会改变，但是如果我们收到有关List更改的消息，然后才收到有关index更改的消息，该代码将捕获IndexOutOfRangeException。 实际上，应用更改顺序的同一问题可能会以多种其他方式表现出来，这是最明显的。
因此，我希望我的界面，一方面不拖动OnError，但另一方面包含.OnTransaction（ITransaction t）
我觉得太深了。 在屏幕上带有代码的流中谈论它显然会更快，并且更容易理解。 关于顶部的更多信息：
- 我的界面是IActive和IReactive。 它们比任何事件都更加美丽，其最终使用效果如何。
- ActiveProperty <T>。 它与Active.Proxy <T>的不同之处在于如何传递它以及如何处理变量的初始值。
- 我如何通过测试检查所有这些内容以及为什么它非常方便。 实际上，完全没有测试就不可能写出这样的东西。
- 客房清洁策略ID是不可能的。 支持OnComplete和ICollection <IDisposible>的双重机制
- 如何轻松进行流工具箱扩展并阅读最有用的示例。
- 所有这些混乱的调试工具。 首先是.Log（），下一次我们将转到CalculationTree。
- 仔细阅读Active.Proxy <T>代码，为什么没有背后的事件，而是一个双向链表。
- IActiveList和IActiveDictionary，最常见的想法。
- 如何拆分为ViewModel，Controller和View。 如何不循环播放流。
- 将变量从反应性删除到模型的过程。
- 具有最小增量的ActiveList和ActiveDictionary。 通常与DeltaDictionary的前端实现不同，特别是与UniRX不同。
- 纠正代码错误的一般策略，因为大学中没有此类主题，但应该这样做。
实际上，已经有几个小时的故事和代码展示，所以让我们从第一个小时开始，然后是如何践踏。
PS：这是我的第一篇文章，因此请不要严格判断是否存在任何技术问题。