Context：我的团队正在开始一个新的中等规模的Swift项目（大约20 MM），我正在考虑在RxSwift中进行开发。我的一位经理怀疑，一旦他对Reactive Programming进行调试时经验很差，因此他建议避免使用RxSwift并选择经典的Swift。我试图找出RxSwift的缺点，但我发现them中都没有提到可调试性问题。
问题： RxSwift在可调试性方面的实际技术限制是什么？
自2015年首次发布以来，我一直在使用RxSwift。这些年来，我将其投入许多中小型项目中。我不会说很难调试，但是调试它[.debug()操作员放在重要位置。
编写单元测试。将一些逻辑包装到运算符中，然后使用RxTest为其编写测试是非常容易的，我不知道为什么除了使用MVC习惯于单元测试之外，还有更多的人不这样做，这是一个痛苦。
根据我的经验，最难调试的部分是资源泄漏。除非您在调试版本中包含TRACE_RESOURCES标志，否则即使检测到它们也可能很困难。完成此操作后，您可以将以下内容放入您的应用程序委托中：#if DEBUG
_ = Observable<Int>.interval(.seconds(1), scheduler: MainScheduler.instance)
.map { _ in RxSwift.Resources.total }
.distinctUntilChanged()
.subscribe(onNext: { print("♦️ Resource count \($0)") })
#endif
这样，当您在屏幕之间来回移动和第四次移动时，可以确保资源计数正确无误。最后，您最终使用的架构与大多数Swift开发人员所习惯的相比，具有相当大的功能并且有很大不同。如果做得正确，最终将获得更多的闭包和自由功能，以及更少的协议和扩展，因此也需要习惯。
加入我们的RxSwift团队，那里有一群知识渊博且积极主动的参与者，他们乐于全天随时回答快速问题或分享一些代码。 https://rxslack.herokuapp.com