在写一个iOS应用之前必须做的7件事

转载自：http://www.cocoachina.com/ios/20160316/15685.html

原文：https://medium.com/ios-os-x-development/7-things-you-must-absolutely-do-before-writing-an-ios-app-a8bacf710c57#.y7k0hh9mb

英文原文第一部分：https://medium.com/ios-os-x-development/things-i-wish-i-had-known-before-starting-ios-development-part-1-421a05e8447e#.15nbie4zf

英文原文第二部分：https://medium.com/ios-os-x-development/things-i-wish-i-had-known-before-starting-ios-development-part-2-d696eec65866#.8k6vbuqjf

这两年，我一直在编写并发布有质量的iOS 应用。我发现大多数的开发人员有直接跳进编码应用程序的核心逻辑的倾向，因为这是乐趣所在。遵循流程开发是很无聊的。

我了解到最有效的方式是，如果你提前花些时间正确设置项目，你将会为将来节省大量的时间。如果你是一位独立开发者，你可能意识不到下面提到的这些步骤的重要性。大多数优秀的应用程序都由团队开发，如果遵循以下步骤，肯定能帮你减少挫败感并提升应用质量。

1.为工程设置编码风格规范

编码风格规范指的是在使用特定语言写代码之前要明确遵守的风格和惯例，它包括类似于该使用tab键还是空格键，如何命名变量以及特定语言本身的约定俗成（像swift语言中是否该使用Classes还是Structs）。

编码规范本身没有孰对孰错。在项目开始前，你可以设置自己的编码风格，但是必须保证同组的人遵守相同的规范。编码规范能够保证代码更加统一和更易于阅读。

一些公司已经开源了Objective-C和Swift语言的编码规范。

• Ray Wenderlich/Swift Style Guide

• GitHub/swift-style-guide

• NYTimes/objective-c-style-guide

2.在写代码之前确定应用的架构

在写代码之前，确定应用架构是非常重要的。一个好的架构可以提升应用的可测试性，更加易于理解并且能降低维护成本。你可以使用传统的MVC架构，或者使用更加流行的MVVM或VIPER架构，这里提供了大量的资源来介绍这些架构。

• iOS Architecture Patterns（中文版：iOS 架构模式--解密 MVC，MVP，MVVM以及VIPER架构）

• Issue 13 Architecture *objc.io

• Modern application architectures (Reactive programming, MVVM and beyond)

3.设定应用的目录结构

为了使数以百计的源代码文件至始至终保存在相同的目录中，最好是根据项目的架构制定目录结构，例如，你可以使用以下的目录结构：

首先，在Xcode的Project Navigator中工程名称分组下面，以group的形式创建它们（小黄色的文件夹），然后，通过打开Xcode右边的File Inspector，为每个创建的group链接到真实的项目路径下对应的目录，点击File Inspector中小的灰色的文件夹icon，在工程目录下创建对应group名称的子目录。

这个看起来是件小的事情，却可以使你的项目更加有条理且易于理解。

了解更多目录结构可以参考以下资源：

• futurice/ios-good-practices

4.项目依赖管理

你当然会在项目中使用第三方库，在项目中，你可以有三种方式可以管理项目依赖。

• CocoaPods

CocoaPods是适用于Swift和Objective-C Cocoa项目的依赖管理库，它有将近10000个开源库，可以优雅地帮你管理项目的规模。它是最有效的方式做依赖管理，就像Ruby中的Gems。

Youtube上有一个google开发者创建的滑稽的视频（地址，需FQ）来解释为什么必须在项目中使用CocoaPods。

• Github Submodules

你也可以使用Github Submodules管理你的项目依赖作为子库，相比CocoaPods，Github Submodules的优点在于它是sub-repos- 这不仅意味着git和git GUIs能够隐式识别他们，并且也可以获得更多支持，同时意味着你的工程依赖能够更加紧密的联系到他们的git仓库，而Cocoapods则不能。

submodules的问题是：你的工程不拥有你依赖库的源代码，仅仅是拥有一个引用到submodule的仓库。大多数情况你控制不了这些代码仓库。

• Carthage

Carthage被认为是往Cocoa应用中添加框架的最简单的方法。Carthage使用xcodebuild编译framework二进制，但是把集成的任务留给了用户。CocoaPods的目的是对用户简单，但是Carthage对用户来说是灵活的、不干涉的。

不幸的是，Carthage的最大的缺点是----只支持iOS8及以后版本。

这三个当中，我最常用并且我个人最喜欢的是CocoaPods，因为它设置超级简单，并且提供了数以千计的第三方库供你访问。

5.为应用设置合适的Scheme

当你点击了Run、Test、Profile、Analyze或者Archive 操作后，Schemes告诉Xcode什么会发生。通常，每个操作对应一个target和一个编译配置。你也可以传递启动参数，比如应用运行的语言(测试本地化很有用)或者debug时设置一些判断的标识位。

建议Scheme的命名规则采用MyApp () [Environment]:

你也可以使用Target制作不同的发布、测试以及开发来编译程序，如以下描述：

• How to Use Xcode Targets to Manage Development and Production Builds

6.设置合适的Certificates和Provisioning Profiles

在测试和发布应用过程中，这个是开发者最头疼且重要的步骤。证书对代码签名来说是必须的，你可以在真机上运行应用程序。

有两种类型的证书：

• 开发证书：每个团队的开发者都有自己的证书，需要请求生成。Xcode会为你做这些，但是最好不要点击“Fix issue”按钮，并且能够理解点击这个按钮会真正执行什么。开发证书是发布应用的开发版本到设备上。

• 发布证书：可以有多个，但是最好保持一个公司一个发布证书，通过内部渠道分享相关的秘钥。发布应用到App Store时需要这个证书，或者是公司内部的企业级应用分发。

• Provisioning Profiles

Provisioning Profiles 可能是系统中最容易引起混淆的部分了，如果你访问苹果开发者网站，你会注意到你可以创建两种类型的Provisioning Profiles（开发和发布）。Provisioning Profiles是“以这个证书的私钥作为签名的应用可以在这些设备上正常运行: https://www.quora.com/What-are-the-differences-between-certificates-provisioning-profiles-and-identifiers

你可以阅读更多相关资源:

• Maintaining Your Signing Identities and Certificates

• What is a Provisioning Profile? Part 2

7.设置应用持续集成和交付过程

建立一个持续集成和交付过程已成为关键，因为现在它可以帮助您在开发早期发现bug和节省大量的开发人员的时间。

持续集成 (CI) 是一种开发实践，要求开发人员一天将代码同步到共享存储库几次。每次提交都会用自动脚本进行验证，可以使团队尽早的发现问题。

很多工具可以帮你做iOS应用程序的持续集成，比如 Xcode Server、Jenkins和Travis CI。

• About Continuous Integration in Xcode

• Travis-CI:Test and Deploy with Confidence

• iOS CI with Jenkins

持续交付 (CD) 是一个软件工程的方式，可以使团队在短周期内开发软件，确保软件可以在任何时间可靠地发布。它旨在更快、更频繁地构建、测试和发布的软件。

为什么使用持续交付？

• 可以在准备应用提交、上传截图以及发布应用上节省数天时间。

• 如果在同事休假期间，但你发现一个严重问题需要修复并发布怎么办？在发布更新版本时不需要依赖某一个人。

• 通过更频繁和小版本的更新，提高软件质量和反应时间。

虽然有大量的工具供持续交付，我个人最喜欢的是Fastlane。它非常容易安装，并提供了一些强大的功能，可以使你整个的编译和发布过程自动化。

• Fastlane