為什麼要思考長久經營之策？

程式設計師，其實都不喜歡接手別人開發過的專案，寧可重寫相同的功能。
因為，在前廠商沒有留下註解或文件的情況下 ( 即使有留下，也未必是最新或正確的 )，與其想盡辦法弄清楚當初開發者的思路，不如自己重寫，可能還比較快。

雖然客戶不見得都有預算，再重新開發一次。
可是，絕對都有不滿意前廠商，想要更換的理由。

因此，耗費巨大心力，協助客戶改善原廠商所遺留下的問題之後。
我們總是想著，如何才能避免相同的情況再度發生。
就如同廣告標語一般：「為客戶建立可長可久的技術架構。」

「功能很簡單，這幾個項目都是固定的，以後絕不會改...」 每次開發時，多少都會聽到一兩次。
沒經驗的程式，會將這些「客戶保證」的固定項目，寫死在 code 中。
因此上線之後，若發生意料之外的狀況，光是修改這些固定項目，就足夠令人煩躁的了...

其實，這是一種莫非定律：
越簡單、越小的專案，越可能不小心成功，延伸成大專案。
越是擔保不會變更的項目，越可能不小心出現例外。

與其發生例外時，跟客戶拿會議記錄嘔氣...
還不如聽我建議，在一開始就採取較為彈性的策略：
各種「號稱不會修改的項目」，仍舊紀錄於資料庫欄位中。
各種「保證不會再新增的品項」，仍舊保留新增欄位，並以關聯表的形式，提高後續增修的可能性。
這並不代表需要額外撰寫相對應的修改程式，只是在建立資料表時，保留更多彈性。
一旦發生不可預期的例外時，只要修改欄位值，即可完成更新。
想要後續增補程式，用以擴大功能，也能簡單實現。

因此，真正有遠見的程式設計師深知：
「現在一點小小的投資，可能讓未來所有人都皆大歡喜。」

以樂高積木為例，只要以積木上圓形凸起的尺寸為依據，即使各家廠商分別製作各種不同的積木組件，就算新積木的形狀、大小、顏色各異，它一定能跟原來的樂高積木組合在一起。

所以，我們為客戶開發系統時，通常會優先設計 API，作為前後端程式串接的基準。
在內部開發階段時，不同的程式設計師都有相同的開發基準，就可以各自開發不同的單元，分工合作，提升效率。
與其他公司偕同開發時，我們也會將 API 預先完成，並提供完整的介接規格，確保雙方的合作默契。

同時，我們會提供一份 API 規格給客戶。如果未來承辦人更換了，或是我們沒有標得後續延伸案，接續的廠商 也能盡量在不改寫核心程式與資料庫的情況下，透過 API 製作新的功能。
如此公開透明的方式，讓客戶不會被既有廠商綁定，可自由選擇開發商，反而提高了信任感。
因此，確保了一個可長可久的技術架構，即使歷經多次的擴增，更替了多家系統開發商，最終仍能保持穩定的結構，不至於疊床架屋、難以駕馭。

「待人以誠，治事以敬。」
其實經過多次開發經驗可知，每次客戶提出規格變更時，一定有其理由，也有其難解之處。
此時，細聽客戶所遭遇的困擾格外重要，並且以技術專業給予最適當的建議；其實八成以上的客戶都會接受專業建議，使之合理化。
所以，即使經過多次調整，跟客戶之間的信任感，總是不變的。

同時，也須深知客戶「不可能雞蛋全放在同一個籃子」的道理，與其他開發商相互支應，各自於負責的系統分工合作，而非相互推諉，才是正道。

一個成功的平台開發案，往往需要經歷數年的經營，才會屢創佳績。
因此，堅持服務精神，不只為了客戶的成效，也營造未來數年良善的工作環境。
絕對是成熟企業的雙贏策略。