From e168b2d8cfd2208b8ffdce1b0bfee54c0f38e68e Mon Sep 17 00:00:00 2001
From: Chun-Fu Chao <aaefiikmnnnr@gmail.com>
Date: Wed, 4 Mar 2020 01:28:58 +0800
Subject: [PATCH] Update

---
 index.xml                                     |  2 +-
 posts/hype-driven-development/index.html      | 50 +++++++++----------
 posts/index.xml                               |  2 +-
 .../index.html                                |  2 +-
 4 files changed, 28 insertions(+), 28 deletions(-)

diff --git a/index.xml b/index.xml
index 27e27e9..7ef8891 100644
--- a/index.xml
+++ b/index.xml
@@ -53,7 +53,7 @@
       <pubDate>Tue, 07 Feb 2017 16:53:42 +0000</pubDate>
       
       <guid>https://chunfuchao.com/posts/hype-driven-development/</guid>
-      <description>&lt;p&gt;原文：《&lt;a href=&#34;https://blog.daftcode.pl/hype-driven-development-3469fc2e9b22#.setimjcqj&#34;&gt;Hype Driven Development&lt;/a&gt;》，感謝原作者 &lt;a href=&#34;https://blog.daftcode.pl/@marekkirejczyk&#34;&gt;Marek Kirejczyk&lt;/a&gt; 授權 &lt;a href=&#34;https://twitter.com/marekkirejczyk/status/827437538071674881&#34;&gt;翻譯&lt;/a&gt;，感謝 CH Huang、Yi Jeng Lin 協助勘誤。轉載請附上原文連結與出處。&lt;/p&gt;
+      <description>&lt;p&gt;原文：《&lt;a href=&#34;https://blog.daftcode.pl/hype-driven-development-3469fc2e9b22#.setimjcqj&#34;&gt;Hype Driven Development&lt;/a&gt;》，感謝原作者 &lt;a href=&#34;https://blog.daftcode.pl/@marekkirejczyk&#34;&gt;Marek Kirejczyk&lt;/a&gt; 授權&lt;a href=&#34;https://twitter.com/marekkirejczyk/status/827437538071674881&#34;&gt;翻譯&lt;/a&gt;，感謝 CH Huang、Yi Jeng Lin 協助勘誤。轉載請附上原文連結與出處。&lt;/p&gt;
 &lt;p&gt;軟體開發團隊時常靠偏見、社群媒體上的消息、或者只是看什麼東西最「夯」來決定要用什麼架構或是技術。而非扎實地研究與衡量這些東西對專案會造成什麼樣的影響。我把這叫做「一窩蜂驅動開發」（Hype Driven Development），我認定這樣是有害的也建議開發者們改採更專業的「務實軟體開發」（Solid Software Engineering）。我會解釋這一切是怎麼發生的，還有怎麼避開這個問題。&lt;/p&gt;</description>
     </item>
     
diff --git a/posts/hype-driven-development/index.html b/posts/hype-driven-development/index.html
index edc98d0..c9731e3 100644
--- a/posts/hype-driven-development/index.html
+++ b/posts/hype-driven-development/index.html
@@ -16,7 +16,7 @@
 <meta name="apple-mobile-web-app-status-bar-style" content="#f8f5ec">
 
 
-<meta name="author" content="Chun-Fu Chao" /><meta name="description" content="原文：《Hype Driven Development》，感謝原作者 Marek Kirejczyk 授權 翻譯，感謝 CH Huang、Yi Jeng Lin 協助勘誤。轉載請附上原文連結與出處。
+<meta name="author" content="Chun-Fu Chao" /><meta name="description" content="原文：《Hype Driven Development》，感謝原作者 Marek Kirejczyk 授權翻譯，感謝 CH Huang、Yi Jeng Lin 協助勘誤。轉載請附上原文連結與出處。
 軟體開發團隊時常靠偏見、社群媒體上的消息、或者只是看什麼東西最「夯」來決定要用什麼架構或是技術。而非扎實地研究與衡量這些東西對專案會造成什麼樣的影響。我把這叫做「一窩蜂驅動開發」（Hype Driven Development），我認定這樣是有害的也建議開發者們改採更專業的「務實軟體開發」（Solid Software Engineering）。我會解釋這一切是怎麼發生的，還有怎麼避開這個問題。
 " />
 
@@ -41,14 +41,14 @@
 
 
 <meta property="og:title" content="一窩蜂驅動開發" />
-<meta property="og:description" content="原文：《Hype Driven Development》，感謝原作者 Marek Kirejczyk 授權 翻譯，感謝 CH Huang、Yi Jeng Lin 協助勘誤。轉載請附上原文連結與出處。
+<meta property="og:description" content="原文：《Hype Driven Development》，感謝原作者 Marek Kirejczyk 授權翻譯，感謝 CH Huang、Yi Jeng Lin 協助勘誤。轉載請附上原文連結與出處。
 軟體開發團隊時常靠偏見、社群媒體上的消息、或者只是看什麼東西最「夯」來決定要用什麼架構或是技術。而非扎實地研究與衡量這些東西對專案會造成什麼樣的影響。我把這叫做「一窩蜂驅動開發」（Hype Driven Development），我認定這樣是有害的也建議開發者們改採更專業的「務實軟體開發」（Solid Software Engineering）。我會解釋這一切是怎麼發生的，還有怎麼避開這個問題。" />
 <meta property="og:type" content="article" />
 <meta property="og:url" content="https://chunfuchao.com/posts/hype-driven-development/" />
 <meta property="article:published_time" content="2017-02-07T16:53:42+00:00" />
 <meta property="article:modified_time" content="2017-02-07T16:53:42+00:00" />
 <meta itemprop="name" content="一窩蜂驅動開發">
-<meta itemprop="description" content="原文：《Hype Driven Development》，感謝原作者 Marek Kirejczyk 授權 翻譯，感謝 CH Huang、Yi Jeng Lin 協助勘誤。轉載請附上原文連結與出處。
+<meta itemprop="description" content="原文：《Hype Driven Development》，感謝原作者 Marek Kirejczyk 授權翻譯，感謝 CH Huang、Yi Jeng Lin 協助勘誤。轉載請附上原文連結與出處。
 軟體開發團隊時常靠偏見、社群媒體上的消息、或者只是看什麼東西最「夯」來決定要用什麼架構或是技術。而非扎實地研究與衡量這些東西對專案會造成什麼樣的影響。我把這叫做「一窩蜂驅動開發」（Hype Driven Development），我認定這樣是有害的也建議開發者們改採更專業的「務實軟體開發」（Solid Software Engineering）。我會解釋這一切是怎麼發生的，還有怎麼避開這個問題。">
 <meta itemprop="datePublished" content="2017-02-07T16:53:42&#43;00:00" />
 <meta itemprop="dateModified" content="2017-02-07T16:53:42&#43;00:00" />
@@ -58,7 +58,7 @@
 
 <meta itemprop="keywords" content="" /><meta name="twitter:card" content="summary"/>
 <meta name="twitter:title" content="一窩蜂驅動開發"/>
-<meta name="twitter:description" content="原文：《Hype Driven Development》，感謝原作者 Marek Kirejczyk 授權 翻譯，感謝 CH Huang、Yi Jeng Lin 協助勘誤。轉載請附上原文連結與出處。
+<meta name="twitter:description" content="原文：《Hype Driven Development》，感謝原作者 Marek Kirejczyk 授權翻譯，感謝 CH Huang、Yi Jeng Lin 協助勘誤。轉載請附上原文連結與出處。
 軟體開發團隊時常靠偏見、社群媒體上的消息、或者只是看什麼東西最「夯」來決定要用什麼架構或是技術。而非扎實地研究與衡量這些東西對專案會造成什麼樣的影響。我把這叫做「一窩蜂驅動開發」（Hype Driven Development），我認定這樣是有害的也建議開發者們改採更專業的「務實軟體開發」（Solid Software Engineering）。我會解釋這一切是怎麼發生的，還有怎麼避開這個問題。"/>
 
 <!--[if lte IE 9]>
@@ -105,11 +105,11 @@
         <div id="content" class="content">
           <article class="post">
   <div class="post-content">
-    <p>原文：《<a href="https://blog.daftcode.pl/hype-driven-development-3469fc2e9b22#.setimjcqj">Hype Driven Development</a>》，感謝原作者 <a href="https://blog.daftcode.pl/@marekkirejczyk">Marek Kirejczyk</a> 授權 <a href="https://twitter.com/marekkirejczyk/status/827437538071674881">翻譯</a>，感謝 CH Huang、Yi Jeng Lin 協助勘誤。轉載請附上原文連結與出處。</p>
+    <p>原文：《<a href="https://blog.daftcode.pl/hype-driven-development-3469fc2e9b22#.setimjcqj">Hype Driven Development</a>》，感謝原作者 <a href="https://blog.daftcode.pl/@marekkirejczyk">Marek Kirejczyk</a> 授權<a href="https://twitter.com/marekkirejczyk/status/827437538071674881">翻譯</a>，感謝 CH Huang、Yi Jeng Lin 協助勘誤。轉載請附上原文連結與出處。</p>
 <p>軟體開發團隊時常靠偏見、社群媒體上的消息、或者只是看什麼東西最「夯」來決定要用什麼架構或是技術。而非扎實地研究與衡量這些東西對專案會造成什麼樣的影響。我把這叫做「一窩蜂驅動開發」（Hype Driven Development），我認定這樣是有害的也建議開發者們改採更專業的「務實軟體開發」（Solid Software Engineering）。我會解釋這一切是怎麼發生的，還有怎麼避開這個問題。</p>
-<h3 id="heading">新技術－新希望</h3>
+<h1 id="heading">新技術－新希望</h1>
 <p>你經歷這樣的情況嗎？有個團隊選了個最新最酷炫的技術然後直接頭洗下去。可能是因為某個成員讀了某篇部落格文章、 Twitter 上面最近也討論很兇、然後有些人剛從研討會聽了一場關於這個新技術很棒的演講回來。過沒多久，團隊便開始使用這個閃亮亮的新技術（或是某種軟體架構）。但開發效率跟成果沒有像其他人宣稱地變好，整個團隊反而陷入麻煩之中。效率降低、士氣開始低落，然後下個正式版本的交付陷入窘境。有些團隊甚至忙到沒時間出新功能都在修 bug，他們總是說「還要再幾天」才能找出根本問題。</p>
-<h3 id="heading-1">一窩蜂驅動開發</h3>
+<h1 id="heading-1">一窩蜂驅動開發</h1>
 <p>一窩蜂驅動開發有著各種不同的樣貌，對你的專案影響也不盡相同。</p>
 <ul>
 <li><strong>Reddit 驅動開發</strong>－團隊或個人是靠知名部落客現在在寫什麼、Reddit 在討論什麼、Hacker News、Twitter、Facebook、GitHub 或是其他任何的社群媒體來決定要用什麼技術／架構／設計。</li>
@@ -118,70 +118,70 @@ <h3 id="heading-1">一窩蜂驅動開發</h3>
 <li><strong>Gem／函式庫／外掛驅動開發</strong>－這在 Ruby on Rails 的社群特別常見，很多 Gemfile 的長度長到只有載入時間可以比它長。因為他們認為所有 Rails 上遇到的問題都該以引入 Gem 來解決。有時候問題只需要自己動手寫幾行程式就能解決，但我們總是想要用別人的函式庫、外掛、Gem、框架去解決。</li>
 <li>然後我想岔題提個一窩蜂驅動開發者常見的症狀－<strong>Stack Overflow 驅動開發</strong>－他們從 Stack Overflow 或是其他網路資源做複製貼上的動作而沒有去理解問題與解答。</li>
 </ul>
-<h3 id="heading-2">一窩蜂是開發團隊自我毀滅的原因</h3>
+<h1 id="heading-2">一窩蜂是開發團隊自我毀滅的原因</h1>
 <p>問題在於一窩蜂會造成錯誤的決策。架構設計錯誤與技術選用錯誤都會<strong>困擾團隊數個月甚至數年之久</strong>。最壞的情況會造成另一個很糟糕的行為：<strong>砍掉重練</strong>，這樣做永遠不會有好結果的。</p>
 <p>一切的<strong>罪惡根源似乎是社群媒體</strong>，太多的想法在實戰測試之前就傳出去了，跑得比大家分析利弊得失的速度還要快。</p>
-<h3 id="heading-3">剖析一窩蜂</h3>
+<h1 id="heading-3">剖析一窩蜂</h1>
 <p>大多數的一窩蜂現象有著類似起伏：</p>
 <p><img src="/images/hype-driven-development/hype-anatomy.png" alt="Hype Anatomy"></p>
-<h4 id="heading-4">第一階段：真正的問題與解答</h4>
+<h2 id="heading-4">第一階段：真正的問題與解答</h2>
 <p>一開始是某個公司遇到某個問題。公司裡的某個團隊認定現有的技術、流程、或是架構設計無法解決他們的問題。這個公司自製了一個架構、函式庫、或是設計模式解決了他們遇到的問題。</p>
-<h4 id="heading-5">第二階段：曝光、瘋傳、關鍵字</h4>
+<h2 id="heading-5">第二階段：曝光、瘋傳、關鍵字</h2>
 <p>這個團隊迫不急待地想跟其他人分享他們的解法，過沒多久他們開始寫文章，去研討會演講。他們解決的問題通常有一定的複雜度，所以提供的解決方法也會有一定的複雜度。人們對新技術感到興奮，卻不一定對問題本質還有解答的實作細節有深刻了解。畢竟問題跟解答都不簡單，一個推文、一段閒聊、甚至一整篇部落格文章可能都沒有辦法解釋清楚。當我們用社群媒體、部落格、或是研討會上的快閃演講來傳達，訊息本身就失真了。</p>
-<h4 id="heading-6">第三階段：狂熱開始</h4>
+<h2 id="heading-6">第三階段：狂熱開始</h2>
 <p>各式一窩蜂的開發者讀到那些文章或是聽到演講。很快地世界各地的開發者都開始採用這個新技術。但因為他們接收到的訊息有一定程度的失真－有些人倉促地決定使用某個框架，即使這個東西並沒有解決到他們現在實際遇到的任何問題，但他們還是錯誤地期待這個新玩意兒是萬靈丹。</p>
 <p><img src="/images/hype-driven-development/hype-dev.png" alt="Hype Dev"></p>
-<h4 id="heading-7">第四階段：失望</h4>
+<h2 id="heading-7">第四階段：失望</h2>
 <p>過了幾個 Sprint 之後，這項新技術並沒有讓團隊過得更好，但他們要花的工夫變多了。團隊要花很多時間重寫程式還有學習新技術要怎麼用。整體進度慢下來了，管理階層覺得火大，大家都覺得被騙了。</p>
-<h4 id="heading-8">第五階段：多麼痛的領悟</h4>
+<h2 id="heading-8">第五階段：多麼痛的領悟</h2>
 <p>終於，團隊在事後檢討的時候領悟到要採用這項新技術是需要取捨的，然後其實應該用在哪個情境會比較合宜。他們學乖了⋯⋯直到下一個很「夯」的東西出現。</p>
-<h3 id="heading-9">一窩蜂的例子：</h3>
+<h1 id="heading-9">一窩蜂的例子：</h1>
 <p>底下是一些現實中一窩蜂的例子，看看它們發展的歷程。</p>
-<h4 id="reactjs">範例一：React.js</h4>
+<h2 id="reactjs">範例一：React.js</h2>
 <p><strong>第一步：</strong> Facebook 遇到一個問題－有些複雜的單頁應用，像是 Facebook 本身，有著大量會改變狀態的事件。會變得很難去追蹤到底觸發過什麼事件或是很難確保程式的狀態保持一致。</p>
 <p><strong>第二步：</strong> Facebook 開始推廣新的設計，夾帶著一些關鍵字：函數式程式設計（Functional）、Virtual DOM、Components。</p>
 <p><strong>第三步：</strong> 狂熱：Facebook 創造了跨時代的網頁框架！從今天起所有東西都該用 React.js 來寫！</p>
 <p><strong>第四步：</strong> 等等，這東西工程浩大，短期之內卻沒有什麼回收！</p>
 <p><strong>第五步：</strong> React 對於有很多即時通知的單頁應用很棒，但是用在簡單的網頁應用上卻不一定會獲得回報。</p>
-<h4 id="dhh-">範例二：DHH 說的「測試驅動開發已死」</h4>
+<h2 id="dhh-">範例二：DHH 說的「測試驅動開發已死」</h2>
 <p><strong>第一步：</strong> David Heinemeier Hansson（DHH，創造 Ruby on Rails 的人）發現在 Ruby on Rails 上做測試驅動開發有所困難。因此做了一個務實的決定－不先寫測試。</p>
 <p><strong>第二步：</strong> DHH 的<a href="http://david.heinemeierhansson.com/2014/tdd-is-dead-long-live-testing.html">部落格文章</a>跟<a href="https://www.youtube.com/watch?v=9LfmrkyP81M">演講</a>開始了一窩蜂。關鍵字： <strong>測試驅動已死</strong>。</p>
 <p><strong>第三步：</strong> 大大都這樣說了，我們就別寫測試了。反正我們本來就不會寫，現在我們也不假裝會寫了。我們終於誠實面對自己了。</p>
 <p><strong>第四步：</strong> 等等！越來越多東西爆炸了。我們寫出一堆蟲。</p>
 <p><strong>第五步：</strong> Kent Beck：「測試驅動沒有所謂的活著或是已死，它是個取捨：要看被改 API 的風險有多高，參與的程式設計師的能力還有既有的設計為何」</p>
-<h4 id="microservices">範例三：Microservices</h4>
+<h2 id="microservices">範例三：Microservices</h2>
 <p><strong>第一步</strong> Monolithic application 難以擴展。現在有個做法是把它拆解成很多小服務。這樣每秒能處理的需求量可以更方便做擴展 ，跨團隊的擴展也更容易做到。</p>
 <p><strong>第二步</strong> 關鍵字：可擴展性（Scalability）、低耦合（Loose coupling）、Monolith。</p>
 <p><strong>第三步</strong> 我們把所有東西都成寫成服務吧！我們的程式一團亂都是因為我們用的是 Monolith architecture！我們必須把所有東西都改寫成 Microservice 。</p>
 <p><strong>第四步</strong> 挫賽！現在開發變得超慢的，部署也變困難了，然後追 bug 要橫跨多個系統。</p>
 <p><strong>第五步</strong> Microservices 需要有經驗的團隊還有在正確的時間點投入才有可能在系統與團隊擴展時有所回報。當你在遇到真正的擴展問題前用就是過度投資。Microservices 往往是拆解出來的而非直接寫成，<a href="https://twitter.com/martinfowler/status/504997343440408576">你要這麼大才能用 Microservices</a>。</p>
-<h4 id="nosql">範例四：NoSQL</h4>
+<h2 id="nosql">範例四：NoSQL</h2>
 <p><strong>第一步：</strong> SQL 資料庫在處理高負載跟非結構式資料（Unstructured data）時會遇到困難。世界各地的團隊開始開發新一代的資料庫系統。</p>
 <p><strong>第二步：</strong> 關鍵字：擴展性、大數據、高效率</p>
 <p><strong>第三步：</strong> 我們的資料庫跑得慢又不夠大，我們要 NoSQL！</p>
 <p><strong>第四步：</strong> 我們需要 join 操作？這做不到。簡單的傳統 SQL 操作變得越來越困難。開發越來越慢而問題本身還是沒有解決。</p>
 <p><strong>第五步：</strong> NoSQL 是為了解決非常特定問題的答案（極大量、非結構式、或是高負載）。SQL 經過良好的調校還是可以處理高負載跟大量資料。到了 2016，應該使用 NoSQL 的情境還是少見。</p>
-<h4 id="elixir--phoenix">範例五：Elixir 與 Phoenix（或是任何一對你最愛的語言／框架組合）</h4>
+<h2 id="elixir--phoenix">範例五：Elixir 與 Phoenix（或是任何一對你最愛的語言／框架組合）</h2>
 <p><strong>第一步：</strong> Ruby on Rails 之類的框架沒有辦法好好處理需要高效能、分散式、還有 WebSocket 的需求。</p>
 <p><strong>第二步：</strong> 關鍵字：擴展性、高效能、分散式、容錯（Fault-tolerant）</p>
 <p><strong>第三步：</strong> 我的天，我們的應用程式超慢然後對話功能竟然不能擴展！</p>
 <p><strong>第四步：</strong> 哇，函數式程式設計跟分散式程式設計超難學的。我們進展緩慢。</p>
 <p><strong>第五步：</strong> Elixir 跟 Phoenix 是好東西，但是需要大量的時間才能學好。如果你真的需要特別高效率的應用，長期來說是有正向投資報酬的。</p>
-<h4 id="heading-10">範例多的是：</h4>
+<h2 id="heading-10">範例多的是：</h2>
 <p>在電腦工程有許多領域一窩蜂的情況時常發生，JavaScript 的世界裡天天都有新框架。Node.js（關鍵字：事件驅動開發）、Reactive programming、Meteor.js（關鍵字：Shared state）、前端 MVC、React.js，應有盡有。軟體工程領域裡我們有 Domain driven development、Hexagon、DCI。你最喜歡的一窩蜂現象是什麼？</p>
-<h3 id="heading-11">比較好的作法</h3>
+<h1 id="heading-11">比較好的作法</h1>
 <p>如果我們不能盡信網路上的說法還有別人們的意見，那我們該怎麼決策呢？以下是一些比較好的實踐：</p>
-<h4 id="heading-12">在用之前先研究測試</h4>
+<h2 id="heading-12">在用之前先研究測試</h2>
 <ul>
 <li><strong>快速測試</strong>（<a href="https://en.wikipedia.org/wiki/Spike_(software_development)">Spikes</a>）－依靠自己的經驗而非別人寫的文章。在你下決策之前，花一到兩天用新技術建造一個新功能的原型。讓團隊一起來分析利與弊。有時候你會想要把團隊拆成幾個小組，各自選定一個在同領域不同的新技術製作原型，然後來比較優劣。</li>
 <li><strong>黑客松</strong>是一個讓團隊熟悉如何取捨各種不同技術的好環境。花個一兩天讓團隊成員去嘗試各種看起來很誘人的新技術，可以讓他們學會如何靠經驗下聰明的決策。</li>
 </ul>
-<h4 id="heading-13">什麼時候下手？</h4>
+<h2 id="heading-13">什麼時候下手？</h2>
 <ul>
 <li>原則上是<strong>投資報酬率很高的時候</strong>就下手。很多技術都是為了要解決特定問題而產生的。你有一樣的問題嗎？這個問題很嚴重嗎？用了會省下很多時間嗎？花在重寫跟學習的成本能回收嗎？如果起步的開發速度會剩下一半可以接受嗎？如果慢到四分之一呢？這樣還值得嗎？</li>
 <li><strong>好團隊可以讓你做更多嘗試</strong>－有些團隊就是能比其他團隊更快交付，當事情一成不變的時候他們也會更快厭倦。這種團隊能更頻繁地試用新技術，但不能因為這樣就略過黑客松跟快速測試這兩個技巧。反而言之，如果團隊連正常交付都有問題了，那就要謹慎為之。</li>
 </ul>
-<h5 id="heading-14">雇用對的人</h5>
+<h2 id="heading-14">雇用對的人</h2>
 <ul>
 <li>有<strong>扎實技術背景</strong>的人是你的好朋友－知道越多範式（Paradigms）、對程式理論（例如演算法、平行處理）越熟悉、或是有好的工程素養的人通常比較不會跟風。</li>
 <li><strong>經驗</strong>－通常越年輕的開發者越容易一窩蜂。見過不同技術來來去去甚至自己被一窩蜂咬過的人做決策會比較平衡。</li>
diff --git a/posts/index.xml b/posts/index.xml
index 00b4841..e2b1985 100644
--- a/posts/index.xml
+++ b/posts/index.xml
@@ -53,7 +53,7 @@
       <pubDate>Tue, 07 Feb 2017 16:53:42 +0000</pubDate>
       
       <guid>https://chunfuchao.com/posts/hype-driven-development/</guid>
-      <description>&lt;p&gt;原文：《&lt;a href=&#34;https://blog.daftcode.pl/hype-driven-development-3469fc2e9b22#.setimjcqj&#34;&gt;Hype Driven Development&lt;/a&gt;》，感謝原作者 &lt;a href=&#34;https://blog.daftcode.pl/@marekkirejczyk&#34;&gt;Marek Kirejczyk&lt;/a&gt; 授權 &lt;a href=&#34;https://twitter.com/marekkirejczyk/status/827437538071674881&#34;&gt;翻譯&lt;/a&gt;，感謝 CH Huang、Yi Jeng Lin 協助勘誤。轉載請附上原文連結與出處。&lt;/p&gt;
+      <description>&lt;p&gt;原文：《&lt;a href=&#34;https://blog.daftcode.pl/hype-driven-development-3469fc2e9b22#.setimjcqj&#34;&gt;Hype Driven Development&lt;/a&gt;》，感謝原作者 &lt;a href=&#34;https://blog.daftcode.pl/@marekkirejczyk&#34;&gt;Marek Kirejczyk&lt;/a&gt; 授權&lt;a href=&#34;https://twitter.com/marekkirejczyk/status/827437538071674881&#34;&gt;翻譯&lt;/a&gt;，感謝 CH Huang、Yi Jeng Lin 協助勘誤。轉載請附上原文連結與出處。&lt;/p&gt;
 &lt;p&gt;軟體開發團隊時常靠偏見、社群媒體上的消息、或者只是看什麼東西最「夯」來決定要用什麼架構或是技術。而非扎實地研究與衡量這些東西對專案會造成什麼樣的影響。我把這叫做「一窩蜂驅動開發」（Hype Driven Development），我認定這樣是有害的也建議開發者們改採更專業的「務實軟體開發」（Solid Software Engineering）。我會解釋這一切是怎麼發生的，還有怎麼避開這個問題。&lt;/p&gt;</description>
     </item>
     
diff --git a/posts/why-attending-game-developers-conference/index.html b/posts/why-attending-game-developers-conference/index.html
index d67ab0d..a6ed909 100644
--- a/posts/why-attending-game-developers-conference/index.html
+++ b/posts/why-attending-game-developers-conference/index.html
@@ -106,7 +106,7 @@
 <p>再來就是到了 GDC 還是會多少有藏私的情形，遊戲設計或是美術方面可能比較少。程式類就很常只說個大概，好像這樣做就解決了。但是你自己依樣畫葫蘆就會遇到參數要怎麼調、寫出來效能爛到不行不知道怎麼優化等等問題。被玩過幾次後來我幾乎都不聽技術演講。</p>
 <p>當然還有玩、逛展覽、拿贈品、找工作這些比較附加的東西。但如果說要玩的話，說不定舊金山本身比 GDC 好玩。有一次在領入場證的時候遇到一群操台灣口音的人，上前攀談知道是國內某大廠的幹部們。聊著聊著他們就問起舊金山有什麼好玩的，跟他們大概說明像漁人碼頭、金門大橋之類的觀光客景點後，他們就直接離開會場去觀光了。</p>
 <p>我自己覺得如果真的去到 GDC 現場，重要的事情有兩個，一個是看看別人是怎麼看待遊戲製作的、一個是去建立人際關係。</p>
-<p>感覺在台灣說到遊戲製作，不免就是談論製程、行銷、哪一家公司代理了哪家國外廠商的東西、或是問別人公司的八卦。當然 GDC 也有這些東西，但還有很多自己想都沒有想過的討論，像是<a href="http://www.gdcvault.com/play/1022362/We-Suck-at-Inclusivity-How">阿拉伯母語的開發者教大家怎麼說正確的阿拉伯文</a>、<a href="http://www.nocrusts.com/#!guide/c1dhs">遊戲開發者突然成為人父人母要怎麼辦</a>、<a href="http://www.gdcvault.com/play/1020034/Performative-Game-Development-The-Design">你可以實況你的遊戲開發過程嗎？</a>、<a href="http://www.gdcvault.com/play/1017828/Experimental-Gameplay">實驗性的遊戲玩法可以做到怎樣</a>、<a href="http://www.gdcvault.com/play/1017963/Obsessive-Compulsive-Development-Retro-Grade">有精神疾病困擾的人怎麼一邊做遊戲一邊跟疾病共存</a>。你會發現遊戲製作做為每個開發者人生的一部分，還有這麼多自己沒有想過的面向。</p>
+<p>感覺在台灣說到遊戲製作，不免就是談論製程、行銷、哪一家公司代理了哪家國外廠商的東西、或是問別人公司的八卦。當然 GDC 也有這些東西，但還有很多自己想都沒有想過的討論，像是<a href="http://www.gdcvault.com/play/1022362/We-Suck-at-Inclusivity-How">阿拉伯母語的開發者教大家怎麼說正確的阿拉伯文</a>、<a href="https://www.gdcvault.com/play/1017779/GDC-Microtalks-One-Hour-Ten">遊戲開發者突然成為人父人母要怎麼辦</a>、<a href="http://www.gdcvault.com/play/1020034/Performative-Game-Development-The-Design">你可以實況你的遊戲開發過程嗎？</a>、<a href="http://www.gdcvault.com/play/1017828/Experimental-Gameplay">實驗性的遊戲玩法可以做到怎樣</a>、<a href="http://www.gdcvault.com/play/1017963/Obsessive-Compulsive-Development-Retro-Grade">有精神疾病困擾的人怎麼一邊做遊戲一邊跟疾病共存</a>。你會發現遊戲製作做為每個開發者人生的一部分，還有這麼多自己沒有想過的面向。</p>
 <p>這些東西當然也都跟技術演講一樣有錄影或是報導，但是我總覺得不是現場聽，現場近距離觀察有想法的人，受到的衝擊跟後來的反思都不會這麼大。就像唸書的時候總是會有各個學校的「強者」傳說流傳，但是真正會震撼到、影響到你的都是跟你同一個學校會面對面的。</p>
 <p>另一個到現場才能做的事情就是建立人際關係，我本來想用 Networking 這個英文字。這個字比較專指建立對自己職涯有利的人際關係，像是跟人資要到聯絡方式或是加 LinkedIn 之類的。但是想想覺得這樣太偏頗，不能涵蓋所有在 GDC 的人際互動。</p>
 <p>去第一次 GDC 之前有前輩說 GDC 期間舉辦的 Party 才是 GDC 的本體，我一開始覺得這實在是沒有道理。Party 就是跟一堆年輕人聚在一起咚滋咚滋，談的也就是找第一份工作、學生專案之類的東西，怎麼會比 Conference 重要？但是後來我才了解這句話的意思，Party 真的是最重要的活動，只是你去的 Party 不夠格所以沒有機會跟重要的人打交道。</p>