為什麼無程式碼畫畫圖就能快速開發的工具軟體註定要失敗 - 世界架構師

這是建立低程式碼平臺的承諾
這些軟體平臺大多數都是從一些簡單的基於流程圖的介面開始的，它允許您將資料流或使用者互動串聯在一起。表示資料來源的小塊可以放到畫布上並連線到軟體。然後，理論上，您只需按一個按鈕即可生成應用，報告或工具。看它就行了！

這讓客戶興奮不已，準備開始用業務分析師替換所有昂貴的軟體工程師，他們是業務流程圖專家。

然而，有兩個缺失的部分被方便地遺漏或忽略：第一個忽視了特別具體情況，您的低程式碼提供商要麼通知您他們的工具不是針對您的特定用例，要麼您被告知您必須使用他們非常友好的指令碼語言自己構建自定義功能；另一個缺失的事實是視覺圖是實際解決方案的粗略簡化，它忽略了可能出錯的事情或用簡單線條捕獲的所有細節。這些細節需要以準確和明確的方式清楚地表達出來。

突然之間，你發現自己正在尋找精通你所購買的特定低程式碼平臺的程式設計師，這是一項非常艱鉅的任務。

現實情況是，無論何時構建具有任何級別的自定義功能的軟體，您將需要能夠輕鬆編寫程式碼的人。這些人更容易在程式碼中編寫程式碼，而不是在編碼時將某些圖片混合程式碼中。這就是為什麼低程式碼必然會失敗的原因，當您需要在不適合現有工具的域中建立某些東西時，您已經進入了最終需要完成程式設計的域，並且在該域中，您需要一個程式語言，而不是繪圖工具。

有什麼選擇？
自計算機時代開始以來，我們看到了與計算機通訊方式的穩步發展，從印表機上編寫的二進位制程式到Python，Elixer和Rust等現代程式語言的爆炸式增長。正在發生的事情是語言本身變得越來越具有表現力和抽象性。這意味著一個想法和你需要編寫的程式碼之間的距離在縮小，你需要越來越少的程式碼來表達這些想法。

程式設計，編碼或軟體工程現在仍然是清晰，完整地表達複雜思想的藝術。首先，提出這些想法，其次，這個表達方式，使得軟體專案難以估計並且通常很難完成。