其實已經持續一段時間了，只是最近才開始面對。
一直以來Art都很喜歡推出看起來很厲害的UI，有很多PM＋其他team的朋友＋路人＋隔壁啊罵，看到其他對手，不管是競業還是異業，都會問一句：「我們可不可以改UI」。
以前在接案公司的時候，我甚至還會鼓勵Art PM設計一些希奇古怪的畫面讓我去實作，我以前都覺得刻那些奇怪的效果很好玩。現在也是。
參與過一些多人合作開發時間很長的案子以後才發現，一樣是加新功能or改UI，在一個只有10個頁面的案子中加跟在一個40個頁面的案子裡加，要花的時間是完全不能比的。（雖然聽起來很像是常識，不過真的是痛過才知道QQ）
以我最慘痛的經驗來說，當時負責的是要把一個tableView上面的item從大雜燴一個section變成分好幾個section分類，我當時接到的時候想說，「這個功能應該兩天就作完了吧，改不好今天下班前就可以做好」。
事實上我做了三個禮拜才把它完成，忽略了80%以上沒看到的data handler，幾乎是改寫了底層2 3000行code，而且後續還有很多沒想到的bug，全部解完加起來時間就差不多一個月了。唉，嚴重的時程規劃錯誤。
會發生這種問題，是因為我只看到UI要處理的問題，沒有想到data +api那邊要處理的問題，甚至沒想到兩邊都改變的時候會不會扯出更多問題。
一開始我在寫code的時候，都是用別人寫好的api module，MVC全部寫在一起，後來想到這樣很難reuse，才漸漸的把一些data + api hadler另外寫，有些壞習慣沒有清除乾淨，現在寫prototype的時候一直出現。
晚上看到facebook 最近出的paper，還有長久持續以來的希奇古怪UI 設計，像是Evernote、Yahoo Weather，來自UI的挑戰一定只會更多不會更少。
所以問題就變成：
怎麼樣讓每次改UI的時候不那麼痛苦
我也很想知道答案，這些是我大致想到的：
- UI 跟data handler要分得乾淨
- 用寫SDK的心情來寫data manager
- 盡量不要用storyboard，要用也不要在 storyboard上面疊床架構
有道是「過早最佳化是罪惡的淵藪」，第一招UI 跟data handler要分得乾淨是一直都知道但是一直沒作完整的，壞習慣再不清除乾淨以後一定會要人命。
所以要用寫SDK的心情來寫data manager，我心中一直有一個期望，有一天我可以把我負責app的SDK放出去，裡面只有connect跟disconnect兩個method，其他的UI層都不用管，只要呼叫跟釋放就可以用了，剩下的時間，可以讓想接我SDK的人自由發揮其他怪招式，要讓更多人用我SDK的前提一定是要寫得夠簡單。所以這點也是個自我期許。
剩下的是單論UI部分，刻UI是每個client從業人員一定會遇到的課題，不管是web、iOS、Android還是Windows，基本功一定是刻UI，就iOS來說，在創建一個UI的時候，有三種方式：用code寫、xib或storyboard。storyboard在頁面很少功能不多的時候是神兵利器，但是隨著案子慢慢變大，就會發現越來越多的功能需要用xib或code才做得到，再繼續用storyboard只是會越難維護而已，這個時間點因案子跟個人忍受度而異，不過最晚應該不會超過app裡有超過10個view controller才是。
之前在RayWenderlich上面的文章，爭論這三種作法的利弊。
storyboard 的強項是清楚顯示view controller之間的關係，至於view controller裡面的客製化，還是交給xib或直接用code寫吧。
