定義程式接腳在系統開發是十分重要的，雖然要定義的清楚有一定難度，不過一旦定出來，後續維護上的問題就會變得很單純，因為我再也不需要考慮誰呼叫我，維護時只要小心不要隨意變更接腳就好，若要變動時，一樣需要遵循前期設計的精神，確實訪談完多數的需求再開始動手修正。
前天在跟member討論程式問題時，發現一個很有趣的問題，問題是這樣的：
狀況：有ABCD四支程式，這四支程式彼此之間是有關聯性的，舉個例子來說，
A是報價清單、B是銷售商機、C是庫存異動、D是業務工作記錄，為了使用上的方便，系統架構是允許ABCD互相呼叫的，B可呼叫ACD、D可呼叫AB、A可呼叫BC...而程式間的關聯，除了流程上的關聯外，還有權限跟資料上的關聯性，乍看之下，真的挺複雜....光看看下圖，確實就足夠複雜了....
我問：那如果我今天要再加一支程式叫E，那我要怎麼開始動手改程式？
member說：那就要看它要呼叫哪支程式，哪支就要改囉。
我又問：那如果今天ABC要呼叫E，那誰要改？
member說：可能都要改吧。
我最後問：那我想問，為什麼今天每多一支程式，舊有的程式就都要改？
問到最後才知道，原來這是前人設計的關係，假設A-->B，他的寫法是在B中定義是誰呼叫它(QueryString中)，然後決定要做些什麼，所以每多一支程式呼叫，它就要改一次，否則會沒有效果，但程式修改總有風險，你如何保證這次加進來的功能不會影響到CD兩支程式對B的呼叫呢？
最後我給了他們一個結論，不管是ABC還是D，設計時應該都直接定出準備接哪些參數(或稱界面，不是C#的interface)，有人呼叫你時就要依循這個規範來傳遞參數，以下圖來說，D在設計時先定義出只接兩個參數，參數一：Mode代表的是D被呼叫時要進入什麼模式、參數二：Name代表的是Key值。
已A-->D為例，就是進入編輯模式，而編輯的資料是Name=Jimmy這筆資料、C-->D代表的是進入查詢模式，而查出的資料是gipi這筆資料…
定義程式接腳在系統開發是十分重要的，雖然要定義的清楚有一定難度，不過一旦定出來，後續維護上的問題就會變得很單純，因為我再也不需要考慮誰呼叫我，維護時只要小心不要隨意變更接腳就好，若要變動時，一樣需要遵循前期設計的精神，確實訪談完多數的需求再開始動手修正。
當然了，以上的設計模式我們也可以設計的很靈活，不需要時常修改每一支程式，我們可透過一個class在每支程式初始時將參數讀進來，並開始設定程式屬性，如此一來我們就把彈性設計的功能從每一支程式中搬到單一class中，維護上就更簡便啦，當然了，維護class的人需要足夠的經驗，避免改一個bug出現另一個bug。
其實程式的接腳定義在每種系統開發維護上都很重要，並不只限於此種狀況，應用的好，對系統的維護絕對是大大的加分了。
 |
游舒帆 (gipi) 探索原力Co-founder，曾任TutorABC協理與鼎新電腦總監，並曾獲選兩屆微軟最有價值專家 ( MVP )，離開職場後創辦探索原力，致力於協助青少年培養面對未來的能力。認為教育與組織育才其實息息相關，都是在為未來儲備能量，2018年起成立為期一年的專題課程《職涯躍升的關鍵24堂課》，為培養台灣未來的領袖而努力。 |
