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

[[277738]]

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

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

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

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

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

原因一：維護(hù)可能很困難

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

原因二：千篇一律

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

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

原因三:一刀切

產(chǎn)品制造商喜歡“一刀切”的產(chǎn)品，因?yàn)榱魉€要簡單得多?？蛻魟t更需要定制化，而且他們特別討厭流水線產(chǎn)品。

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

原因四：:有時(shí)編碼比配置更容易

開發(fā)人員一直在犯一個(gè)戰(zhàn)略性錯(cuò)誤，將配置軟件的工作量最小化。也許是因?yàn)閎ean計(jì)數(shù)器計(jì)算每行代碼成本的指標(biāo)，也許是因?yàn)榭偸窃诒容^創(chuàng)建新代碼的成本和購買現(xiàn)成產(chǎn)品的價(jià)格。在任何情況下，編碼人員都喜歡假裝更改平臺(tái)或工具的配置文件中的參數(shù)并不是什么大問題。

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

原因五:低代碼意味著盲目運(yùn)行

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

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

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

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

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

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

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

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

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

原因八：:需要經(jīng)驗(yàn)

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

低代碼通常不被教授，因?yàn)槟悴恍枰魏沃噶?。這些工具通常是用通用語言編寫的，但這對開發(fā)人員來說并不是真正的挑戰(zhàn)，挑戰(zhàn)在于捆綁到低代碼框架中的額外結(jié)構(gòu)。如果他們要修改或擴(kuò)展平臺(tái)，這些就是你的團(tuán)隊(duì)需要花時(shí)間學(xué)習(xí)的。

原因九：容易被困住

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