在昨天的介紹中，我們其實發現這個系統已經能正常完成日常的核心工作。

也已經運行了不少年。

在上一篇我留下了一個問題：

這套系統究竟是怎麼設計的？

但在開始拆解它之前，我們需要回答一個更基本的問題。

既然還能用，為什麼我們要重寫？

假設今天老師想要發布一則廣播：

老師打開電腦，新增一則廣播，貼上內容、加入附件後送出。

到這邊一切都是這麼的順利。

如果今天老師拿的是手機呢？

老師打開手機，在螢幕上戳戳戳。

由於網頁上的文字很小，老師需要用兩根手指把畫面放大，把層狀的功能表一一點開。

系統中有許多按鈕的尺寸是極小的。

在電腦上的操作是不困難的，但在手機的情境上會變得十分不方便。

如果老師使用的是 IE 呢？

不對這可能是它的主場。

好，那如果老師使用的是 Safari、Firefox，或其他現代瀏覽器呢？

如果今天學生在回覆時輸入了一段 script 呢？

如果學生不知道需要重新刷新網頁才能看到新的廣播呢？

單獨看每一個問題，每一個問題都是一個問題。

好啦不鬧了 XD

以上的所有問題，單獨看都是小問題。

但當使用的裝置、瀏覽器、內容發布方式，甚至 Web 的安全環境都與 20 年前有所不同時，問題就開始一個一個冒出來。

所以真正值得問的或許不是「它還能不能用」，而是：

一套用了 20 年的系統，為什麼還需要重寫？

但我認為在探討這個問題之前，我們應該先來思考：

是什麼造成了這些問題？

1. Client 與使用情境越來越多元

   20 年前桌機幾乎是這套系統需要服務的唯一對象，但如今手機、平板等裝置，也早已成為我們日常使用 Web 的重要途徑。

   舊的版面沒有為這些裝置設計，「功能能運作」≠「功能現在依然好用」。

2. 內容發布方式的改變

   舊系統在發布廣播時，如果想要調整文字樣式或排版，就需要直接接觸 HTML。

   但現在已經有 WYSIWYG （所見即所得） 編輯器了，使用者可以直接操作介面來完成排版，不需要知道背後產生了什麼 HTML。

   使用 WYSIWYG 編輯器除了能降低排版門檻，也可以避免把 HTML 編輯直接暴露給一般使用者。

   呃當然，編輯器產生的內容仍然需要經過適當的過濾與驗證。

   並不會因為你用了 WYSIWYG 編輯器，漏洞就自己不見了。

   而對老師而言，基礎網頁開發也不應該成為發布廣播需要的能力。

3. Web 的安全模型在改變

   在這 20 年間，Web 的功能越來越複雜，攻擊方式與防禦實務也不斷演進。

   一些今天看來理所當然的防護，在當年的環境中可能還不是一個普遍的做法。

   但一套長期運作的系統，也仍需要持續面對當前的安全需求。

但看到這裡可能會有另一個問題：

既然知道問題在哪裡，把它修掉不就好了嗎？

其實可以。

手機若是不好操作，可以調整版面；

撰寫廣播樣式不方便，可以引入 WYSIWYG 編輯器；

廣播不能及時出現，可以加入 SSE 或 WS；

發現資安問題，也可以一個一個補起來。

但在系統所有的零件都修了一遍之後，這個系統還是原來的那個系統嗎？（忒修斯：啊？還有我的事？）

好啦其實就是我自己想嘗試做一個新版。

但是我們要解決的問題依舊沒有改變：

我們依然得回答：「師生間的訊息在校園裡應該如何傳播」這個問題。

老師依然需要發布廣播、加入附件；

學生依舊需要登入系統、查看廣播；

原本已經習慣的使用方式，也不用為了「用了新技術」而全部改掉。

真正需要重新思考的，是這些功能底下的實作方式。

也就是接下來這三周，我需要回答的問題。