物件導向筆記 (1)：寫程式和開發軟體，差在哪？
本文整理自物件導向分析與設計的課程影片與講義，是自己的上課筆記，非完整教學。
老師上課舉了一個例子，說到學校教的程式設計，大概是教你「蓋狗屋」，只要邏輯通了、功能跑出來就收工。但現實中你需要蓋的是 101 大樓
設計複雜度、困難程度、規模，完全不在同一個量級。
1. 軟體設計的老問題
軟體工程幾十年來一直在面對相同的問題：
- Software Reuse：程式碼好不好重複利用？
- Maintainability：維護起來容不容易？這是和物件導向關係最密切的一點。
- Software Quality：正確、一致、穩定？
- Software Evolution：軟體能不能隨著需求演進？
2. 開發軟體 vs. 寫程式
Table: 課堂作業和真實軟體的比較
| 課堂作業 | 真實軟體 | |
|---|---|---|
| User | 自己 / 助教 | 不特定使用者，用途多樣 |
| Specification | 固定題目 | 彈性、持續變化 |
| Quality | 跑過就好 | 正確、一致、穩定性都要求 |
還有最大的差異：Size does matter. 規模一大，所有問題都被放大。
3. 軟體的真實時間成本
在學校，我們寫完程式就交卷。但在業界，產品上線的那一刻，才是開始。
當你的軟體在市場上活下來，維護與擴充的工作會佔據整個開發成本的 2/3 到 3/4。
就如同「生小孩容易，養小孩難」。軟體需要不斷跟隨環境更新。
很常會是 Released 之後就會有立即需要修改的地方，且 Requirement 是個 moving target，只能在舊有架構上持續疊加。
聽到這裡我非常有感，最近因為時常更新部落格，剛 Push 上去一個新功能，馬上就會發現新的 Bug 或想調整的 UI。
4. 軟體的品質控管 (QC)
製造業透過改善生產流程來提升良率，也就是生產線（Assembly Line）的概念。
如果某部分工作無法由機器執行，就把人的任務拆解得極度單純，
每個人只做一件簡單的事，出錯機率自然降低。更重要的是，當進度落後時，加派人手就能提升產能，而且這個邏輯基本上是線性的。
但軟體開發截然不同。
人月神話（The Mythical Man-Month） 是 Fred Brooks 在 1975 年的觀察：製造業裡，10 個人做 1 個月的工作，和 1 個人做 10 個月，產出大致相當。但軟體開發中，這個等式完全不成立。
向一個已經落後的軟體專案增加人手，只會讓它更加落後。 — Fred Brooks
原因是新成員需要學習成本，而溝通與協調的開銷會隨人數非線性成長，和生產線那種乾淨的任務分工完全不同。
對應到程式碼本身的品質控管，類比製造業的做法，或許是把 function 拆解到只做一件事。但實際上很難做到，因為 function 之間本來就存在耦合性，這也是物件導向試圖去解決的問題之一。
5. 物件導向就是「延遲滿足」
老師第一堂課提到經典的棉花糖實驗，這個影片我之前看過，是在講延遲滿足。
為什麼設計類別（Class）很痛苦？因為設計需要思考「明天的事情」。先做再說、邊做邊改雖然當下很快，但未來可能會陷入無盡的維修地獄。 （雖然我開發個人專案時也很常這樣哈哈哈，這也是我想修這堂課的原因。）
物件導向思維就是強迫我們在動手寫程式前，先忍受設計的枯燥與複雜，為了換取未來系統的擴充性與可維護性。
小結
- 軟體工程面對的問題不是技術本身，更多是規模、協作、時間
- 維護成本才是軟體開發的主體，不是初始開發
- 物件導向是一種設計思維，目的是讓程式碼在未來更容易維護與擴充