READr 提倡開放與協作，這不只是針對讀者，也包括新聞團隊內的所有成員，因此工程師很早就參與在改版的過程中——從天馬行空的構思，經過反覆的使用者測試，收斂到具體的功能規劃，我與其他成員一起嘗試從目標讀者的角度來理解一個媒體網站應該長什麼樣。
要說工程師在前期的改版流程中能有什麼樣獨特的貢獻，就是當在討論、決定網站的具體功能時，工程師能從實作面說明一個功能的難度，並提供一些替代選項，讓產品經理能從一個比較合理的基礎來評估時程及功能開發的優先順序。
如果某個功能的難度過高，就要再經過更嚴謹的使用者訪談或原型測試，以免花費大把心力，開發出根本不是讀者想要的功能。
選型：衡量團隊需求選出適合的技術方案
進行到實作階段，便是工程師大顯身手的時候了。首先是選型，選型就是從多種技術方案中，衡量利弊，根據業務需求及團隊狀況，選出最適合的技術方案。
接著，該怎麼將網頁算繪（render）至瀏覽器上？大致上有四種方案：靜態算繪（Static Rendering）、用戶端算繪（Client-Side Rendering）、伺服器算繪（Server Rendering）、同構算繪（Universal Rendering）。
READr 有大量的文章，要為這些文章都生成一個單獨的 HTML 檔，顯然不太可行，因此可先排除靜態算繪方案。
再來，READr 有自己的內容管理系統（CMS），文章都需要打 API 才能取得，使用用戶端算繪對 SEO 不利。且隨著 READr 功能愈加愈多、JS 檔愈變愈肥，網頁性能將會大幅下降，難以擴展。
學習新工具需要時間，但由於我們早已慢慢地將鏡週刊原有的程式碼用 Nuxt 重寫，大家都對這個框架有一定的掌握，成本因此不高；反之，它能夠提升團隊的開發效率。
大主軸確定了，接下來是選型的細節。
要不要寫測試呢？鏡週刊的網站有寫，但考量到 READr 的產品性質，可能這個禮拜上線的能，下個禮拜就拿掉了，寫測試有點冗贅，而且會大大拖慢開發速度，因此就決定不寫了。
另外，在 READr 改版之際，Vue 3.0 也正在如火如荼地開發中。從維護鏡週刊網站的經驗，讓我相當認同 Composition API RFC 對於 Options API 提出的批評，也深受 Composition API 的承諾所吸引。由於 READr 沒有支援 IE 的煩惱，加上 Nuxt 官方社群也有提供相關套件，因此我便決定引進，以提升程式碼的可讀性與複用性（Vue 3.0 快出來啊~）。
開發：早點發佈、不要通靈
在時間壓力下開發實驗味較濃的網站，思緒大抵就是在「可維護」與「快速」之間來回擺盪。
該不該元件化呢？該怎麼取名呢？該怎麼組織原始碼呢？該不該把這個部分抽取成一個函式呢？
有需要想這麼多嗎？這個東西未來應該不會被複用吧？要花時間重構這段代碼嗎？不是有句話這麼說：過早的最佳化是萬惡之源？但，怎樣才算是「過早」呢？
以下是我在痛苦又快樂的掙扎中，暫時總結出的幾個原則：
- 時間有限時，優先開發新功能
- 針對目前可預見的未來準備代碼複用，不必設想太遠，因為產品發展往往不是你原本想像的那樣
- 用備忘錄記下程式碼散發異味之處，有空時再回過頭來重構
- 針對需求、設計不明確的功能，先找人問清楚，再開發
簡而言之，盡快讓功能上線、東西沒壞就先不要修；不要對未來通靈、不要對需求通靈，能找得到人問就問，找不到人⋯⋯再通靈（但目前還沒遇到啦）。
工程師的職責是讓使用者愈少意識到我們的存在
開發新功能很有趣，維護一個中大型網站則很刺激。未來 READr 的功能會愈加愈多（或許也會砍掉很多？），網站也會愈來愈難維護。身為一名工程師，責任就是讓使用者愈少意識到我們的存在愈好（「吼工程師！網站又壞掉啦！」），讓讀者每次都能順暢、開心地體驗整個網站。