蠻有趣的詞：「低代碼」。
簡單的說，原本要完成一件事需要 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, 讀書會，就希望他們具有團隊學習能力，甚至學習型組織，會不會太樂觀了一點？
