關於之前討論的「App程式的複雜度與所需的時程」，當下我沒想到好例子，用pchome app當例子也許能解釋，一樣功能都能用。改過之後，外觀比較好看、操作起來比較好用、用起來比較順暢。然後還是可能被質疑，功能大致上一樣，換個外觀、微調功能和執行的速度，「一下子」就可以弄好。

關於App UI改善:

這個外觀如果App只有一個頁面，當然簡單，但是如果App有N個頁面，每個頁面有M種狀態、K種資料，而且App還要讓使用者根據UX/UI設計師的想法，要在許多不同頁面之間切換(p.s. 請參考註1)。這個複雜度如果不是事先規劃好UI框架與reusable 的UI元件與層級(p.s. 請參考註2)，每一頁的不同狀態都要需要修改。的確可以硬改，但改完，今年就過了。

關於App運行速度、操作流暢的優化:

• 不熟悉程式語言、框架、library特性:
  導致實作出可以動，但是記憶體管理有問題、執行效率低落(p.s. response嚴重延遲)、增加運算流程的複雜度，導致難以維護(p.s. 互相dependency，改A壞B、改B壞C、改C壞A)。

• DB schema設計不良:
  要優化，不僅要重新了解完整的業務邏輯流程，來重新設計table及relationship (p.s. DB Model Sample請參考註3)。改完schema後，又要把存取DB的方法及與原先的dependency不同的方法重寫⋯⋯。 寫完等於把過去幾年累積下來的功能或workaround重新實作一遍，然後App已經開發了N年，所以現在要做到優化，等於把之前開發N年做的基礎建設全部重寫實現。然後UI與DB的溝通方式或方法，也要重新改寫。

• 軟體系統架構不良
  不熟軟體設計原則、物件導向原則，無法設計出良好的軟體系統架構，導致執行效率低落(p.s. response嚴重延遲)、增加運算流程的複雜度，導致難以維護(p.s. 互相dependency，改A壞B、改B壞C、改C壞A)。好的軟體系統架構甚至能夠從「結構上」去避免「記憶體管理」、「流程複雜度」、運算效率」等問題。(p.s. 藍牙服務架構圖請參考註4)

綜合上述，也許App本身用到的技術難度不高，但系統複雜度高，高到負責的工程師維護不了只能全部重寫。

註1: (App頁面切換流程)

註2:(Reusable components sample)

註3: (DB Model Sample)

註4: (Bluetooth Service architecture Sample)