蠻有趣的詞：「低代碼」。

簡單的說，原本要完成一件事需要 programmer 寫的程式碼量，因為一些解決方案而有機會讓不太懂寫程式的人，透過設定或簡易一點的方式來完成一些代碼的設定，就能看到讓人「驚艷」的成果。

註：這個驚艷通常有一定的比例來自於「不懂寫程式的人」能做出「這樣的成果」

這一篇文章提到的低代碼是行業毒瘤，裡面一些論述點我蠻有共鳴的（有一些則是覺得並非該強調的重點），但這的確是個該留意的議題。

其實用 programmer 去寫程式完成某一項工作的成本是不低的。只是大家在這一行，身為這個角色，會覺得這不難，卻忽略了一樣的時間你可能可以創造更多其他的價值。（價值優先） 這也是類似 design thinking 中為何要用低成本先驗證可行性與價值的概念。

拉回來主軸，我自己過去對「低代碼」這類的擔憂，最常見的就是 Robot framework VS cucumber.

如果 enterprise application 產品夠大、夠複雜、夠重要，那其對應的自動化測試（尤其是 end-to-end）肯定也是同樣產品量級的測試系統。

與其總是想著讓一堆不會寫程式，尤其是「不願意學」寫程式的人，能用哪些方式少寫一些測試程式，最終付出的代價是，前期投入的成本都將毀於一旦。因為當產品越來越複雜時，測試程式也會越來越複雜。

甚至測試程式還會依賴許多 “DevOps” (developer + operation 的工作範圍）都得碰到的相關內容，例如用 docker 起一座 redis，例如怎麼清理與初始化測試資料。

越不想碰程式碼，最後就會一直繞路，或是把一些「限制」視為理所當然。那些事情對 developer 來說，可能就是平時的工作之一，但對不諳程式的測試人員來說就是天方夜譚。

越是這樣把職責角色分開的組織，他們的開發人員往往越是覺得測試是測試人員的工作，他們就是負責把關（甚至覺得他們是專門找碴的），我的工作是負責開發，不是測試。如果我去寫測試程式，那誰要開發？

所以退10步來看全貌，我們很常讓不會、不愛、不想寫程式的測試人員，試著去自動化測試。我們讓會寫程式的人員，覺得測試是測試人員的事，開發人員只要想辦法在時間內做完功能交付（往往品質低落）。

而我們真正希望的目標是產品交付能有比較好的品質，產品交付速度不會因為規模而導致交付時間冪次上升。

讓真正的「測試」人員（不是做那種已知的 check/validation）去做那些未知的、發散思維的探索，甚至讓他們結合 UX/UI 找到更好使用產品的動線與方式，讓他們產出並指導其他人來進行這些已知的 check 動作自動化（最好他們也願意參與、動手自動化的過程），讓開發人員有認知：產品就是我們的小孩，品質跟功能都是我們要 cover 的，開發跟測試是一體兩面的，我們對測試思路與角度的短板，團隊中能有專業的測試人員來互補。

我們能在開始動手開發功能之前，知道這樣的功能是為了給
1.「怎樣的使用者」
2.「解決怎樣的問題」
3.「帶來怎樣的好處」

而這樣的功能提供使用者「哪些使用的情境與方式」。

當我開發完功能之後，我至少能模擬出來各種使用者會碰到的使用場景，功能要如預期般運作。（白話一點，簡單一點，就是問後面把關的測試人員，如果這個功能做出來，你會測試那些東西、怎麼測，再把他講出來的內容，思考哪些動作跟環節可以自動化，這是一個合作的過程，往往因應搭配自動化，會需要微調他們的測試方式）

這中間當然就會應用到 #實例化需求，而這基本的概念才是 #測試左移 的原型。

議題跑得有點遠了，「低代碼」用對地方，就是事半功倍，用錯地方，就是在基礎建設埋了顆地雷，未來爆掉時付出的代價將相當艱鉅。

怎麼評估用對地方、用錯地方？

第一，核心的部分避免用低代碼思維去貪快走捷徑，總有一天要還的。

第二，讓懂得寫程式的人來決定哪些地方適合用低代碼，也讓他為未來衍生的代價負責。

第三，與商業價值的平衡。如果就是埋一顆地雷可以讓公司活下來，評估有著大量的商業價值值得冒險，那就找專業一點的人埋地雷，讓他評估未來抽換掉地雷時，不會導致整個大樓付之一炬。

—
另外一點就是關於招募的。

招了不想寫程式的人，再來想辦法改變他們，讓他們學寫程式，當然事倍功半。

因為他們不想寫程式，所以找一些低代碼的解決方案，可能是種飲鴆止渴。

就像找了一堆需要被管理的人進來，希望他們能自組織、自我管理，當然就擔心東擔心西。

然後再訂了一堆指標來衡量評估他們是否有認真工作，有產出對應得了薪水的價值。

再聘專門管理工作的管理者來管這些需要被管理的人。

如果源頭就是找到能自我管理的人，會不會省了很多「希望能改變他們」的動作呢？

找了一些不懂也不想，甚至也不會持續自我學習的人進來，然後希望弄點內訓、活動、team building, 讀書會，就希望他們具有團隊學習能力，甚至學習型組織，會不會太樂觀了一點？

今天帶來的是 CNCF 使用者科技雷達第四篇的介紹，這篇報導探討的是 Storage/Database 的調查報告

報告中顯示了六個最被大家推崇的解決方案分別是
1. Redis
2. Elasticsearch
3. PostgreSQL
4. MySQL
5. Memcached
6. Kafka

同時根據調查報告， CNCF 團隊觀察到公司對於 Storage/Database 的選擇是非常謹慎小心的，沒有必要不會隨便遷移解決方案。特別是當本來的資料已經達到 TB 甚至 PB 等級時，遷移帶來的成本非常巨大，如果新專案帶來的好處沒有辦法蓋過這些成本時，很難說服團隊去遷移。

詳細的報導介紹可以參考下列原文

https://www.hwchiu.com/cncf-tech-radar-storage.html

前一篇 (https://www.facebook.com/kewang.information/posts/2241503749459320) 提到了 Autocomplete 的實作方式，但仍然有許多可以調整的地方，像是如何加大 throughput、帶額外資料...等，下面就來分享一下小編的作法。

---

## 1. 減少傳輸量

因為 Autocomplete 的操作行為是使用者每打一個字，就要傳給 server，server 再回傳使用者一些 candidate。所以減少傳輸量是最先要處理的事情，要不然資料量太大傳輸慢會影響前端使用體驗。最簡單的作法就是改變原本回傳的 JSON 格式，如下所示：

### 調整前

[
{"id": 123, "candidate": "taipei"},
{"id": 456, "candidate": "taiwan"},
{"id": 789, "candidate": "tall"}
]

### 調整後

["123%taipei","456%taiwan","789%tall"]

前端拿到資料後自己再用 split 的方式分割字串，實測下來大概可以減少 40% 的資料量。

---

## 2. 減少傳輸量

沒錯！第二點也是減少傳輸量，將準備要回傳的資料用 gzip 壓縮後再回傳。

以 expressjs 本身建議的 compression 套件來說，實測下來發揮不了什麼作用。因為 compression 套件預設為資料量大於 1kb 才會做壓縮，而目前的資料已經是小於 1kb 了，所以沒做任何壓縮就直接回傳。

另外還發現加了 compression 套件之後，以目前開的 heroku 機器來說，回應時間會加上 5-10ms 左右。不過現在服務還沒上線，沒有使用量都不準，等上線之後再來觀察看看好了。

---

## 3. 減少使用者打 server 的次數

前端可以在輸入一個字元的時候不要送 request 給 server，因為經驗法則，使用者應該至少會打兩個字元之後，Autocomplete 回應給使用者 candidate，這樣對 UX 上應該會比較好吧 (小編不專業分析 XD)。不止可以降低 server 的 loading，也可以減少存入 Redis 的資料量。

但這會牽涉到 CJK 與 non-CJK 的處理方式，這就還要再看看如何處理比較好。

---

## 4. 減少使用者打 server 的次數

沒錯！又是減少次數。client 可以在 server 回傳資料的時候，將資料暫存在 client 的記憶體內。因為常會有輸入相同文字的時候，這時就可以直接從 client 的記憶體取出資料，就不用打到 server 了。

但這個使用方式比較不好處理，需視情境而定。若是 Redis 的資料常常在變動，那這個方式會造成取不回最新的資料。或許可以在 client 放個 LRU cache 來做處理。

---

## 5. 減少使用者打 server 的次數

又是我 XDDD！這次是要 server 幫忙，當 client 重複輸入相同 keyword 時，client 會帶 If-None-Match 的 header 給 server，server 會檢查這串值是否已經有打過了，如果打過就回 client 304，表示資料沒變動，可以直接用 client 本身的資料。

這在之前的 JCConf 有分享 (https://www.facebook.com/kewang.information/posts/2192127034396992) 過，大家可以回去翻一下。

---

## 6. 減少 Redis 的資料量

西方國家所用的拉丁字母除了大家常用的 26 個英文字母外，也常會有一些包括重音之類的字母。像是 a 及 á 之類的，這個在搜尋的時候不會太影響，JavaScript 可以利用 String.normalize('NFD') 把 á 轉換成 aˊ，最後再將 ˊ 取代為空字串 (https://stackoverflow.com/a/37511463/939212)，Redis 裡面只要存 a 就好，這樣可以節省不少資料量。

當然還有將大寫轉為小寫、trim 掉頭尾空白這幾種做法，也都可以省下不少資料量。

至於 CJK 的話，再說吧 XDDD

---

## 7. 存入 metadata

如果這個 Autocomplete 只是單純選擇 candidate 之後做搜尋，那可以不用存 metadata 進去。但有些功能其實是要把 candidate 回傳給 client 時，也帶一些 metadata 給 client 做其他運用，最常見的應該就是帶 id 這類 metadata 了。

最簡單的作法就是在存入 candidate 的時候，直接把要存的 metadata 帶在字尾，如下所示：

1. t
2. ta
3. tai
4. taiw
5. taiwa
6. taiwan
7. taiwan*123

把 123 放在 taiwan 後面，在取出 candidate 的時候再利用 split 的方式把 taiwan 跟 123 分別取出就可以了。

---

總結上面的幾種方式，目前小編這裡用到了 1, 2, 5, 6, 7 共五種，效果還不錯，就等上線再來看看實戰結果囉。

#funliday #autocomplete #redis #javascript #nodejs