[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是否買單...
並不是說這些設計完全不需要, 只是現在還用不到,更應該專注當下最重要的問題, 並用做簡單的方法去做驗證
如果我們建立團隊的方式是可以快速地應對變化, 我們是否還需要事先假設未來的需求呢？
如果我們團隊成長到一定的程度之後, 可能會浮現擴展性的問題, 如果團隊可以快速發現問題且提出解決方案, 我們是否不用在第一時間就設計擴充性？
Good Design is an incremental process 透過不斷地發現跟學習讓系統更完善
Ease of Change = Quality in Code
如果我們害怕去改變程式或是架構, 表示他是不好的設計
想像一下
你是一個自由接案的工程師, 你的合作對象帶著他的需求來請求幫忙
- 你會多做沒有在需求對話中談到的"需求"？ 合作對象會說沒有在原本的需求裡面不會付錢
- 在你的合作對象真的賺錢之前, 你有信心他不會很快就倒了？這樣你還願意多做不在計畫裡面的設計？
- 在還沒有驗證方案的可行性之前, 你會先寫完所有的功能？ 如果解法不可行,你將浪費很多時間要在尋找其他的解法, 重點是合作對象不會針對之前不可行的解法付錢
- 你是否會再聽到合作對象的第一時間就給出解法？ 那如果連合作對象都對他的自己都不了解呢？是否能透過溝通去探索問題的本質, 先把問題弄清楚, 才不會提出無法解決問題的方案, 一再的來來回回釐清問題
- 如果你的合作對象產品一直在變, 你是否有能力跟上？ 還是轉個方向你之前的設計就全部不能用要重寫？ 培養快速面對變化的能力很重要
留言
發佈留言