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

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

本篇不是一個技術文章，而是一個 DevOps 招募主管的經驗談，隨者 DevOps 需求提升，愈來愈多人開始轉往這個方向。對於作者來說，要如何從茫茫大海中挑到正確的人選其實並不容易。
作者的公司會對所有的招募人員有個第一次的技術訪談，該技術訪談著重的都是一些基本技能，是一些第一天上工可能會用到的知識與能力，譬如 TCP/IP 網路概念， Linux 工具使用，儲存相關概念等。然而另作者感到灰心的是，很多人的履歷寫得洋洋灑灑非常厲害，什麼東西都有碰過都會，但是實際上去問對方該技術是什麼該技術什麼怎麼做，都沒有辦法準確有信心的回答，這樣反而會讓面試官覺得該履歷是個打腫臉充胖子的行為。

因此本文後續作者就整理了一些關於 DevOps 面試的心得與經驗，譬如說

1. 不要造假履歷，履歷上面寫的東西都要能夠精準回答到基本等級，不論是程式語言或是 docker/kubernetes，只要敢寫上去，就要有信心去回答這些問題。
2. 對於所面試職位所需要的技能要真的會，舉例來說面試一個要使用 PostgresQL 的職位，結果連該技術都沒有用過，這樣其實真的會浪費彼此時間
3. 誠實面對所有問題，不知道的問題就勇敢的說不知道，瞎扯淡什麼太多的其實面試官都知道。

原文中還有不少段落，這邊就不一一列出，但是我認為本文真的算滿忠肯的，畢竟現在 CNCF 生態系這麼龐大，很多時候沒有一個扎實的基本功是很難快速地去學習不同領域的技術並且將其整合再一起，更不用說當遇到問題時，該如何除錯了。

https://lukeshaughnessy.medium.com/im-a-devops-hiring-manager-here-s-how-to-crack-my-technical-interviews-part-1-b53885e08655

想要對 DevOps 的概念，以及別人成功的案例怎麼做，千萬不要錯過這堂課喔。
（它不是教工具的課喔）

https://www.facebook.com/106300404532875/posts/172614454568136/?d=n