您已经完成了一门课程，在 YouTube 上观看了一系列视频，或者阅读了一系列有关 iOS 开发的文章，现在您准备好编写您的第一个宠物项目了。 首先，干得好！棒极了。你好酷！ 💪 其次，宠物项目可以极大地提高你的技能。当你开始自己做某事，而不是遵循指示时，你必须花费大量的时间和精力，大量谷歌，阅读大量新信息，并尝试过滤它并将其精确地适合你的情况。简而言之，这已经是一项真正的任务，可以让你提升五倍。 然而，大多数初学者都会忽略关键的事情（不是出于主动，而是没有理解它们的重要性）。在过去的六个月里，我一直积极地 帮助新人解决问题，包括宠物项目。 辅导 我已经确定了作为初学者，您应该将其纳入您的必备清单、掌握、理解和使用的前三点。 访问权限 一开始，几乎没有人关注 修饰符。同时，如果你在半夜叫醒他们，每个人都可以立即解释 。阅读了各种聪明的文章后，人们尝试根据 （单一责任）的思想创建一堆类。 private SOLID S 然后，他们问心无愧，将 的属性从 ，反之亦然。 class A class B class A { var someAValue: Int? } class B { let a = A() func foo() { a.someAValue = 1 } } 一般来说，如果仍然不清楚，这里是计划： 总是在任何地方都写 private ，当编译器抱怨时 - 想一想，可以从外部访问这个属性或函数吗？如果是的话——删除 private 。 当您思考时，请通过现实世界的比较来指导自己。例如，如果您的类是商店，那么外部客户显然应该可以访问 属性。但 显然只能由内部商店员工更改。 goods moneyInCashRegister 毕竟，即使使用 ，客户也不应该访问收银机，更不用说 。 put fetch 有人可能会说，“我非常清楚哪些属性可以被触及，哪些属性甚至在没有 修饰符的情况下也不能被触及”。然而，编写访问级别修饰符是设计的一部分。我确信您不会为三楼有一扇通向外面的门的房子创建一个蓝图。 private 然后，记住不要打开它。毕竟，其他人也可能会使用您的代码。 顺便说一句， 和 也存在类似的情况。再次强调，除非您立即确定要更改该值，否则请始终使用 。 var let let 架构简单 我注意到初学者试图提前计划一切的趋势。虽然这是值得称赞的，但开发人员经常由于缺乏经验而犯错误。他们预先准备过于复杂的管理人员（通常是从 ）有许多复杂的方法，但他们最终从未使用过。结果，代码的数量和复杂性都增加了。 堆栈溢出 我们的程序员最终得到的只是问题和误解，而不是看似方便的现成服务。建筑也是如此。 让我简要介绍一下编程的历史来传达我的观点。到 20 世纪 60 年代末，随着编程开始流行，程序的规模也随之增加。正如您所理解的，程序规模越大意味着代码行数越多，从而导致程序的复杂性和理解难度增加。 为了解决这个问题，出现了结构化编程——允许将程序划分为更小、可管理的部分的函数和过程。代码变得模块化、可重用且更易于理解。 结构化的出现导致程序进一步增长，直到它们再次达到其规模和复杂性极限。因此，到了 20 世纪 70 年代末和 80 年代初，面向对象的编程方法形成了。该解决方案支持创建灵活且可扩展的系统，解决日益复杂的任务。 在接下来的十年里，我们见证了电脑游戏的繁荣。事实证明，对用户操作（点击、按下）的反应至关重要，从而导致了事件驱动编程的出现。 为了在 Web 和桌面应用程序中组织代码（当需要从不同角度重新排列相同的数据时），MVC 模式（即，将模型与其视觉表示分离）应运而生。 您已经掌握了主要思想：问题出现，-> 解决方案出现。 问题->解决方案。 那么，为什么初学者程序员现在在问题还没有出现的时候就开始应用解决方案（架构）呢？教程立即建议至少选择一个 MVP。一个/两个屏幕的测试任务始终指定不使用 MVC。 在采访中，一个曾用相同的一/两个屏幕编写过几个喜欢的项目的人会被问及 VIPER 问题。如果他还没有遇到问题，他怎么可能知道这些问题呢？ 人们经常在架构的背景下谈论可测试性的便利性，但他们从未编写过测试。即使有，也只是基于一些教程，只关注单元测试，而不将它们与实际应用程序联系起来。 他们可以用简单的术语解释 MVP 方案，但当涉及名称相似的协议（例如 和 时，他们经常会感到困惑。在内心深处，他们已经将这一切视为一些开销🙄🤯 ViewInput ViewOutput 结论：不要给自己制造问题。不要为 MVC 感到羞耻。当你的控制器变得太大，或者你遇到不便时，你就会明白是时候寻找新的方法了。 用户界面简单 前端开发是初学者的多巴胺天堂。您编写代码并立即在屏幕上看到结果 - 收到您的奖励🍭。无可否认，这具有激励作用。然而，这枚硬币也有其反面。初学者通常会努力立即创建过于复杂的 UI。 此外，复杂的功能往往遵循复杂的用户界面。尽管 SwiftUI 简化了当今的任务，但人们仍然会花费大量时间添加花哨的东西，而没有取得真正的进展。 我在一门课程中学习了 iOS 开发，我们组建了团队并致力于一个项目。在我的团队中，一个人建议通过选择深色模式的字体和颜色来开始我们的应用程序开发。 总的来说，他花了整个课程的时间来学习它，值得注意的是，字体和颜色都非常棒。然而，在那段时间里，这个人编写了大约零行实际代码。 毫无疑问，应用程序的美观和功能至关重要。最终，你将不得不在这方面花时间。最好从更简单的事情开始。开发 MVP（最小可行产品），专注于最关键的功能，然后从那里启动。 相反的方法将导致解决复杂的细微差别并不断处理不断出现问题的主要功能。 这 80–20 规则 此处适用 - 创建应用程序的基础，然后添加其他内容。 对于移动开发新手来说，存在过早采用复杂解决方案的风险。虽然前端开发的视觉奖励可能很诱人，但从简单的 MVP 开始通常更明智。 历史趋势表明，解决方案应该不断发展以应对真正的挑战。 了解基本原则并解决出现的现实问题对于有效发展至关重要。 也发布 在这里
