【譯】如何避免程序崩潰-8：基本架構

即使你覺得自己的app是無故障的，你也需要收集崩潰日志 —— 因為沒有什么是無故障的：只有 已知 的崩潰bug是可以避免的。

有一些做這類事情的服務，我嘗試過的還都不錯，所以我在這里就不做特別推薦了。

有幾點功能是它應該具備的：

1. 崩潰日志被收集的過程，不需要用戶手動查找它們再發送給你。它應該是自動化的（如果在OS X上，用戶可能會收到提示；而在iOS上沒人會希望被彈窗）。
2. 要有給崩潰日志分組的機制，你得到的應該是每一組的匯總，這樣你就能知道哪些經常出現，哪些不經常出現。
3. 要能夠給一組問題標記為已解決。

當然，僅僅收集崩潰日志是遠遠不夠的。你應該定期查看它們。（我每天早上查看崩潰日志。）

Bug跟蹤器

要有一個。

對于我私人的項目，我會綜合使用Lighthouse，OmniOutliner和紙筆 —— 當然你可以使用任何工具，只要你的崩潰記錄歸總到你的bug跟蹤器里面而不會遺失。

（Lighthouse是個不錯的bug跟蹤器。我喜歡用OmniOutliner來標記大的新功能或者完整的app，在那里我可以建立to do的事件樹。對于短周期的事情 —— 比如完成一個10步就可以完成的任務 —— 我喜歡用紙筆，因為依賴短期記憶很讓人疲倦，而紙筆不會干擾屏幕上的上下文環境。）

錯誤和警告

Xcode默認不會打開足夠的錯誤和警告。我強烈推薦 Peter Hosey的集合 。

關鍵是要移除你代碼中的 不確定性 。

就像我推薦的，我更進一步：我像對待錯誤一樣對待警告。是的，這就意味著，如果警告存在我甚至不能在本地debug —— 但是這條守則物有所值。它意味著無論何時，只要我的app在運行，就不存在任何警告。

Instruments

Instruments非常棒。查看你的app分配了多少的內存是個好主意，同時，查看內存泄漏也是非常重要的。

如果你的app崩潰了，使用Zombies工具是個好主意。你的問題可能和zombies并沒有關系，但是在懷疑的過程中，排除法是很值得使用的。