1.流程麻煩清楚
2.讓別人一看就知道你在幹什麼
3.初期程式請勿封裝過頭
4.初期程式請勿封裝過頭
5.初期程式請勿封裝過頭

有件事情說了三次，為什麼，很重要

開發階段為什麼叫開發階段，就是因為我們可能還會按照需求調整
可能還會中途插入一些預想外的資料需要處理，也可能其中有一半要全部打掉因為不用了

你把程式全部像OOP概念一樣封起來，就程式精神沒錯，但就合作開發角度你TMD根本在搗亂
首先這種東西沒有辦法很快讀懂，浪費所有人初期確認你程式運行的方式，撰寫架構等等

再來，如果真的慘劇發生，"這一大半現在說不需要了，我們另一半資料應該用另一個資料庫，處理方法也要變更"
封裝過頭的下場就是你會抱怨怎麼這樣我超不方便改我程式的
因為近乎，不對，是整個要重寫

其次，遇到封裝無法處理(例如需要多考慮一個參數)，結果又要說是程式限制導致，結果其他人要配合你解決嗎?
不可能的，你還是得大費周章調整自己已經封裝好的程式，因為這是你的問題
且還要額外多測試很多東西，因為你不能保證我只調整這邊，其他一律不會出錯

你當然也是可以不測試，但往後如果出錯就是被裱到更慘，因為通常已經是很多人開始使用，然後你也說這程式沒有問題的狀況

最後，最現實的
"我現在東西參照到你的，東西也完全符合格式，但就是出錯了"
結果一查，一開始沒有全面考量就封起來，結果要改掉這個例外狀況，我還是要拆掉重新寫在重新封裝

你覺得這樣回應有用嗎?
"這是這個函數的限制，你要呼叫這個函數，要自己避免我程式不支援的地方"

拜託，不用想就知道會引起公憤的行為，請三思而後行

補充一個更慘的事情，那就是因為別人看你的程式看不太懂，以為你封起來的東西並不支援需求，所以又另外寫一個，結果到時候還要解釋說
"如果你當初有多花幾小時研讀我程式的話，就會發現我寫的東西已經滿足你需求了，所以你這些並不需要寫"
即使你寫的東西再完美，都會讓很多人不爽，因為你寫的程式很難溝通


然而，OOP概念沒用嗎?封裝沒用嗎?考慮最佳效率沒用嗎?

錯，當然有用，非常有用

但是這種東西有用是，大家合作的部分都已經確定，整體架構趨於穩定，需求也穩定近期不會改版，或基本要封測上線
那我們就可以考慮哪邊可以開始整合，優化，提高效率

這時候當你提出，"我覺得這地方要進一步整合封裝起來，可以提高效率"
那，大家也可以快速地確認有沒有影響到自己的部分，有也可以馬上提出來
再者，你這時間點想幹這種事情，除非提案荒唐，否則獲得雙手贊成的機率應該非常高

因為你是針對穩定下來的東西想進一步優化他，沒有反對的理由

因為你接下來要封裝的東西，別人同樣呼叫你寫的程式，方法必定更簡單，或者根本沒有必要改呼叫方法

總而言之
重構，整合，封裝，絕非在最早的開發階段應該做到徹底完美的事情
因為你做了就等同在找合作夥伴麻煩，以及找自己麻煩

請先有初版程式，讓大家看懂你整體流程到底在幹什麼(當然還是要整理，只是別過頭，詳見文尾說明)

開發階段是討論程式架構與合作方式，分工方式的時間
而不是爭論哪種寫法效能比較高的時間

隨著需求改變，你所謂正確率最高的寫法有可能在當下直接變拖油瓶
最簡單的狀況就是因為絕對不會錯又大量狂跑一堆寫過頭的防錯機制

又或者你是為了因應未來"自己認定的可能修改方式"而特化了部分封裝，然而這永遠沒發生
結果發生的都是"自己認定以外的修改需求"，結果感覺別人都在整自己，然而這不是從一開始想法就本末倒置了嗎?

所以，請務必清楚團隊合作開發一開始該做什麼

以上

說明:
1.文中所提及之基本易懂流程絕非單一函數CALL到底叫易懂，絕非SQL WHERE JOIN JOIN WHERE SELECT到底就叫易讀，這種也並非效能問題，而是會"直接死的問題"
2.效能問題大概像是"雙引號還是單引號效率高一點"，"我先用function整理起來，呼叫時間可以縮短0.01ms，記憶體可能減少1bit"的問題