寫程序要悲觀一點

程序員的思路一種悲觀的思路，考慮問題的時候永遠考慮最壞的情況是什麼，最壞的時間是多少，因為總會有一些奇葩的 case，在一個犄角旮旯出現，他一定會砸到你不縝密的邏輯上。

今天在我身上發生的一件事情讓我再一次的堅信了這一點：永遠不要把一個未定義的行為往好的方向猜測，而要把它當成最壞情況處理。

事情的起因是這樣的，有個 app 裡面有讀取 iOS 系統日曆的功能，當然功能非常的簡單，就是用了 EventKit 的 EKEvent，由於我只需要處理事件的標題，所以我只拿了 title，我大概就是遍歷一個 NSArray<EKEvent *> 把它的 title 添加到一個 NSArray<NSString *> 裡面。

這個程序一直沒有出過什麼問題，我自己也試過，你在 iOS 系統日曆裡面添加事件的時候，是根本不可能新建一個沒有標題的事件的，即便真的沒有標題，系統也會給你一個「新建事件」這樣的標題。所以我就認為這個地方應該沒太可能會出現 nil 吧，所以添加的時候就沒做任何判斷。

但我萬萬沒想到今天有用戶跟我反饋他用這個日曆一直崩潰，最後定位到還是這裡，原因是，被郵件同步的日曆事件，有可能出現標題是空的情況。

我不知道為什麼 iOS 唯獨沒有把這種情況給限制掉，我產生了一個低級的 bug，然而就是這麼簡單的一個問題就把我樂觀的猜測給幹掉了。

如果不想想最壞的情況是什麼，那到最後這筆賬是一定會償還的。

- EOF -