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

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

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

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

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

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

原因一：維護可能很困難

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

原因二：千篇一律

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

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

原因三:一刀切

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

原因八：:需要經驗

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

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

原因九：容易被困住

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

作者：Peter Wayner