Crash Reports

身为软件工程师，在你的工作中（如果不计会议时间的话），其实你只有大约十分之一的时间真的在写程式，其余九成的时间，则是会花在测试、Debug 与修正问题上。而发觉已经写出来的程式里头有哪些问题，这件事情，其实可能写程式本身还要加倍困难。

我们平常要处理的bug，除了程式最后的逻辑是否符合产品规格之外，更要处理各种稀奇古怪原因而造成的crash。可以造成crash 的原因太多了：在array 或是dictionary 中插入nil 会crash、一边enumerate 一个mutable array 又一边改动他会造成crash、你从server 抓到一份资料以为是字串或数字​​但server 偏偏给你null 会造成crash，而以iOS 的设计，执行速度太慢、用了太多的内存也都会crash。

在开发过程中，我们可以有各种工具，像是debugger 等，可以检测软件中的问题，但是当我们把软件交付给QA 测试、以及上线之后，软体已经不在我们的环境，而是在用户的环境上执行，而用户在回报问题的时候，一定是不清不楚，我们不能够期待客服可以帮我们从用户身上收集问题的重现步骤。在QA 与用户的装置上发生crash 的时候，最可靠的，就只有当时产生的crash report。

所以iOS 工程师要具备搜集、阅读crash report 的能力，因为在绝大多数时候，crash report 是我们理解、修正问题的最重要线索，甚至是唯一的线索。

而其实，我们也不希望经常从用户的装置上收集crash report，因为我们并不希望在用户的装置上发生crash。

我们经常在讲什么要给用户好的使用体验，但是在台湾，所谓的使用体验设计似乎偏往一个奇怪的方向，变成只讲视觉上的体验，就算是一个音乐服务App，也只关心视觉设计，而用户听到怎样品质的声音却完全不管。甚至就连所谓视觉体验也都只讲怎样做出一个又一个看似美美的画面，每个画面之间有什么关系、流程是否合理也完全不管。可是，在讲用户体验的时候，我们先来问—什么是最差的使用体验？最差的使用体验就是crash。

在我们的工作中常常会遇到奇怪的事情：我们拿到一份残缺不全的Spec 就得开工，在莫名其妙的期限之前完成，而在要出货的时候，我们在做的并不是测试与修正，而是为了所谓的使用体验，所以在画面上调整一两个pixel 的线条位置，而逻辑有问题的程式却留在上线的产品内。

让人感叹的是，这样的状况总是在每一轮产品开发流程中都不断循环。