關於前端工程的難點

最近一次面試，面試官問我一個問題：

你認為前端開發最困難的點是什麼？

當時我回答瀏覽器相容性問題：

每個瀏覽器的API支援程度不一，CSS引擎的實做機制也不一樣。這讓我吃了不少苦頭。比方說，之前有個專案，就因為某個設備沒有支援特定API，所以就花了更多時間在想出替代機制、還有解決替代機制所發生的錯誤。那專案，大概花了好幾個星期才解決。

當我反問「開發最困難的點」時，面試官回答除了相容性問題外，還有套件更新的問題。大概是因為 node npm 套件機制比較完善、加上我不輕易更新套件吧，我甚至有點不太感覺痛點何在。

面試後，我又想了這個問題。

瀏覽器相容性確實是大問題。但我其實想講另外一個問題：測試機制。

前端的手動測試非常難搞：你以為這裡你作對了，但在另外一邊卻會壞掉。可能你找了很久，卻發現問題在其他地方。專案越大，這種問題就越多、有時候可能還越致命。

那麼大家說的單元測試、自動化測試呢？

沒有。並沒有比較好做。

在純瀏覽器就不說了。就算是在擁有完整模組化開發的 webpack 下，要做各種斷言測試，你首先就要安裝各種斷言函式庫，並熟悉那些語法： expect, toBe, equal, throwError ……學習這樣的語法，首先就是一段學習曲線。

AJAX API 的非同步處理也很難做：如何驗證那些請求的參數有沒有對？如果後端沒有實做，你又要怎麼做？就算做成模塊，如何填充那些模塊，又是另一條崎嶇的學習之路。

這還沒完。就算你測試做成功了，在瀏覽器顯示又是另一回事。而且配上相容性問題，整個外觀呈現在某個設備、或單元測試沒問題，在另一個設備卻會顯示錯誤。這樣根本沒辦法確保每個地方都能正確呈現。如果要動用 Selenium, Nightwatch 或 Browerstack 之類的工具，欸，還要不要寫程式啊？

噢，我有說到其他套件的整合與整合測試嗎？

所以我每次寫測試，都覺得自己在寫另外一套程式；而且這個程式，甚至比程式本身還難寫：往往程式本身都對，問題卻都出在測試程式那邊。這種發生一多，我就對寫測試越來越無力。

至於如何改進這樣的問題，我原本想說寫自己懂的測試。無奈框架都有自己的邏輯要走，然後又卡在那邊……

所以，唉，算是個牢騷吧。