對不了解系統上線流程的人來說，他們會覺得這不過就是個小調整，為什麼每次都要我三催四請的？

對開發的工程師來說，他們會覺得這些人有完沒完啊？這些文字不是都已經討論過了，為什麼每隔幾天，甚至幾小時就要改一次？

實際上，改動文字對工程師來說可能花不到 1 分鐘的時間。

但對有上版流程的公司來說，每次更新可能都要花 1 小時以上（就算只有改一個字）。

今天這篇文章不是要談誰對誰錯，或是如何用技巧來迴避問題；而是要分享面對問題時，可以如何一步步「解決」他。

文章寫完後，感覺自己在寫技術發展史；另外，這是朋友向我分享的經驗，絕對不是我自己的。

石器時代：寫死在程式碼

在最遠古的時期，網頁上的文字是寫死在程式碼的。

雖然直觀，但維護性極低。

因為面對「修改文字」的需求變更，開發人員可能改了 A 頁面，卻忘了還有 B、C、D 等頁面也用到一樣的詞彙。

大航海時代：建立語言包維護

如果系統只用同一種語言，那寫死在程式還勉強能維護。

但如果接下來要進軍國際市場，有中、日、英、法等多國語系的需求時，我想工程師就會崩潰了。

因為寫死在程式碼是完全行不通的，雖然很痛苦，但開發人員會需要把系統中所有的文字抽出來，建立「語言包」來維護才能解決這個需求。

這樣未來在面對「修改文字」的需求變更時，開發人員只要在單一檔案處理，透過模組化的管理，可以大幅降低遺漏的可能性。

工業時代：提供 Google Sheet 讓產品方填寫

把文字集中到語言包維護後，其實面對修改文字的需求就很容易處理了。

但…接下來要討論的是「人」的問題。

因為產品方會一直看系統的文字，看著看著可能就覺得哪裡不順眼，不順眼就要改！

所以在新版本上線後，可能一週內會收到多次文字變更的需求。

在這樣的狀況下，現實生活中最容易遇到的就是「漏訊息」；當訊息有前後因果關係、重複資訊的時候，失誤在所難免。

為了減少產品方打擾 PM 與工程師的頻率，以及減少訊息遺漏的問題。

提供一份格式律定好的 Google Sheet，讓產品方在線上「修改文字」是一個不錯的方案。

這樣雙方約定一個時間一次性更新即可（會跑一個將 Google Sheet 轉成語言包的腳本）。

科技時代：直接透過管理介面修改文字

改成 Google Sheet 後，雙方和平了好一段時間。

但還有一個問題，那就是這種修改沒有「即時性」。

因為程式每次上版都需要 Build Docker Image、跑回歸測試、上多個環境確認…

你可以理解為這些步驟至少要花費一小時以上的時間，而且會涉及到不同團隊的人（開發、QA、PM…）。

如果今天只是要修改文字，這樣的操作完全不符合成本效益。

所以目前的最新方案，就是在後台管理介面中，新增修改文字的功能，讓產品方可以依照自己的需求即時進行調整（搭配預覽頁）。

總結

修改文字是一個常見的需求變更，而且很多時候是在系統上線後才發生。

對工程師來說，修改文字這件事的確很簡單，但背後所需花費的時間與人力成本其實很高。

相信看完這篇文章後，大家可以理解為什麼有些小變更需要等一段時間才能更新。

儘管這篇不是純粹的技術文，但還是提醒一下讀者，每個時代的演進都需要不少時間成本。

這些改進所用到的技術並不困難，但問題在於：

• 有足夠多的時間來做優化嗎？
• 這個問題真的有優化的必要性嗎？
• 優化帶來的效益符合成本嗎？

因此千萬不要看完這篇文章後，就拿他去跟工程師吵架，我可不背這個黑鍋。

也許最後的方案在不久後會遇到其他挑戰，但這不就是「有問題我才有工作嗎？」