Image

今天轉貼一篇我很喜歡的文章，在嘴人的場合很好用：
一窩蜂驅動開發 - Northern Wind

原文：Hype Driven Development

一窩蜂驅動開發，又能稱作「Reddit 驅動開發」、「研討會驅動開發」、「講話最大聲的說了算」等等。

基本上就是看什麼最夯就用什麼，把新工具視為一切解決方案，然後馬上跌坑的開發方式

一窩蜂會造成錯誤的決策。架構設計錯誤與技術選用錯誤都會困擾團隊數個月甚至數年之久。 最壞的情況會造成另一個很糟糕的行為：砍掉重練，這樣做永遠不會有好結果的。

在這篇文章中，作者提出了一窩蜂開發的五個階段：

  • 第一階段：真正的問題與解答
  • 第二階段：曝光、瘋傳、關鍵字
  • 第三階段：狂熱開始
  • 第四階段：失望
  • 第五階段：多麼痛的領悟

看說明不如看例子，這篇文章提了五個範例，我轉其中兩個我平常比較有感的出來：

範例一：React.js

第一步： Facebook 遇到一個問題－有些複雜的單頁應用，像是 Facebook 本身，有著大量會改變狀態的事件。會變得很難去追蹤到底觸發過什麼事件或是很難確保程式的狀態保持一致。

第二步： Facebook 開始推廣新的設計，夾帶著一些關鍵字：函數式程式設計（Functional）、Virtual DOM、Components。

第三步： 狂熱：Facebook 創造了跨時代的網頁框架！從今天起所有東西都該用 React.js 來寫！

第四步： 等等，這東西工程浩大，短期之內卻沒有什麼回收！

第五步： React 對於有很多即時通知的單頁應用很棒，但是用在簡單的網頁應用上卻不一定會獲得回報。

範例三：Microservices

第一步： Monolithic application 難以擴展。現在有個做法是把它拆解成很多小服務。這樣每秒能處理的需求量可以更方便做擴展 ，跨團隊的擴展也更容易做到。

第二步： 關鍵字：可擴展性（Scalability）、低耦合（Loose coupling）、Monolith。

第三步： 我們把所有東西都成寫成服務吧！我們的程式一團亂都是因為我們用的是 Monolith architecture！我們必須把所有東西都改寫成 Microservice 。

第四步： 挫賽！現在開發變得超慢的，部署也變困難了，然後追 bug 要橫跨多個系統。

第五步： Microservices 需要有經驗的團隊還有在正確的時間點投入才有可能在系統與團隊擴展時有所回報。當你在遇到真正的擴展問題前用就是過度投資。Microservices 往往是拆解出來的而非直接寫成，你要這麼大才能用 Microservices。

感覺到了嗎，醒悟總是來得太晚，先衝上頭的先挫賽 :0hah:

面對內心的熱血跟衝動，如果我們真的好想好想使用真香的新技術，可以怎麼做呢？

  • 快速測試：花一到兩天建立原型，然後邀請團隊一起分析利弊，或是嘗試黑客松
  • 確認投資報酬率：很多技術是為了解決特定問題產生的，我們有遇到同樣的問題嗎？嚴重嗎？值得嗎？
  • 累積經驗：知道越多範式跟理論，或是被坑過比較多次 能夠幫助我們平衡決策

那麼，今天的轉貼就先到這邊。明天見 >< 還好我不缺搞笑文章，呼