寫程式的好習慣

一開始寫程式，學 Library、學 Object Oriented 物件導向 ……

開始寫 class、event、abstruct、interface ……

接著是私下補充過去沒有了解到的高緊密低耦合之類的，然後又是 Design Patterns、Dependency Injection ……

作為一個非資訊科系出身的人，現在回想，很多路都是在不知不覺中踩過去的

只是到了職場，公司希望可以寫出 Library，常常被念為什麼當初設計沒想到之類，就開始會想很多。

想得太多、程式過於複雜，卻變成了另一種客製化。

於是回頭在網路上找到這一篇習慣，小菜鳥僅擷取了自己所需要隨時複習的要點。

1. 不要太多的預設計 (Big Design Up Front)

　　在開發程式時，僅需要符合當下的需求就好。不要預想未來「可能」的需求為何？效能問題？應用程式架構怎樣分才能符合「未來」的需求。

　　要知道未來不見得發生這些預想的事。做這些預設計不但浪費時間，並可能造成未來程式難以重構，成本自然增加不少。

　　example: 筆者曾將某網站設計成三層式(3-tier)的架構，其中應用程式層(application tier)使用了 remoting的分散式架構。當時想：未來系統一定拆開到不同的伺服器，以符合高擴展性的需求，這些設計未來一定會用到。結果，開發兩年後，不但沒有發生，更糟的是網站還交給另給一組人維護。因為做了多餘的設計，而這個設計已過了5年還沒發生當時預想的狀況，新進人員都會問當時為何這樣設計？造成交接、維護上的困擾。

2. 奧坎剃刀原則 （Occam’s razor）

Occam’s razor 說明了下面的原則：

　　假如一個問題有很多種解決辦法，選最簡單的那個。

造成系統複雜的原因，其實還可再細分成兩種類型：本質複雜及意外複雜。

　　(1). 本質複雜(essential complexity)

　　本質上的複雜，是該問題本質上就比較複雜，我們應該採取科學上的方法讓它變簡單。常見科學方法，再分成兩種。

　　一個是將大而複雜的問題，拆解成多個簡單的小問題，進而一個個解決並得到整體行為。例如微積分，有限元素法。專案管理中的WBS 也是採用了這類的方法。這類方法有個缺點：小問題的總體行為等同於原大問題的行為嗎？

　　另一種是承認該大而複雜的問題難以拆解成小而簡單的問題。因此使用統計學的方法來統計大而複雜問題的行為。缺點是相當費時秏力，方法不正確，有時反而會得到相反的結果。

　　(2). 意外複雜(accidental complexity)

　　問題本質性的複雜外，有時候(也是常常)是我們採取的解決方法錯了，反而使得問題更複雜，稱為意外複雜。例如上述example所犯的預設計問題。此時，正確的方法則是將這些意外複雜因素移除掉。

　　本質複雜與意外複雜有時難以分辨，相當依賴設計人員的經驗。

　　經典常見的意外複雜原因，如下:

• 我們實作了自己的 Web/Persistence/Messaging/Caching 的framework, 因為找不到比較好用的!
• 買整個工具包，即使我們只用到10%。
• 為了效能，我們將所有的商業邏輯寫到 Stored procedure。(常見吧！)
• 我們不寫單元測試，因為我們已經花了很多時間在 debug。(真是天才)

3. 學新的技術

　　新技術往往是用來解決以前難以解決的問題，進而使用更簡單的方式來解決。

　　雖然使用新技術解決問題往往更加容易，但並非一定要採用這些新技術才能解決問題。因此許多「上班族」不願花時間學習，只願使用已經習慣的舊技術來解決。這樣的心態，稱為舒適區(Comfort zone)。

4. 獨立思考

　　並非所有新技術都能存活下來，故並非所有新技術都值得學習。那要如何分辨呢？

　　相同的道理，網路上的訊息已經多到「知識爆炸」也難以形容，但我們還是要學習/吸取新知。那要學習哪些知識呢？使用什麼方式學習較有效率呢？

　　答案就是獨立思考，不要隨廣告/行銷等手法矇騙。要常常想這樣做，比較快嗎？比較有效率嗎？沒有其他方法了嗎？沒有其他觀點了嗎？

Reference:

http://charlesbc.blogspot.com/2010/06/blog-post_29.html