太长不读版
被动态语言宠坏的前端在初次开发 Native 应用的时候，容易掉进以下几个坑：
- 害怕程序崩溃
- 满篇 Optional
正文
首先说一下我司的背景。我司大部分开发人员是网页前端开发和 Java 后端开发。公司最近搞了一个 iOS 应用开发，使用了苹果的新开发语言 Swift。
经过了一段时间的开发，我发现前端开发者在初次开发原生应用，特别是使用静态语言时容易走入几个误区。
害怕程序崩溃
一个非常有趣的现象是，我发现很多开发者非常害怕程序崩溃掉，因此在代码中加入了大量的防御性代码。
其实这个东西见仁见智，但是个人认为，在函数遇到与预期不符的状况的时候，优雅地崩溃掉比为了不崩溃而隐藏错误重要得多。
举一个非常简单的例子：某个成员函数需要使用某个成员，而这个成员在这个类初始化的时候并不一定存在。
很多人会把代码写成这样：
class MyObject {
var somethingToBeSetOutside: ImportData?
func foo() {
guard let sth = somethingToBeSetOutside else {
return
}
// use 'sth' the import data
...
...
...
}
}
这看起来并没有什么问题。但是如果将来某个时候，外部的调用者偶然没有设置 somethingToBeSetOutside 这个成员的值，那么 foo 里面很大一部分代码都将不会被调用。而且这个 bug 将会非常难以查找。
那么这个问题怎么解决呢？其实在“古老”的 C/C++ 里面，有一种简单的处理方式，那就是 assert ——调用者如果想要调用某个函数，那么传入的参数必须满足指定的契约。
例子：
class MyObject {
var somethingToBeSetOutside: ImportData!
func foo() {
assert(somethingToBeSetOutside != nil)
// use the import data
...
...
...
}
}
这个例子看起来和前面的代码非常类似，仅有两个区别：
- somethingToBeSetOutside 的类型是 ImportData!
- 加入断言判空，如果不满足条件就让程序崩溃
我们把类型修改为 ImportData! 的目的是为了 foo 下面的代码能够直接访问这个 somethingToBeSetOutside 的内容。而加入断言的目的，是给这个函数加入了一个契约的概念，就是说我函数不负责检查你传入的参数，你要调用我，那你得负责输入的参数符合我的规则。
那么有人可能会说了，程序编译成 release 以后，就不会做 assert 检查了，那你这程序交付给客户的时候崩溃了掉了怎么办？
其实这很简单，这个 assert 的作用是在开发的时候防呆，在 debug 时候给开发人员提示错误原因，而不是用来保证 release 代码正常工作的。只要应用程序经过了适当的测试，基本上所有错误调用的地方都能在上线前被找出来。
另外，如果遇到了数据真正是可能没有的情况，代码也不应该这样写了。
满篇的 Optional
先上代码：
struct APIReturnedPassenger {
let firstName: String?
let middleName: String?
let lastName: String?
}
因为不能确认 API 返回的数据是否包含了 Passenger 所有的信息，有些开发人员就把结构上的很多成员做成了 Optional 的。
这看起来似乎很好。但是，如果我把这个翻译成 C 的结构：
struct APIReturnedPassenger
{
char *firstName;
char *middleName;
char *lastName;
};
看出什么没有？这似乎就是 C 语言被新人诟病的指针满天飞！
这种例子非常好解决。
首先把结构设计成下面这样：
struct APIReturnedPassenger {
let firstName: String
let middleName: String
let lastName: String
}
然后在接收 API 返回内容的地方，对返回的信息做验证即可。
如果 API 返回的信息不满足我们预先设定好的格式，直接提示用户服务器出现了故障或者使用预先设定的默认值，后面的代码写起来不要舒服太多。
再看一个例子：
假设这是一个点餐的系统，客户可以选择不要甜点，一份甜点，或者两份甜点。恐怕下面这种代码是很常见的：
func setDessert(firstDessert: Dessert?, secondDessert: Dessert?) {
...
}
可以想象，后面处理甜点的代码将是大灾难，到处都需要判空，各种复杂的逻辑处理。
其实 Swift 提供了一种机制，在处理类似的问题上非常轻松愉快。
enum DessertType {
case NoDessert,
case OneDessert(Dessert),
case FullDessert(Dessert, Dessert)
}
func setDessert(dessert: DessertType) {
...
}
程序这样写以后，我们可以发现完全不需要处理各种奇葩的逻辑了。
总结
使用静态语言的原生开发和使用动态语言的前端开发在开发理念上有一些不一样的地方。不同领域的开发人员确实有不同的习惯。
希望这篇简单的文章能够帮助一些转到原生开发的开发人员，我就很满足了。