我想是可以分享的時候了～
2019 年我進入一家 2009 年成立的公司，是以 Web 起家，2012 年開始研發 App，據傳當時僅有一為 App 工程師，同時要寫 iOS 和 Android，這讓聽到的我感到不可思議，一方面佩服該工程師偉哉之處，一方面擔心若該工程師發生意外，有人能夠接手處理嗎？🤔
我接手 iOS 專案時，已經不再是由一人同時研發兩平台，所以我能專注在我熱愛的平台 iOS，首先評估當前專案狀況。
iOS App 歷代開發者接手時間
- 第四人：2019/09 就是我～🙃
- 第三人：2017/04
- 第二人：2014/03
- 第一人：2012/07
接手別人寫的專案有好處嗎？有～但壞處也不少喔！
好處是不必再想架構，基本上照著前人已制定好的架構繼續做即可。
若有新的功能，則視情況發展自己的邏輯架構。
壞處則是首先要熟悉前人的程式邏輯，我必須瞻前顧後，確定不會影響舊有功能為前提，才能繼續開發新的功能。
由於 App 已有久遠歷史，專案有數量眾多檔案與複雜邏輯，每次編譯會花費 1-5 分鐘不等（端視筆電規格與有無快取）。
有可能踩到前人不小心埋的坑，導致增修功能後，產生不預期的問題，甚至可能難以除錯。
我目前已離開此專案，來歸納一下整個產品繼續發展下去，未來會有哪些挑戰與困難。
- App 作品檔案沒有與 Web 同步
因而無法任意切換手機與電腦來製作 - Web 與 App 功能差異多
App 作品可相容 Web 作品，但反過來則否 - App 版本沒有強制更新
舊版本問題依然存在，導致後續處理作品需要修正 - API 開發欠缺工程師
須由其他平台工程師臨時開發 - App 資源來源：Built-in (Local) 與 API (Remote)
導致 App 新舊版本難以維護 - App 開發需分新舊版本實作功能流程
需要撰寫各種條件分開流程 - App 是末端，一出現問題就會找 App，尤其用戶數 iOS 比 Android 多
使得某些不是我造成的問題，都會預設歸咎於我 - API 回傳格式：JSON 與 XML
由於 App 是從 2012 年首次開發，API 依舊沿用 Web 使用的 API 開發模式
此外，在我離開此專案前，我開發遇到瓶頸，詳情可見：升級 MacBook Pro。
總之，很高興，能參與到歷史如此悠久的專案，代表此產品一直都有市場需求。我也觀察到市面上類似的 App 產品，都沒有像我們這個專案來的優異。以功能面來看，後進模仿者很難超越，若是以強調簡單操作，加上行銷才有機會勝出。
起初，我們總是在一開始對新的事物懷抱著美麗的憧憬，曾經想要參與讓此事物變得更加美好。然而，努力一段時間後，發覺能夠改善的部分可能只有 60%-80%，然後就很難再往上推進。導致無法獲得足夠的成就感，繼續支持當初懷抱的期待。
最後，工作成果開始崩解，從 100% 降至 90%，已經無法滿足公司的期望，那麼就是該選擇離開的時候。😉
逍遙文工作室 
隨意留個言吧：）～