ios - 在路径数据模型或其他问题的情况下如何遵循干净的代码规则

我真的很喜欢干净的代码设计和不同的架构模式和解决方案，比如 VIPER 等。我喜欢单一责任规则和 SOLID 原则。但是有时我们需要进行与用户数据相关的更正，这可能会涉及到我们需要编写额外的代码来解决/修复一些可能会破坏代码设计并增加其他用户对代码理解的复杂性的问题的情况。

让我举个例子：我有一个屏幕可以创建带有名称的练习，还有一个屏幕可以显示所有创建的练习。

我会说崩溃可能是由 iOS 或其他一些后台进程引发的，而不是由我的创建练习方法引发的。

假设现在我们将这个应用程序发布到商店，并且由于一些意外的崩溃，一些用户的数据库中有这个僵尸记录。

在此之前，我的代码是按照所有干净的代码规则设计的，但存在一些潜在的“僵尸”问题。

所以现在我需要以某种方式纠正这个问题。例如，在开始时，我可以运行一个方法来检查是否有任何没有名称的练习。没关系，这只是技术解决方案如何检查那些我不需要在这里回答的僵尸。我只想问应该如何使用干净的代码样式编写代码。

因为我会添加额外的代码来删除僵尸，实际上它不是我精彩架构的一部分。

我是否需要编写一些需要存储这些路径/修复功能的类，或者我是否还需要遵循其他一些规则。

可能可以在应用程序委托中放置一个在应用程序启动时调用removeAllZombies的函数，但即便如此我也不喜欢。但是，如果我们说很多潜在的路径，那么代码可能会一团糟。

我知道这也是可测试性问题的一部分，但有时我们无法通过测试和动态路径数据模型来涵盖所有问题，向视图控制器、演示者、服务等添加大量额外行是一种非常快速的破解方法一个项目和项目代码设计规则。

标签： iosswift