[CD心得] How To Avoid Designing A Big Ball Of Mud (YAGNI) 怎樣去避免設計出一個大泥球(缺少可認知架構的軟體系統)
什麼才叫做好的設計？ 怎麼樣算是過度設計? (Over Design) 看完了影片之後記錄一些重點和心得 Big up front Design VS Incremental Design 如何避免去建造明天會覺得老式的系統呢？ Agile Design = Incremental Design Anti-pattern => Big up front Design 非常古老的方法且目前還非常普遍, 會希望我們在寫Code 之前詳盡地做完一切的Design YAGNI = You Ain't Gonna Need it (你不會需要他) Extreme Programming Explained: Embrace Change 的作者Kent Beck提到 只做最簡單可以完成工作的部分 盡可能地讓程式小步驟地前進 透過Refactoring 去完善你的設計 你永遠沒有足夠的時間完成你心目中完美的設計 核心理念是以目前所知所能做的做簡單方法去完成這個任務 如果我們提前去設計目前看不到需求的功能, 或是我們還不是真正了解需求背後的目的 我們有很大的機會在浪費時間做不對的事 當遇到問題的時候, 好的工程師會透過對話去探索或是理解問題的本質 進而從搜集的資訊中去找出最簡單可行的方案 在給出解法之前, 非常建議多花點時間去了解問題的上下文, 不然你給出的方案只是建立在你的假設上, 並沒有解決真正的問題 如果你的問題的認知是錯的, 非常的可能你給的答案也會是錯的 只專注在什麼是我們現在該解決的問題 當我們釐清問題之後, 我們可以小步驟的去驗我們的方案是否有解決問題 並且只專注在目前的問題上 YAGNI 的方法去限制過度設計的問題 大部分工程師在專案初期都有所期待, 認為自己的產品之後會爆紅, 在不自覺中就會去想著之後如果User 都在同一時間上來, 我們的系統撐得住嗎？ 該採取怎麼的設計才比較好擴展？ 以至於在專案的前期花費了大量的時間和金錢, 但是還無法得到驗證User是否買單... 並不是說這些設計完全不需要, 只是現在還用不到,更應該專注當下最重要的問題, 並用做簡單的方法去做驗證 如果我們建立團隊的方式是可以快速地應對變化, 我們是否還需要事先假設未來的需求呢？ 如果我們團隊成長到一定的程度之後, 可能...