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 的線條位置，而邏輯有問題的程式卻留在上線的產品內。

讓人感嘆的是，這樣的狀況總是在每一輪產品開發流程中都不斷循環。