"過度"的不是設計，而是對未來的不確定性
今天早上不好意思寄了重複的信。因為服務突然沒有回應了，我以為它沒收到我的設定。 所以今天還是有新內容的。😉
Overengineering can kill your product - Mind the Product
「過度設計(Overengineering)」 是一個在軟體開發中，蠻少人談到，但實際上很常發生的事。尤其現在我自己已經不是開發人員了，所以也已經不敢確定我的團隊內有沒有這種問題。如果有我不會太厲害，因為我自己以前也常想這問題，是一個很容易想到出神的問題。
Overengineering (or over-engineering, or over-kill) is the act of designing a product or providing a solution to a problem in an overly complicated manner, where a simpler solution can be demonstrated to exist with the same efficiency and effectiveness as that of the original design.
雖然跟Wiki的定義不同，不過這解釋十分接近。也就是說，明明這個問題有更簡單直白的寫法，我們卻用更複雜的解法來處理。作者引用Paweł Głogowski的話來解釋過度設計，是讓我蠻耳目一新的：
Code or design that solves problems you don’t have.
定義雖然很簡單，但問題沒那麼簡單。軟體人員腦子裡都在想什麼？嫌時間太多沒事做？還是嫌問題太簡單太好做？
文中有提到，有些開發者剛學到一些 design pattern ，覺得自己的軟體功力增加了不少，是個”專業人士”了。因此會在眼前看到的問題上，嘗試用”專業”的方法來解決問題，這就造成了過度設計。是的，我們會看到這種過度設計，會覺得這些「年輕人」就是太嫩了，才會這樣亂套一通。可我確實見過一些開發者，他們不是亂套的。design pattern 的源碼寫起來又沒有比較少，而且他們很確定這個 design pattern 做什麼用，也清楚自己要解決什麼問題。很多時候，這問題真不是「開發者太嫩了」這麼簡單的答案就可以帶過，實務經驗上，真的有更無奈的理由，讓整個源碼趨向這個方向去發展。
他們要面臨的不是實作的複雜，而是未知的複雜。
真的認真詢問這些開發者，他們一定會異口同聲的說，現在的設計，是為了將來的擴充性；現在的準備，是為了將來的穩定性；現在的處理，是為了將來的移植性…也就是說，他們過度設計的根本理由，是過度為未知的未來準備。軟體工程的設計，本質上確實就是要為了未來而設計。可擴充性，穩定性，移植性什麼的，這些都是正確的觀念及事實。只是真正的問題是在「未知」的程度太過模糊的狀況下，「準備」的程度就要儘可能的完整。
做過規格模糊的產品的開發者，尤其是那些資歷夠老的，一定都有說不完的慘痛經歷。老闆口中的一句”小改”，往往就成為他們挑燈夜戰的趕工；客戶的”感覺不對”，常常就得讓他們犧牲假日來滿足需求。大家當然知道不要過度設計，可那個「度」在哪裡才是真正的問題。如果規格不夠清楚，用戶調查不過徹底，開發者為了不要再浪費生命加班，只好想辦法儘可能讓「設計」來 cover 那些問題。有時，我們會覺得軟體工程很神奇，感覺很複雜的規格，在正確的設計下可以輕鬆的滿足。可我們很容易忘記的是，軟體人員其實很貴，他們的”魔法”都是年輕的肉體配咖啡施展而來的。
文末提了一些避免工程師過度設計的方法，其中一項是讓工程師參與用戶日常的生活及使用產品的場景。這是好方法，也很正確。別看工程師好像只懂得怎麼跟電腦溝通，其實工程師的觀察力並不比業務人員差，尤其是人類怎麼決策這種事情。「用戶調查」這種事，或許是產品經理的職責，但其實軟體開發者的「決策觀察」能力，是值得產品經理借重利用的。