在开发移动应用程序时，我不得不多次创建一个项目。 同时，我和我的团队一直在项目的基本设置上花费很多时间，例如集成第三方工具，设置项目结构，编写基类，集成外部库等。
我决定可以减少启动项目所需的时间，并且可以使流程的主要部分自动化。 同时，我收集了我们使用的最佳实践和工具，并准备
了一个在启动新项目时使用
的项目模板 。 这样的模板应节省开发人员配置新项目的时间，并提供每个团队成员都习惯的通用项目结构，这样您就不必再为他思考和研究新项目的结构了。 现在总是一样。
模板中添加的每种工具或方法都应单独撰写一篇文章，但我想尝试总结每个段落，并简要说明为什么我将它们包括在本文中。
椰子足
我认为可可豆不需要提交。
这是一个用于管理iOS项目的外部依赖关系
的库。 它已经存在了很长时间，并且已经在数千个（如果不是数百万个）项目中得到了可靠的实践证明。 还有其他的依赖项管理器，例如：
Carthage ，但我决定继续使用Cocoapods，因为它具有受支持的开源项目范围最广。 使用Cocoapods非常简单，并且带有
搜索索引 ，可轻松找到随时可用的软件包。
模板项目提供了一个简单的
Podfile ，其中包含Swiftlint和R.swift。 该模板还包括一个
gem文件，用于管理用于依赖性管理的Cocoapods版本。 开发人员通常会忽略此解决方案，但是它可以防止团队开发人员使用不同版本的Cocoapods安装依赖项时发生的问题。 Gemfile强制整个团队使用相同版本的Cocoapods。
斯威夫林特
Swiftlint是一个非常有用的工具，用于由一个团队中的每个开发人员强制执行某些规则和编码样式。 该系统可以被认为是一种自动代码验证系统，该系统可以警告开发人员有关危险时刻的信息，例如强制转换，强制尝试等，但除上述之外，该系统还采用了通用的编写代码，监视代码的方式。这样所有开发人员都遵循与“代码样式”相关的相同规则，例如：缩进或间隔。 这种方法具有巨大的优势，不仅可以节省代码验证的时间，还可以使项目文件易于识别，从而提高了文件的可读性，并因此提高了开发团队所有成员的理解。 此
链接提供所有规则的列表。 在Swiftlint模板中，它是使用Cocoapods安装的，并包含在“编译阶段”步骤中，因此，每次编译项目时，它将向开发人员显示警告。
斯威夫特
R.swift是一种用于获取强类型的自动填充资源（例如图像，字体段和本地化）的工具。 它通过扫描项目并创建获取资源所需的类来执行上述所有操作。 该库的最大优点是，在使用资源时，它可以编写程序代码：
- 全类型 -更少的强制类型转换和关于将返回哪种方法的假设
- 检查编译时间 -不再存在无效行，这些行会在代码执行期间停止应用程序的运行
- 自动完成 -无需再次猜测图像名称/笔尖/故事板
考虑使用官方字符串API的以下代码：
let icon = UIImage(named: “custom-icon”)
如果您在图像名称上输入错误，将得到零。 如果团队中的任何成员更改了图像资源的名称，则在您强制图像扩展时，此代码将返回零或停止执行。 使用R.swift时，如下所示：
let icon = R.image.customIcon()
现在您可以确定该图标确实存在（由于编译时间检查，编译器会警告您是否存在该图标），并且您将确保您不会在该图标的名称上打错字，因为您将使用自动完成功能。
R.swift使用Cocoapods安装，并在编译阶段集成到模板中，并将为每次编译生成Swift shell类。 这意味着，如果添加文件/图像/本地化/字体/颜色/笔等，则在编译项目后，所有这些都可以通过R.swift获得。
单独的AppDelegate文件进行测试
很多时候，他们忘记了运行测试时使用单独的TestAppDelegate类的良好做法。 为什么这是个好主意？ 通常，在应用程序启动时，AppDelegate类会执行大量工作。 它可以具有窗口配置逻辑，配置应用程序用户界面的基本显示，执行注册逻辑以接收通知，具有数据库连接设置代码，甚至有时可以进行服务器API调用。 单元测试不应有副作用。 您真的不希望随机调用API并自定义应用程序的整个用户界面结构只是为了运行单元测试吗？
TestAppDelegate还是一个合适的选择，它可以使您只希望在测试套件执行期间仅运行一次代码。 它可能包含生成模拟对象，网络请求存根等的代码。
模板包含main.swift文件，这是应用程序的主要入口点。 该文件中有一些方法可以测试应用程序的环境，如果是测试环境，则可以调用TestAppDelegate。
编译器性能分析标志
Swift是一种很棒的语言，比Objective-C（IMO）更易于使用和安全。 但是，当它第一次被引入时，它有一个很大的缺陷-编译时间。 回到我在Swift中进行项目时，该项目包含约4万行Swift代码（中型项目）。 该代码非常繁重，具有设置和类型推断功能，并且编译干净的程序集将近5分钟。 如果进行了很小的更改，则将重新编译项目，并且大约需要2分钟才能看到更改。 这是我经历过的最糟糕的经历之一，因此，我几乎停止使用Swift。
然后唯一的解决方案是尝试分析项目的编译时间并更改代码，以使编译器更快地工作。 为了帮助解决此类问题，
Apple引入了一些非官方的编译器标志 ，这些
标志警告开发人员编译方法主体或确定表达式类型所需的时间太长。 我将这些标志添加到模板项目中，以警告您的应用程序编译时间长。
如今，编译时间已大大减少，开发人员很少需要优化代码以减少编译时间。 但是与项目解决方案过大之后尝试解决此问题相比，事先了解所有信息还是要好得多。
开发/登台/生产配置
另一种好的方法（或可能是必要的）是为开发环境，最终测试和应用程序发布使用单独的配置和环境变量。 当前，几乎每个应用程序都应与服务器一起使用，并且通常将这些服务器部署在多个环境中。 开发人员将开发环境用于日常部署以测试其代码。 最终的测试环境用于创建稳定的版本或供测试人员和客户进行测试。
在iOS项目中支持多种环境的一种方法是在项目级别添加配置。
项目级配置定义配置后，您可以创建一个Configuration.plist文件，其中包含每个环境的变量。
配置文件启动项目时，可以指示应使用哪种配置。 您可以在装配图中执行此操作。
然后，您需要向Info.plist项目文件中添加另一个属性。 该属性的值将在运行时以当前配置的名称动态替换。
所有这些都在模板中预先配置。只剩下编写一个可以在运行时提取这些变量的类，这取决于在组装方案中选择的配置。 该模板包含
ConfigurationManager类，该类可以检索当前环境的变量。 您也可以在Github上检查此类的实现，以了解其工作原理。
自述文件
每个项目应包含一个自述文件，该文件至少包含有关安装依赖项和启动项目的说明。 它还应包含对项目体系结构和模块的描述。 不幸的是，开发人员不喜欢编写文档（自述文件是这项工作的一部分），我看到一个开发了几个月的项目，甚至还有一个自述文件。 为了减轻编写自述文件的负担，模板包含一个
标准的自述文件 ，该
文件涵盖了项目的安装和结构。 使用模板设置新项目时，将自动包含自述文件。
吉特尼奥雷
当前，大多数项目使用GIT作为版本控制系统。 使用GIT时，开发人员不想忽略项目中的某些文件或文件夹，例如build文件夹或派生数据文件夹。 为了使开发人员不必查找适合其iOS项目的gitignore文件，该模板包含Github成员提供的标准gitignore。
处理外部链接和通知的基类
如今，几乎每个应用程序都应处理外部链接和通知。 为此，开发人员必须在AppDelegate类中编写一些标准代码。 该模板包含有关如何执行此操作的描述，还
包含有助于使用外部链接和通知的
基类 。
结论
总而言之，所描述的
模板包含最佳方法，并集成了有用的第三方工具。 所有这些都可以节省您的团队在建立新项目上花费的开发时间，并为其余项目提供通用而坚实的基础。
让此模板为您和您的团队服务！