编译时保证-减少崩溃和不一致的行为
在运行你的App之前，你能做的事情去保证更多的事情-在运行时。首先你想编译我们的app或者一段代码传输它到代码，CPU或者一个事实上的设备能中断和运行，这是一个编译阶段；下一个是链接；它使用你刚刚编译的代码，用所有的框架和包和它相连进入一个单一的app容器，或者仅仅一个二进制，下一块便是运行。用户能运行我们的App。否则我们能在我们的手机或者电脑上运行我们的App，因此一切都是如此美好，尽管事实上我们得到了一个崩溃，大量的时间内我们不得而知。
App崩溃通常提供了一些疯狂的不一致的行为。这是它崩溃的最终原因。或者我们期望一些事，但是我们得到了另外的东西，我们得到一个栈扫描，我们通过了崩溃报告，这不是最有希望的flow，为什么会发生这些事呢？它发生仅仅因为一个简单的原因，因为我们是人类，真正的解决方案就是测试一切事情。我们通常测试，或者我们应该测试，我们应该写测试永猎，这里有不同的测试类型，例如单元测试，简单的，或者将你的App甩给用户-beta测试。如果我们看一看测试的金字塔，我们确信这个家伙和这个表太相似了。证明这里事实上缺了一块，或者，它是十分明显的。它是编译器。编译器是在创建和运行App时候是第一步，它是最好的一步，或者你认为它是最好的一步，因为它提供了更多的方式去保证，它比单元测试保证的要多的多，它可能提供了更多保证-关于你的App在客户端上如何运行，最重要的是编译器不是人类。它很聪明。
编译器有很多特性，但是我们没有，例如语法检查或类型检查，先进的特性像控制流和语法分析，它们能提供保证。通常，它提供了二种方式去保证你的App如何运行。第一个是编译器错误，它检查你的App语法，无论你用swift或者oc要讲得通。另外一种方式就是它检查你的真实意图。如果你正在写一个函数，你正在调用那个函数，但是它被界定了，它阐述了一个编译时错误，因此另外一块便是编译器警告；这可能没有错误，以至于你的App仍然能编译。但是它们让编译器告诉你关于潜在的问题，但是他或许不是最好的意图。因此去容纳这些的所有，并且在你的App内使用它。我们能做一些事例如趋向编译器的开发。
这真的不是一个事情，但是它通常是规则的集合-你能写swift代码去提供更多的保证-关于你的App在编译时如何运行。因此第一个地方便是早早就失败，或者经常fail。扔异常和可选的是最好的朋友，如果那里有一个微不足道的可能-这个事情或许做一些其他事情，或者周六有一个可能-这里在这个事件中可能有一个错误，使用ow去提供更多的上下文，或者使用可选值去返回nil。另外一部分，事实上比趋于编译器开发耗费更多；但是这就是，从不相信输出，如果我们关联它到swift， 我们有一个明显的强制解包或者可选值；第一个是十分糟糕的；因为你试图去找借口确信，你的代码从不返回nil，但是我们是人就不可能避免这样的错误；因此我们事实上应该使用可选值，而非显式强制解包，因为我们仅仅那样使用，当跑到那行代码的时候，如果返回nil则直接崩溃；
另外一部分，我们真的喜欢保护一切事情，使用guard，if，switch和where去保证一切事情，这样就会得到更多的保证；我们能以这样的方式去构建我们的代码，这样我们能得到更多的保证；事实上这样的例子很多，向常量和变量，如果你能使用常量去替代变量的话，请那样做；变量是十分糟糕的代码，因为如果后续你更改了代码，半年后你再看工程的时候，你试图计算一些事，它在这里不是最好的意图；它让我们达到了另外的一个点-被明确，最明显的方式就是和使用final一样使用public ，private；
如果你不想让你的类,再或者你写的,不是可扩展的,这不是你打算写这篇文章的时候,使用最后一个。如果你不确定一个属性,它应该是公共或私人,是否使用私人因为你真的不需要使用它。最后一个在这个巨大的列表;预防/文档。我们总是想阻止不支持我们的代码的行为,而不是记录。第一个原因,我告诉你,因为我们是人类,我们通常不会读。这是所有伟大的。它如何在实践中应用?我这里是一个小例子。我想让一个类,这是一个请求,我想要初始化一个字符串,它表示我的URL以及我要使用一些网络库。因此,我需要使用一个NSURLRequest,或在这种情况下,一个NSMutableURLRequest,然后我要添加一些授权,然后我要完成我的请求。
因为我真的需要我的请求的执行功能,我会将其解压缩到一个变量上。然后一些地方,实际上我要使用这个类。所以这一切看起来好可爱,但实际上如果我改变URL从适当的规范这样的URL,以TM吗?TM是重要的。我会崩溃,通常发生的是,“嘿,我只是写了这可怕的代码和它的工作原理,我可以推断它”,“它与通用网址,我不知道发生了什么事”,所以你进入这一模式。这里到底发生了什么,你可能已经注意到,我用一个隐式打开可选在这里,这是一个单个的字符。和可选的让我的代码崩溃,所以现在我知道问题。因此,我可以安排。通常解决诸如隐式地打开可选,以及保护我的代码,从崩溃保护我的代码,我可以使用一个将注释在init函数。实际上也迫使我重组我的代码,所以我从错误捕捉中获益。您也可以使用可选在这里,如果你没有一个精确的错误提供,并提供一些到底发生了什么,但是在这个例子中,我们可以看到如何通过构建和添加几行代码,编译器让我们编写代码的方式,我们可以更多的理由。另一个例子从同一段代码。如果我们改变这个请求吗?我们不会崩溃,但是我们不能原因在运行时发生了什么。它发生的原因是由于一个事实:我们先写一个var,不是让我们代码表达不是我们的意图。所以让var改变,相同的代码会产生编译错误会告诉你,“嘿,这不是你的意图。你是打算做别的东西,所以你不能突变那边的请求。”
另一个,另一种方法打破这种简单的变异中的URL请求。只使用一个不同的URL。我们不知道会发生什么在运行时。我们想要提供一种方法来保证这不会发生在编译的时候,所以不要这样做,我们会是我们班和使用这个类的分割成单独的斯威夫特文件,标注了我们的请求变量请求类和私有的。这是一个重要的发现这些分离成独立的文件,因为私人注释是私人相同的源文件,而不是同一个班。现在我们把我们的代码,我们提供了更多的意图。我们上市,我们使用的是私有的,因此这将产生编译错误,我们有更多的保证运行时编译时。如果我们回到这些东西的列表,你可以看到如果你把斯威夫特注释从他们所有人,他们可以是很模糊的东西。关于所有这些可怕的部分是,他们可以是任何你想要的。这里的重点是你应该提供更多的保证和你应该结构代码,你可以在编译时提供更多的保障。否则,你会遇到的生产问题。你会陷入崩溃在App Store导致一颗星评论,导致销量不佳,导致所有不好的事情。但是如果我们使用一组这些事情,如果我们认为之前我们写代码或之后我们写代码并运行它第一次,我们回去清理一切——然后我们可以提供更多的编译时保证。实际上比这更对这些担保。有分析仪警告。铿锵声分析仪是惊人的。它可以检查您的代码以先进的方式,可以给你流,你可能没有想过,这都是自动的,不仅仅是超级容易xcodebuild测试,而且xcodebuild分析。也有编译器警告,重要的是抓住不要忽视警告。如果你有一个警告在您的项目,你有更少的担保。我看到项目与成千上万的警告和他们真的很难推断。但是如果你没有警告,你使用的编译器。你使用的分析器。
实是有很多没有被记录的叮当声的警告,他们都可以在fuckingclangwarnings.com。舞台,是的,我发誓我不能发誓在幻灯片。网站有26 + 21 + 234警告上市,它们都是不同种类的东西,这是唯一的号码。实际上有更多的警告只是不同类型相同的标志。但是使用他们所有人,说在objective - c中,我们需要做的就是进入我们的目标,改变构建设置,找到其它的警告标志,并添加Weverything。这将给叮当声知道的任何警告,给我们。如果你是一个迂腐的人尽可能多的人,你可以用Wpedantic,实际上是存在的。如果你使用这两个,你也可以禁用警告,如果你不认为他们是必要的,只需添加# pragma叮当声诊断和流行,而忽略警告通过案件。疯狂的一部分,这不是斯威夫特。这纯粹是在objective - c预处理程序因为没有迅速和苹果并不想做一个。但是如果你使用它们只是在objective - c中,或者你让所有的警告,它会给你更多的担保权利。这就是我。
Q1:我只是想添加什么你只是谈论,Xcode的设置更改错误警告,“将警告视为错误”,所以这样你真的不能编译项目中如果你有警告。
Answer：难使用,因为通常你编写代码的方式编译然后清理,然后消除警告。但是你不想阻止你编译时警告你只是在开发过程中。但是flag是有用的。
2:两件事,一个是你可以把它添加到他刚刚发布的构建,这是相当不错的,然后你可以调试。无论如何,关于那个感叹号和问号的问题。所以当我第一次开始迅速,我是在同一条船上,问号是可怕的,没有使用它们。但是我已经开始改变我的想法是,“实际上,有时也许车祸比用户的操作。“对吧?如果你是一个用户和你只是触及的东西,但是什么也没有发生,这可能实际上比东西更混乱的崩溃。就像,现代bug报告,像说,Crashlytics什么的,可能捕获,它可能会让你发现错误比如果它只是一个空操作更容易。所以我实际上,当我现在开发,我来回喜欢,”崩溃实际上会在这种情况下比任何操作吗?“我不知道,只是想如果你有任何见解,或你的想法是什么。
answer：你做一个很好的点,事实并非如此,但开始迅速2,我们扔给我们一种我们的代码结构。如果是零,然后把我们可以保护声明。所以我们可以为最终用户提供错误。因为用户花费的时间重新启动应用程序或如果他们甚至想崩溃后重启应用程序实际上是一个很多。如果你能给他们一个错误,“嘿,我只是点击URL和有一个意想不到的错误,我不知道发生了什么,”这可能是一个更好的选择,因为他们可能会采取一些不同的措施。不一样的行动,因为他们的目的。所以如果你使用可选的组合,不隐式地打开可选的只是可选的,和保护每一个可选的声明,您希望非nil,但是你想要扔,这是一个更好的代码,只是撞你的应用。
3，伟大的说话,这真是一个伟大的讨论,一个追随捎带托尼刚才说的是,你也可以使用断言来保证对您的代码不变性。这不是编译时,但至少这是。得到快速的反馈,early-fail经常失败,被显式隐式。你也可以在发布模式下做事情,你可以有一个客户断言处理程序,而不是崩溃你的应用,抛出一个警报,允许用户报告错误。其实东西Spotify应用程序在调试模式,我也认为对于开发人员在发布模式下。但我想问尼基塔的一个问题是,当你有更多这样的编译时合同和担保,以你的经验,如何影响你编写单元测试的方式,和你看的东西当你发现候选单元测试和做风险分析?
answer：你会写更少的测试。这是非常真实的。甚至在objective - c中,只需将nullability注释添加到您的标题,您不需要编写测试代码打破或让它把让它做什么,它可以断言的东西和你想要验证这些断言。你想确保你的代码不做一些疯狂的事情,当你通过NIL。实际上如果代码抛出和保安的事情,您可以测试更少的事情。
4，嗨。谢谢你的谈话。一件事一个团队我在处理,如何处理零传播和可选的传播。你显示的示例中,你总是试图保护它早期吗?因为,否则,你最后做一个objective - c风格的事情,你经常检查NIL一路堆栈,例如。所以,你是保护非常严格,防止随意传播,是个问题。
answer：它实际上取决于。所以在与请求的例子中,如果你返回可选零,有很多原因可以零或者我们无法分配——可以是零?可能不是在斯威夫特,但一般来说,是的。如果我们添加更多属性相同的初始化,我们可以返回NIL在两个场景。扔在零传播进一步的好处是,它给你一个明确的能力告诉发生了什么。因此,在本例中,您可以看出,“嘿,我的URL字符串是畸形的,我不能构建一个请求字符串。”
-摘自https://www.skilled.io/u/nikitalutsenko/compile-time-guaranteed