YAGNI(You Ain't Gonna Need It)原則是 KISS(Keep It Simple and Stupid)的一個支派,意思是我們不應該為程式碼加入尚未用到的功能。
有時候,開發人員可能會想得很多、很遠。也許是因為需求太模糊、經常變動而產生的危機感,也許是對進階技術的學習熱誠或其他原因,他們可能會不加思索地直接套用某種設計模式(design pattern)或物件導向設計原則。對老手來說,這樣的不加思索可能是經驗累積出來的直覺;但是對於仍在摸索嘗試階段的人來說,卻容易落入「為賦新辭強說愁」的泥淖--為 pattern 而 pattern、為 IoC 而 IoC、為 xyz 而 xyz....
某種程度上,YAGNI 扮演著一種平衡的角色,或者說,鎮靜劑。想到此原則,應該可以讓開發人員停下來多想一下,現在這個程式,真的需要使用 XX 模式嗎?真的要用 IoC 容器嗎?真的需要切成一堆小介面和抽象類別嗎?
Sometimes, you just ain't gonna need it.
當然,YAGNI 不可拿來當作不求進步的藉口。我們只是需要找到一個平衡點:程式寫到甚麼程度就夠了。我是說,當未來--比較近的未來,不是兩三年後--出現需求變動時,我們的程式能否有應急之道?能否透過一點點重構(refactoring)就解決問題?如果答案是肯定的,那麼也許就離「適度」不遠了。這樣的成本效益比較好,這樣的程式碼往往也比較「謙虛」,亦可免於陷入過度設計或「技術大車拚」的困擾。
一個考量的重點是:context。也就是說,當下那個需求、那個場景是否適用。若硬要找個模式來套,寫出來的程式碼多半會顯得彆扭、不自然。Code review 時應該很容易嗅出這個味道。
順便打書:《軟體構築美學》的第七章有提到 YAGNI,第九章則專門討論 dependency injection。
Happy coding :)
有時候,開發人員可能會想得很多、很遠。也許是因為需求太模糊、經常變動而產生的危機感,也許是對進階技術的學習熱誠或其他原因,他們可能會不加思索地直接套用某種設計模式(design pattern)或物件導向設計原則。對老手來說,這樣的不加思索可能是經驗累積出來的直覺;但是對於仍在摸索嘗試階段的人來說,卻容易落入「為賦新辭強說愁」的泥淖--為 pattern 而 pattern、為 IoC 而 IoC、為 xyz 而 xyz....
某種程度上,YAGNI 扮演著一種平衡的角色,或者說,鎮靜劑。想到此原則,應該可以讓開發人員停下來多想一下,現在這個程式,真的需要使用 XX 模式嗎?真的要用 IoC 容器嗎?真的需要切成一堆小介面和抽象類別嗎?
Sometimes, you just ain't gonna need it.
當然,YAGNI 不可拿來當作不求進步的藉口。我們只是需要找到一個平衡點:程式寫到甚麼程度就夠了。我是說,當未來--比較近的未來,不是兩三年後--出現需求變動時,我們的程式能否有應急之道?能否透過一點點重構(refactoring)就解決問題?如果答案是肯定的,那麼也許就離「適度」不遠了。這樣的成本效益比較好,這樣的程式碼往往也比較「謙虛」,亦可免於陷入過度設計或「技術大車拚」的困擾。
一個考量的重點是:context。也就是說,當下那個需求、那個場景是否適用。若硬要找個模式來套,寫出來的程式碼多半會顯得彆扭、不自然。Code review 時應該很容易嗅出這個味道。
順便打書:《軟體構築美學》的第七章有提到 YAGNI,第九章則專門討論 dependency injection。
Happy coding :)
『軟體構築美學』真的是一本超棒的書啦!感謝老師幫忙翻譯這麼棒的書,也翻的很棒喔!
回覆刪除91 兄:
回覆刪除多謝您的讚美!
後半部是張簡才祿翻譯的,相信他聽到了也會很高興。^_^