（以及如何创建在更新后继续有效的解决方案）
“应用程序只能使用公共 API，并且必须在当前发布的操作系统上运行。”苹果应用程序审查指南
如果您曾经开始使用新框架并发现自己在想：“现在我自己就能理解所有内容，阅读文档太长了”，那么您绝对不是一个人。我们中的许多人都有一种天生的调查本能：先尝试，然后再查看说明。这是完全正常的。
然而，在这个阶段，很容易得意忘形，最终陷入代码运行良好但可能依赖于系统的非明显功能的情况。
为什么有时仅仅“自己解决”还不够？
框架，尤其是封闭框架，是复杂的、多层的系统。它们经常隐藏内部逻辑和优化：
* 公共文档中没有描述；
* 不保证该行为将来会维持；
* 可能会随着新版本的发布而改变；
* 可能包含开发人员已知但尚未修复的功能。
当我们凭直觉行事时，存在根据随机观察而不是根据记录的规则构建架构的风险。这可以使代码对更新更加敏感。
文档不是限制，而是可靠的支持
框架开发人员创建手册来帮助我们。在文档中执行操作，我们得到：
* 稳定;
* 支持;
* 可预测的系统行为。
如果超出这些限制，我们就会承担额外的风险，并且维护此类代码会变得更加困难。
实验？当然。但要了解边界。
好奇心是开发人员的一大特质。探索和尝试新事物是绝对必要的。但这里有一个小小的愿望：
最舒适的实验方法是依赖最佳实践。
该文档是一张地图，显示哪些路径最安全并受到创建者的支持。
外部观点：专家建议
我们经常向经验丰富的同事学习：
*他们开设有用的课程，
* 在会议上发言，
* 写精彩的书籍和博客，
* 分享他们独特的愿景。
他们中的许多人分享了真正宝贵的经验。但值得记住的是：如果作者的方法与官方文档相矛盾，它们可能会变得脆弱。
有时，这种“经验模式”：
* 仅适用于特定版本的框架；
* 对更新敏感；
* 在异常情况下可能会出现不可预测的行为。
向社区学习是伟大且有益的。但任何建议，即使是最权威的建议，都应该仔细检查官方手册。
关于 SOLID 的一些知识
SOLID 原则中的三个想法完美地补充了这种方法：
* 开放/封闭原则：尝试通过公共 API 扩展行为，如果可能，不依赖隐藏的实现。
* 里氏替代原则：依赖合同，而不是具体执行。否则，幕后的变化可能会导致意想不到的困难。
* 依赖倒置：建立对抽象的依赖，而不是细节。
在实践中，这意味着与框架的内部、未记录的细节相关联会使系统变得脆弱。
基于公共接口和合约，我们得到：
* 更好地将代码与框架的更改隔离；
* 易于测试；
* 架构的可预测性和可靠性。
如果出现错误怎么办？
也有这样的情况，一切都按照规则去做，但结果却没有达到预期。框架不断发展，但并不总是完美的。在这种情况下：
* 构建一个重现问题的最小示例。
* 确保仅使用记录的 API。
* 发送错误报告 – 开发团队一定会感谢您的工作并尽力提供帮助。
如果该示例依赖于解决方法，那么开发人员提供支持将会更加困难。
如何充分利用框架
*请参阅文档。
* 遵循作者的指南和建议。
* 在所描述的功能范围内进行实验。
* 检查来自互联网和官方来源的建议。
* 本地化错误，同时尊重框架契约。
结论
框架是强大的工具，有自己的游戏规则。如果忘记它们，我们的代码就会变得过于脆弱。但我们都希望创建的产品能长久存在，而不是在每次小更新后都需要紧急修正。
手册和文档是极好的支持，有助于创建真正可靠的解决方案。
来源
https://developer.apple.com/app-store/review/guidelines/
https://en.wikipedia.org/wiki/SOLID
https://en.wikipedia.org/wiki/API
https://en.wikipedia.org/wiki/RTFM
Leave a Reply