程序員們喜歡“低代碼”工具的理念。 對他們來說，更少的代碼意味著更少的工作和更快的項目、更高的滿意度、更精簡的預算甚至是更豐厚的獎金，試問誰不喜歡這些呢?

[[277738]]

但是他們也都知道，在最后期限接近或者工具不合適時，理想和現實之間往往存在很大的反差。

程序員欣賞低代碼以更少的時間和精力交付工作的能力。低代碼工具理論上可以產生一種良性機制，可以搜索、排序和處理表格數據。當時機成熟的時候，他們也很樂意使用它們。

但是開發人員也擔心低代碼出現問題，在低代碼出現問題時，他們就需要處理這些故障，并找出解決辦法。

開發人在使用低代碼工具比編寫自己的堆棧(換句話說，使用高代碼方法)更慢、更麻煩的現實之間兩難。

下面是程序員對低代碼工具好感度不高的9個原因。

原因一：維護可能很困難

處理低代碼解決方案最棘手的部分通常是在運行幾年之后才會出現。舊系統已經部署好并運行得很順利，但是每個人都需要修復和改進。很多時候，這些額外的特性位于舊的、低代碼解決方案的體系結構結構之外，并且沒有合適的方法來添加它們。如果我們有源代碼，我們也許能夠深入研究并重建一些核心內容，但遺憾的是我們沒有。如果最初的設計者知道需要這個特性，他們就會做出不一樣的決定。但現實是我們依然被維護困難困住了。

原因二：千篇一律

就像去連鎖餐廳吃飯一樣，我們能輕易地知道菜單，也得不到什么驚喜。商業模式依賴于標準菜單和標準設計，從而節省成本，同時還提供完全一致的使用體驗，這并不是一個好現象。

低代碼工具就提供了千篇一律的感覺。一個稍有經驗的優秀開發人員通常只需點擊幾下鼠標就可以識別底層工具。無論有多少配置選項、閃屏或定制的CSS皮膚，底層機制都會顯示出來。對于一些想要一致性的用戶來說，這可能是一種安慰，但它也屏蔽了許多驚喜和新奇感。

原因三:一刀切

產品制造商喜歡“一刀切”的產品，因為流水線要簡單得多。客戶則更需要定制化，而且他們特別討厭流水線產品。

同樣，低代碼產品也很容易使用。只是沒有那么多東西可可供更改、自定義或編寫代碼，所以您只能使用它們，這可能不符合一部分開發人員的心理。

原因四：:有時編碼比配置更容易

開發人員一直在犯一個戰略性錯誤，將配置軟件的工作量最小化。也許是因為bean計數器計算每行代碼成本的指標，也許是因為總是在比較創建新代碼的成本和購買現成產品的價格。在任何情況下，編碼人員都喜歡假裝更改平臺或工具的配置文件中的參數并不是什么大問題。

低代碼選項往往會帶來相同的結果:在指定算法、連接數據庫和填充參數時，您并沒有編碼。每個人都知道這只是配置問題，但實際情況是，這些工作可能需要數天或數周才能完成，直到他們真正按照您的想法運行，但它需要比實際編寫代碼的“工作”更長的時間。

原因五:低代碼意味著盲目運行

多年來，開發人員創建了精心設計的調試工具，可以很容易地在任意位置停止軟件，并深入查看所有數據結構和算法狀態，以了解到底發生了什么。低代碼工具則會故意對我們隱藏所有這些，并且系統自動認為它們在正確運行。

如果低代碼部分像我們預期的那樣工作，那么一切都是順利的。但通常情況下，有些事情會出錯，我們則會陷入困境，無法弄清黑匣子里到底發生了什么。系統在沒有監測儀器的情況下盲目運行，找不到任何方法來了解發生的事情。

原因六:有時您需要插入函數來清理數據

編寫過軟件的人都知道，一半的工作是編寫額外的少量粘合代碼，以便在過濾問題的同時保持數據的流動。有時日期是ISO 8601格式，有時它們是本地首選。有時數字是整數，當它們應該是字符串時，反之亦然。

低代碼產品試圖通過提供過濾器或開關來承擔部分工作，這些通常就足夠了。但如果不是這樣，低代碼產品就會陷入困境。有些人嘗試過在某些地方插入任意代碼塊，但是這是一種誤用代碼的方法，還會產生巨大的安全漏洞。例如，Drupal刪除了在某些地方包含PHP代碼的選項，以關閉潛在的安全漏洞，并提高緩存性能。

原因七:低代碼通常效率低下

低代碼工具的承諾是，它們知道您需要什么，然后自動交付它。不過代價是一堆厚厚的代碼，它處理所有可能出現問題的奇怪配置。

如果您編寫了代碼，您可能知道您的公司只將數據存儲在CSV文件中。但是，回到低代碼總部的團隊需要為所有突發事件做好計劃，這意味著要使用JSON、YAML和XML，這兩個版本都是1.0和1.1。市面上有幾十種格式，低代碼銷售團隊希望確保他們的工具能夠處理所有這些格式。

這項工作異常復雜而浩大。最終的結果就是一切都變慢了，效率也降低了。如果你的截止日期不是太緊，你的數據集也不是太大，那你可以通過增加堆棧的計算能力來隱藏這一點，但最終結果可能不會太好。

原因八：:需要經驗

許多頂級的開源平臺都是用學校教授的流行語言構建的，有一個龐大的人才系統，可以分解和重建用Java、JavaScript、Python或PHP等主要語言構建的堆棧。

低代碼通常不被教授，因為你不需要任何指令。這些工具通常是用通用語言編寫的，但這對開發人員來說并不是真正的挑戰，挑戰在于捆綁到低代碼框架中的額外結構。如果他們要修改或擴展平臺，這些就是你的團隊需要花時間學習的。

原因九：容易被困住

有時啟動一個低代碼平臺， 加入很容易，但是很難離開。 站在巨人的肩膀上，你會盡可能地減少自己的工作量，但是這個巨人的變化會牽動的你的變化，如果它停止運行或者崩潰了，你也會陷入困境。也就是說，低代碼業務流程只能隨著組件改變，組件的功能和種類限制了開發。