Srouce Code是最好的文件

軟體開發過程當中，需要不少文件作為溝通的媒介，例如需求書、系統分析書、系統設計書。在撰寫這些文件，除了文件的內容本身之外，還有其他兩種用途。第一是企業開發流程的產出。所謂凡走過必留下痕跡，做了什麼事，需要讓上級、後人知道你作了什麼事。基本上我不太喜歡用這種理由來撰寫文件，但不可否認，很多時候這是無法避免的。這種特點，在proposal中特別顯著。你會在proposal中看到明明是描述相同的東西，卻分散在不同的章節；或是明明可以用較少的字數來表現相同意思，卻一定要使用一堆文字來佔篇幅。

你的專業造成了什麼結果？

其實以文字來說，文字的詞意，很多時候，是無法表達出我們的意思。以「專業」這個詞來說，至少就有兩種意思。

一種是是名詞。他用來描述一個行業，很少人進入或是當進入這個行業時，需要很高的學習成本。
另一種是指你做一件事情做得很好。如果是以掃地來說，通常不會形容「專業」來形容掃地這件事；但如果掃地掃得很快、掃得很乾淨，這是專業。

我們現在來說第二種專業。

掃地這件事，家庭主婦跟清潔人員都會做。清潔人員與一般的家庭主掃的差別在於，專業的人或許平常就會去思考如何掃得更快、也或許會去練身體(我猜的)，不管做了什麼其他相關的事，但最終的目的，是要讓自己掃得更快、掃得更乾淨。By the way，如果定位是可以掃更多的地方，那所做的事情就又不同了。不過我需要先做一個澄清：我並不是說家庭主婦掃地掃得不好，只是如果是家庭主婦的話，應該還要著重在其他的地方；掃地只是其中的一小塊。不管如何，先暫停一下，來談談我最近在看的一部漫畫。

保留系統的彈性

設計系統時，預留彈性是很好的事。但需要注意，應該預留完整的彈性。

假設說我們今天開發的是一個POS系統。在開發的時候，我們針對POS產品類別，保留了一個彈性：「可以很輕意的增加產品類別」。所以未來我們可以很簡單的新增一個產品類別。不過這裡有一個地方要注意。

這裡有一個前提假設： 「每個產品類別，其他的流程是一樣的」。如果接下來一些銷售流程不儘相同，或是相關的擴充彈性沒有一起保留下來，倒不如在未來真的增加產品類別時，再一併增加，以免在目前的架構下，多了許多無意義或是令人困惑的程式碼。

其實不只是這個假設；你需要brain storm看看是否還有其他隱含假設。這些隱含假設來自於每個人不同的經驗。當然，需要保留多少彈性，這永遠是一個tradeoff 的問題。你需要考慮時間成本、研發人力、系統複雜度blabla。需要保留什麼樣的彈性這是一個經驗的問題。像上面所舉的「增加產品類別」，需要看系統中，所謂的「類別」是怎麼定義法。舉例來說，書店增加一類書是很容易的，但是增加書以外的產品類別比方說滑鼠，可能就沒那麼隨隨便便可以增加(雖然說最近有越來越多的書局開始兼賣滑鼠是怎樣…？)，因此像這類的彈性，如果在成本、人力都很吃緊的情況下，可以選擇性放棄這樣的彈性。