YAGNI 原則
繼 DRY 原則與 KISS 原則之後，最常被並列再一起討論的非 YAGNI 原則莫屬了，而 YAGNI 原則（You aren’t gonna need it），顧名思義為你不會需要它。但到底程式設計中我們會不需要什麼呢？
仔細回想一下，有沒有曾經在開發過程中為了預先擴充某樣功能而撰寫程式碼的經驗？
最終那些為了擴充的程式碼最後有真的派上用場還是就默默冷落在角落成為雞肋的存在？
抑或是派上了用場但與當初所預設的規格有所不同？
對於 YAGNI 原則來說，這些都是應該自己盡量避免的，而幾個可以達到 YAGNI 原則的概念：
- 專注在實現專案文件中需求的功能
- 不要過早優化程式碼
- 不要替未來的功能預設立場，去撰寫用不到的程式碼
為何需要 YAGNI 原則?
對於專案實務上來說，這些預設立場的功能並沒有辦法在專案上實際運用，很有可能自己猜想覺得完美無缺，但實際真的運用時會有沒想到的例外處理。即便是寫了單元測試（Unit testing）去細心維護這些擴充的功能，在將來也很有可能因為文件規格的改動使得這些擴充的功能並不符合預期效益。
另一點則是對於人員的調動與接手維護上的問題，當今年這個專案移交給其他人維護時，其他開發人員很有可能不清楚該段程式碼的想法，將原意可能良好的設計，突變（Mutate）了原本的設計，導致概念更加的混亂。除此之外，預設了越多立場程式碼也會對於後續維護的人在閱讀程式碼時得花上額外的心力，才能辨別該段程式碼中的原意。到頭來，還不如一開始留的乾淨直白，等到需要的時候，才真正地將原有不符合規格的程式重構（refacting）。
而對於實務經驗不多的 Junior 開發者來說，預先立場更是一件可怕的事情，由於實務經驗不多，對於功能將來擴充的方向不明，而做了多不必要的功能，甚至限制了該功能在將來的彈性，再加上針對不必要的功能所進行的防禦性與邊界處理等等，就會產生出更大量沒有必要的程式。
YAGNI 的隱憂
因為每個開發環節關注的點不同，雷點也不盡相同，究竟要保留彈性到什麼樣的程度對於開發者來說是一個很艱困的難題。畢竟有些雷點即便是我們都聽過，但沒有親自踩過、痛過的經驗，有時候是難以體會的，而這部份真的只能依靠實務經驗來累積，所以除了上班寫的專案之外，下班後就靠 side project 來增加實務經驗吧！