大綱
ㄧ、別談技術，先來看看筆者發生的蠢事
二、也許不是關關難過，而是從沒看過
三、如果方向是錯的，那離目標會越來越遠
四、總結

ㄧ、別談技術，先來看看筆者發生的蠢事

筆者過去購買家電時有個壞習慣，就是幾乎不看說明書；總覺得憑藉自己的理工頭腦可以輕鬆駕馭這些產品。

儘管大多數的狀況下我都能無師自通，但現實生活總是會找機會賞你幾個巴掌，有時我沾沾自喜的用法，過一段時間才發現根本是錯誤的。

就拿吸塵器來舉例好了，現代的吸塵器往往是多功能的，吸地、吸床單、吸鍵盤各有不同的吸頭；自以為聰明的我，認為吸附面積最大的頭一定是拿來吸地板的，但用了一陣子後總覺得馬力不夠，地板上常常有灰塵很難吸起來。

此時我去看說明書才明白，原來我一直拿吸床單的頭來吸地板！？儘管這樣也能使用，但卻無法發揮出每個吸頭應有的功效。

會發生這個蠢事，就是因為我覺得這個東西很簡單，沒必要看說明書。

二、也許不是關關難過，而是從沒看過

現在的技術日新月異，很多時候開發人員真的沒時間慢慢看文檔。

如果今天的需求較為簡單，那可能用套件的範例程式就能解決；但萬一需求較為複雜，那勢必要更深入的研究套件。

理論上是這麼說，但實際上有不少工程師，是選擇投入大量精力在魔改基礎的範例程式，而非去深入閱讀官方文檔。

就拿前端（Vue.js）來舉例，框架提供的 Component 有很多的 Props 可以使用；但很多人會選擇自己用 watch、computed 刻出一樣的功能。

一個問題往往有多種解決方案，但站在筆者的角度，除非框架沒有提供 Solution，不然盡量不要自己手刻，這些多餘的程式碼會導致日後的維護更加困難。

遇到需求請先閱讀官方文檔，很多時候有更省力的解決方案。

三、如果方向是錯的，那離目標會越來越遠

如果你人在台中，接下來打算前往台南；但車子卻一直往北開，你認為什麼時候才會抵達目的地？

前兩個案例，我們只是在解決問題的路上多花一點力氣；但在這個案例，是整個團隊白費力氣。

幾年前筆者曾選擇 Adonis.js 這個 Node.js 的框架來開發後端，前期開發的很順利，但隨著專案結構越來越複雜，我們發現這個框架缺少許多實用的功能，甚至還遇到不少需要等待作者維修的 Bug。

儘管當時已經使用它開發了 3 個月，但最終開發團隊還是決定忍痛放棄，跳槽到其他穩定的框架；而這次的失誤，導致系統架構要重新設計，不少程式需要重新撰寫。

會發生這個慘劇，是因為貿然選擇了一個不夠成熟的框架，且事前評估不足就直接投入開發。

四、總結

古人是因為缺少前人的經驗，才需要靠自己試錯來尋找答案。

現在資訊這麼發達，大部分的坑都有前輩幫你踩過了，沒必要親自去體驗。

儘管讀文檔要花費不少時間，但在很多時候它可以幫你解省更多時間。

磨刀不誤砍柴工，古人的話別當耳邊風。

你是十八般武藝樣樣精通，還是樣樣通樣樣鬆？

工程師真的很難，會得不多會被問為什麼沒學，會得很多還要被質疑專業程度；這種比較類型的問題，除非你有事先做功課，不然就算你都會用也未必能在現場對答如流。

大綱

1. 你會的後端框架不只一個，可以說明一下它們之間的差異嗎？
   • 1.1 面試官為什麼會問？
   • 1.2 面試官想從答案確認什麼？
   • 1.3 筆者提供的簡答
2. 回答問題所需具備的知識
   • 2.1 PHP VS Node.js
   • 2.2 用 supervisor 讓 Node.js 熱更新
   • 2.3 不一定要拼個誰輸誰贏
3. 衍伸問題
   • 3.1 既然你先學了 Node.js 的框架，為何後來改用 PHP 的框架？
   • 3.2 使用框架有什麼好處跟壞處？

1. 你會的後端框架不只一個，可以說明一下它們之間的差異嗎？

1.1 面試官為什麼會問？

因為履歷資訊中顯示求職者會如下的後端（Backend）框架：

• PHP：Laravel
• Node.js：Express.js、AdonisJS

當你會的東西多，面試官就會想了解你是每個都學一點，還是真的了解它。

1.2 面試官想從答案確認什麼？

• 能否簡單敘述 PHP 與 Node.js 的差異
• 舉例過去用這些框架做過哪些專案或是功能
• 為什麼會學習新的框架

1.3 筆者提供的簡答

之前使用 PHP 的 Laravel 框架開發過內部管理系統，也曾用 Node.js 的 Express.js 框架完成過餐廳點餐系統。

兩者的差異主要因為程式語言而產生的，PHP 是同步語言、多執行緒，Node.js 是一個能執行 JavaScript 的環境，支援非同步，為單執行緒。

如果專案要求穩定一致的效能，我會偏向使用 PHP 框架；而如果要承接高流量，我會選擇 Node.js 框架。

2. 回答問題所需具備的知識

2.1 PHP VS Node.js

如果面對一個問題只有一種解決方案時，面試官會深入詢問這個技術；但如果面對問題有兩個以上的解決方案，他就會問你在不同情境下該使用什麼技術，每個技術都有各自的優勢，這邊我們就從不同的角度來做分析吧～

• 同步的 PHP vs 異步的 Node.js
  • 同步的 PHP 會為每個 Request 建立一個 thread，每個 thread 都會消耗記憶體，也就是說如果想要服務更多的客戶就要花心思在硬體設備上。
  • 異步的 Node.js 是非阻塞 (non-blocking) I/O 設計，搭配上 Event Loop 可以用一句很形象的話說明：「與其人多但好多人閒著；還不如一個人拼命往死裡做。」
• 多執行緒的 PHP VS 單執行緒的 Node.js

  • 多執行緒 (multi-threaded)的 PHP
    使用阻塞 (blocking) I/O 的設計

    PHP 可以為每個 Request 都開一個執行緒；如果你想要實現非阻塞也能透過 reactPHP 來實現。

  • 單執行緒 (single-threaded)的 Node.js
    使用非阻塞 (non-blocking) I/O 設計 + 提供非同步 (asynchronous) 處理

    Node.js 原則上是單執行緒，但可以透過 PM2 的 Cluster Mode 達到多執行緒。

• 應用場景
  從 Client 端與 Server 端的溝通頻率來做分析：
  • 溝通頻率不高
    PHP 是個不錯的選擇（ex：個人部落格，像 WordPress 就是用 PHP 寫的）。
  • 溝通頻率頻繁
    Node.js 更能激發性能（ex：single-page-application、聊天室）；它適合大吞吐量的系統，較不適合需要大量 CPU 運算的系統。
• 可使用的資源

  • PHP 有 Composer
    Composer 的命名方式：「所有者/package 名稱」

  • Node.js 有 NPM
    NPM 的命名方式：「package 名稱」

    因為 NPM 的命名方式太自由，導致上面有很多的資源都是無效資源，關鍵字第一個找到的未必是最合適的。

• 人才市場
  • 人才數量
    PHP 比 Node.js 早了 10 幾年發行，因此市場上使用 PHP 的人比使用 Node.js 的人更多；如果職位流動性高，用 PHP 開發會比較合適。
  • 薪資
    物以稀為貴，同樣都是新人，會 Node.js 的薪水會略高於會 PHP 的求職者。
• 專案容量
  用 Laravel 跟 Express.js 來比較：
  • 專案初期
    一開始 Laravel 因為包山包海所以專案體積較大。
  • 專案後期
    儘管 Express 是 Node.js 輕量級的框架，但因為實作過程往往要擴充一堆 package，而且一個 package 往往會有很多的 dependency；這些原因容易導致最終實作出來的是一個笨重的專案。
• 程式語言轉換
  除非你的運氣逆天，每次都剛好找到符合你技能樹的公司，而且這間公司專案用的技術還很固定；不然肯定要面對程式語言的轉換，這邊分享幾個轉換時要注意的重點。
  • 找類型相似的框架
    從 PHP 跳到 Node.js 一定會面臨諸多不適應；但如果你選擇的是跟 Laravel 很類似的 AdonisJS 框架，這份不適感會下降許多，反之亦然。
  • 語言語法
    如果你已經熟悉了一種程式語言，我覺得轉換到另外一個語言的學習成本不會太高；但許多內建函式都要重新學習、生命週期也要重新熟悉、錯誤處理的經驗也要重新累積。
  • 專案規模
    如果是只需要 CRUD 邏輯的小專案，那我覺得藉此多瞭解一門程式語言是一個很棒的機會；但如果面臨的是業務邏輯複雜的大專案，我強烈建議一定要選自己熟悉的程式語言，或者團隊中的扛霸子熟悉這門語言；不然出事根本沒人可以救得了。
• 效能
  • 響應速度
    Node.js 靠著 V8 引擎加上非同步的特型，擁有較快的響應速度。
• 面對錯誤的處理

  • PHP 遇到某個 Request 錯誤時，它只對這個 Request 產生影響。

  • Node.js 因為所有 Request 都在單執行緒的 Web-server 中，所以某個 Request 導致的未知錯誤就可能影響到整個 Server。

    不過這塊可以透過 PM2 的 Cluster Mode 與自動重啟來補救。

• 熱更新
  • PHP 修改後，只要刷新頁面就能看到。
  • Node.js 預設沒有熱更新，需要關閉專案後重啟。

2.2 用 supervisor 讓 Node.js 熱更新

在開發階段推薦使用 supervisor 這款套件。

• STEP 1：在全域安裝套件npm install supervisor -g

• STEP 2：建立一個myapp.js的檔案，並複製貼上下面程式

  var http = require("http");
  http
    .createServer(function (req, res) {
      res.writeHead(200, { "Content-Type": "text/plain" });
      res.end("Hello World!");
    })
    .listen(3000, "127.0.0.1");
  

• STEP 3：用node myapp.js啟動程式後，修改res.end("Hello World!");的內容；再刷新網頁後內容不變。

• STEP 4：改用supervisor myapp.js啟動程式，修改res.end("Hello World!");的內容；再刷新網頁後內容更新。

supervisor 也可以做專案資料夾的監控，但是要記得排除一些資料夾（ex：儲存 log 檔的）；否則你的專案就無時無刻在重起了。

如果是正式的網站且流量大，建議使用 PM2 來做處理，它也有監控資料夾的功能。

2.3 不一定要拼個誰輸誰贏

存在即合理

• 小專案不用花太多時間在評估框架及程式語言選擇上
  有些公司對專案要用什麼框架以及程式語言保持著非常謹慎的態度，謹慎的態度是對的，但也要考量到專案的規模；如果今天的專案就是 CRUD 的簡單應用，預估使用者數量不多或是主要來自於內部成員，用什麼框架及程式語言其實都差不多。
• 看組織成員擅長的語言
  如果公司高層為了追求潮流而要求開發人員用一個不熟悉的框架去做專案，他最好祈求專案上線後平平安安；不然出事了公司沒有能夠處理的人才，沒有人會在意一個不能用的網站效能有多好。
• 每個程式語言都有自己的擁護者
  在不同的條件下，每個程式語言都有自己的優勢，而且每年都會誕生新的框架與程式語言；筆者覺得與其不停盲目追逐新的技術，不如先深入研究一個成熟的技術，當你有辦法靠它解決各種現實難題時，再去學新的框架跟程式語言也不晚。

3. 衍伸問題

3.1 既然你先學了 Node.js 的框架，為何後來改用 PHP 的框架？

考點：這題其實是想了解求職者的人格特質

這兩個都是為了解決問題的技術，我一開始用 Node.js 的 Express 框架獨立完成了幾份專案；但後來有一個需要 Team work 的大型專案，因為當時的組長比較熟悉 PHP 的 Laravel 框架，所以我便藉由這個機會學習新的技術；也因為這次的技術轉換，讓我了解不同框架在部署以及效能各方面的差異。

我想透過上面的回答給面試官幾個訊息：

• 我能獨立完成專案，也可以團隊合作。
• 我願意學習新技術。
• 學習的同時會分析不同框架的優劣。

3.2 使用框架有什麼好處跟壞處？

考點：確認求職者對框架的認知

• 好處
  框架能夠讓初學者快速入門並開發出有一定水平的專案，因為框架提供了許多常用的函式，因此可以大幅縮短專案時程；在團隊協作上框架優勢更為明顯，能夠讓成員有一致的開發方式。
• 壞處
  因為框架已經幫開發人員做了太多事情，這會導致開發人員並不理解許多功能的原理，這也造成了一但框架無法滿足功能，初學者的生產力會斷崖式下降；如果長期使用，也容易讓自己的開發思維被限制在框架內。

筆者碎碎念

希望讀者不要只把我提出來的問題當成面試會出的考題；當面試官會這樣詢問時，通常是因為實務上也會遇到類似的問題。

感謝大家的閱讀，如果喜歡我的文章可以訂閱接收通知；如果有幫助到你，按Like可以讓我更有寫文的動力，我們明天見～

參考資源：

1. PHP + Apache Stack vs Node.js
2. 服務端 I/O 效能大比拼：Node、PHP、Java、Go
3. 簡析 Node.js 特點與應用場景
4. 詳細版 | 用 Supervisor 守護你的 Node.js 進程
5. 淺談 Node.js 和 PHP 程式管理

在許多人的幫助下，本系列文章已成功出版，除了添加新的篇章，更完善了每個案例的應對進退；如果對現在的職涯感到迷茫，也許這本書能帶給你不一樣的觀點～

天瓏書局： https://www.tenlong.com.tw/products/9786263334571

CSR - Client-Side Rendering（客戶端渲染）
  ➤ 優點
  ➤ 缺點
  ➤ 應用場景
SSR - Server-Side Rendering（伺服器端渲染）
  ➤ 優點
  ➤ 缺點
  ➤ 應用場景
可以思考的問題
  ➤ 現實面遇到的狀況
  ➤ 運用框架結合 CSR 與 SSR 的優點讓網站取得雙贏

CSR — Client-Side Rendering（客戶端渲染）

渲染過程全部交給 client 的瀏覽器去處理，server 不參與任何渲染。一開始的 HTML 是空白的，需要等待 JS 下載並執行後瀏覽器才會顯示畫面。

優點：

• 減少 server 端的壓力：因為 JS 及 CSS 在第一次都已經發送到 client 端，之後只需要向 server 端取得相關頁面的 data 即可
• 頁面切換速度快：因為 HTML 頁面都是 client 端自己編譯的，所以頁面切換時不需要像 SSR 等待 server 回傳 HTML；而且網頁內容的改變通常都是局部的，這樣就避免了不必要的跳轉及重複渲染。

缺點：

• 首屏顯示慢：明明首頁只有一點內容卻把下載了所有頁面的資源
• SEO 較差：因一開始的 HTML 是空白的，雖然現在 Google 的爬蟲也會等 javascript 編譯好再爬，但這塊對 SEO 的實際幫助還需要時間驗證

應用場景：

• 會高頻操作且不需 SEO 的網站：像是內部管理系統，如果這類型的系統採取 SSR 會造成 server 端很大的負荷。

SSR — Server-Side Rendering（伺服器端渲染）

HTML 由 server 編譯出來返回 client 端，所以 client 看到的畫面就是最終版 HTML。

優點：

• SEO 排名更高：因為 Google 爬蟲可以直接抓到網站的資訊
• 首屏渲染快：因為不需要下載一堆 JS 以及 CSS 執行後才看到頁面
• 減少 client 端的耗電量：因為編譯的步驟都在 server 端執行

缺點：

• server 端承受比較大的壓力：由於頁面都是在 server 端進行編譯，在高併發場景中會消耗相當大的資源

應用場景：

• 低頻操作但需要 SEO 優化的網站：像是媒體類型的網站，因為文章需要被搜尋到，我們看一篇文章也需要一點時間很少高頻的操作這個網站

可以思考的問題

現實面遇到的狀況

在 CSR 的狀況下如果某個頁面需要同時存取多個 api，假設 client 端的網速不理想，那使用者的體驗會極差；在這種情況下 SSR 會因為 server 環境相對穩定而獲得相對好的使用者體驗。

運用框架結合 CSR 與 SSR 的優點讓網站取得雙贏

經由上面的分析，我想大家應該已經感受到 CSR 與 SSR 可以說是性質完全相反的渲染了，所以實際應用上我們通常會讓第一個頁面用 SSR 來爭取更高的 SEO，其他的頁面則採用 CSR 的方式來操作給使用者兩好的體驗。

現有的框架： Nuxt.js（Vue）、Next.js（React）都有很好的解決方案

以上是我個人針對 SSR、CSR 技術的理解，如果有理解錯誤的地方希望有大神給予指教，感恩不盡～