模組化設定值的開放與否

有一次和同事討論程式的作法，發現兩個人對於「模組化」程式的開發有滿大的不同。我認為應該多使用預設值，只公開必要、儘量少的設定值。而同事則認為應該讓參數有多種的變化性，這樣開發程式比較不會因為某些沒有被參數含蓋的變化功能，導致得回頭的查看、修改模組程式。

討論到最後，並沒有達到完全一致的共識，因為彼此提出的論點和舉的例子都無法說服對方。當然尊重別人的程式撰寫風格的前提下，都沒有強迫對方要照著自己的方式走的意思。最後我採用較為折衷的方式來開發，作為這次討論的結束。
回到家又再思考了一遍這個問題，回憶一下從前是如何作下「儘可能少開放」方針的原因。很清楚的知道並不只是單純的跟著「封裝原則」的建議。而是有其它理由支持這個論調。還好，最後終於讓我回想起來了⋯

人是不可信，相同的程式大多數的狀況能跑出一樣的結果

並不是指互相欺騙的那種不可信，而是人的「失手」機率是遠高於一般想像，從常見的拼字錯誤到帶入全型空白，少了幾個分號、結尾的大括號都是幾乎能在每天的工作中發生，就別說在剛上班、午休後生理狀況不佳（想睡）的時候，有時候都不知道自己在寫些什麼東西的時候，產出的程式要 100% 沒有 bug，是很不容易的。

因此，就不應該去期望當需要編寫大量設定檔案才能讓人程式運作，但合作的對象是幾個月前開發出的來的模組。這個時間足夠讓人把上次使用時犯過的錯都忘掉，而結果則是會犯一些常常出現的錯，或是出現一些在當下沒有查出來的問題。既然人是不可信的，那麼應該多使用一些能自動判斷、檢查的程式，能夠減少需要手動操作、調整的部分。這樣才能減少程式出錯的次數。

作現在需要的，不作過度設計

網路架構在學理上可以分為七層，但是被實際上只要實作五層就夠用了。網路 HTTP 的方法有八種，但是被最常使用的只有 GET 和 POST ，其它則是不常甚至很少被用到。這些都是屬於過度設計的例子。然而人家那是許多人一起討論，最後設計出來的規格。在一般工作上的程式開發，不會有那麼多人，也不會有那麼多時間實作出每個「未來可能用到」的規格。與其冒著因為需求變化，而被遺棄的設計，不如一開始只作現在就需要的功能。其它的，就是靠重構來整理程式，再將功能加入。

單元測試和重構的技巧就是因應這樣子的需求產生的，無論再好的規劃，總是可能出現超出，不甚相同於既有規劃的需求，那麼就不再嘗試在一開始捕捉到所有的需求，而是讓程式能夠面對一次次修改後，仍能保持程式的穩定與一定程度的可讀性。畢竟「變動」才是程式發展的不變真理。

結言

以上的論點仍不足說服我那位同事，不是理論的問題。而是以既有的開發方式並沒有重構與單元測試，所以每一次的修改都有可能引入新的 bug。在一開始多試幾種可能遇到的狀況，確保只改設定不改程式能夠應付更多一些不同的需求，相對而言就表示得去更動模組程式的機會就變少。這樣子的想法其實能夠被理解，也需要自己在重構的程式有更多的心得，作出一點成績之後，才比較能夠說服他吧！