議題
「單一職責」、「開放封閉」、「依賴注入」、… 這些寫程式的原則，因為面試找工作時都會考，所以大家都倒背如流，可是為什麼進到公司後，把前人的「鉅作」打開來，看到的往往不是那麼一回事；更有甚者，當我們想要幫忙把原有的程式改寫成更好的樣貌時，總是得到「會動的程式不要改」的回答？
我們用一個日常生活中常見的服務：「停車場計費器」，來看看在功能保持正確的情況下，有意識地善用物件導向設計原則，與沒有善用的，在閱讀上的表現力，與當需求有變時的改動難易度，有什麼區別。
講者
Kuma Syu
Kuma 最討厭的就是 coding 了。
你沒聽錯，身為RD，只要能滿足品質與時程，他堅持能夠少寫 code 就少寫 code。
他也很懶，能夠讓機器做的事就不自己做。
他討厭浪費，也懶得算計，就傻傻地在組織內努力推動各種流程改善、人員教育，與軟體工程實踐。
「崇尚敏捷精神，熱愛軟體工程」— 你可以這麼形容他。