在《軟體構築美學 pdf p.16 》提到軟體開發中鐵三角的概念。
而作者則提出另一個水平的觀點：
天平左邊放的是（預估的）時程和資源，代表我們希望盡量減少的部分。
天平右邊放的是品質和功能，我們希望這部分愈多愈好。
重點在於天平必須隨時保持平衡，如果要增加一項功能，就必須增加適量的時間和資源來維持平衡。
如果經費不足，你就得做出選擇：要犧牲品質還是功能。
時程短、範圍大、資源少
壓時程，趕工作，結果導向，那麼產出的程式碼就必定含有技術債(這是指我)，最少有以下二個缺點：
- 以「功能分解」分解為主
- 未能含有測試
功能分解
指以「函數」為主的開發方式，雖然設計成Class，但Class內其實就是把幾千行的程式分類為數十個函數方法，如果以Main(指程式進入點)的角度來看，程式的回應符合我預期會動就好，管你Class內的程式碼怎麼實作。由封裝的角度看來，也是如此，我給你最後的"return 結果"符合呼叫者的預期就好，你管我如何實作。
功能分解的寫法很容易產生副作用，頂多只是把早期Library的做法放入一組有名稱的Class之中。這樣的Class再往下分析，它就是一組端士刀的組合，換句話說就是「職責不單一」了。
夏天到了，想想，你想切西瓜，但你只有端士刀能用是什麼感覺，如果能有個職責單一的切西瓜神器不知道有多好？
From: www.best73.com未能含有測試
記得 91 在 TDD 課程說過：「如果你的程式，測試加不上去，測試很難寫，很難獨立對它進行測試，那代表你production code寫太爛。
」一個職責不單一的Class，想要補測試都難。以我上課時的統計(中部地區)來看，天平都不是站在品質的這邊，更不要說寫測試了。
盡早重構 - 還債的第一步
債什麼時候要還，我覺的和上層很大關係。也就是在《軟體構築美學 p.19, p21》裡提到的政治因素，書中有很多說明，真的是字字珠璣的一本書。
債早還晚還都是要還的，只差看你是解 bug 時再還，還是盡早重構來還。
在《軟體構築美學 p.17》中討論「大幅重寫」與「重構」，如果債已深(通常就是留到解 bug 時)，大多會偏向或感覺或希望能大幅重寫的思考方式。
重構
盡早的重構，並將職責畫分出來。
盡早的好處在於，程式的印象還很新，每個函數、作用等都還清楚，畫分也容易些。程式寫久的人都有這樣的經驗，一個月後問你，當初這段程式為什麼這樣寫？最常得到的的第一答案是不知道。
分析的過程中，因為程式是自己寫的，也清楚整體的架構與變化點。變化點也就是重構的重點。
算晚輩資淺，還有很多先輩不認識，除了91，TED，投影片裏的先輩大名分別是
回覆刪除