提供具體的服務，有具體的業務是很容易的。基本上每個大眾用的軟件，都是 No code / Low code 就可以使用的。之所以這么多廠商提出自己要做 No code / Low code，都不是沖著解決一個特定領域的問題去的。比如說不用寫代碼也可以在網上賣東西。這個用淘寶就好了，不需要 No code / Low code。

為什么說遠比想象得要難。因為這里面其實蘊含了4層問題。我們由表及里來看。

第一層，是要解決普通人也能編程的問題，這一層需要用一些普通人熟悉的概念和表達方式來代替代碼。本質上是要解決一個教學的問題，利用熟悉的概念學習新的概念。讓編程的效率更高，和讓普通人也可以學會編程是兩個完全不同的問題。其實這個教學問題沒有多少捷徑。所以大部分 No code / Low code，實際上是把問題轉換為下一層的問題，就是讓你復用，就不用寫代碼了。

第二層，因為這種普通人也可以“編程”的方式效率其實是不高的，所以盡可能少的讓普通人來完成必要的工作。而是把工作前置到平臺方提前幫用戶做好。然后普通人只需要“復用”就好了。但是通用不限領域的軟件復用，這個自身就是一個非常難的問題。往往可復用的代碼都會更復雜，復用的同時還要好懂，易于維護就是更難的問題。軟件復用其實歷史悠久，然而進展非常緩慢。今天的代碼生成器和五十年前的代碼生成器，沒啥本質的提高。所以快速生成Java 的 CRUD 是不會有什么實質性提高的。如果這種做法有用的話，早就普及推廣了。還是要看有沒有比 Java 這樣主流的方式更好的寫法。所以就引出了下一層的問題。

第三層，要解決的問題是減少軟件開發與維護的總工作量。第二層是關于軟件代碼的 reuse。第三層就是假設不存在 reuse 的問題，就是實打實的解決一個明確而具體的問題，如何做得更少的問題。軟件開發和維護的工作量是一個總數，我們也不論這個總工作量怎么在平臺方和復用方分工的問題。這些活不論你干還是別人，總得有人干。一個總的方向就是降低編程這項活動的認知負擔，減少需求和源代碼之間的Gap。所謂 complexity 大家都認同，但是有幾個人可以具體 complex 在哪幾處說明白的。為什么這些事情會對我們的大腦來說是難呢。這個問題分解的過程才最為致命。

第四層，當我們寫的代碼越像需求，而實際的CPU執行方式是恒定不變的。那么代碼和實際的執行過程的Gap就會越來越大。目前的主流實踐是用 console.log 這種非常低帶寬的方式獲得反饋。如何提高開發者獲得反饋的帶寬以及頻率是很難的一個綜合性問題。

整體而言，一個根本性的困難是這些問題都不是可定量的科學。因為其作用的對象是人類自身。這些問題更多的是人文性和社會性的問題，而不是數學問題。同時強烈的主觀性，導致了進展非常難以評估。而且也會導致即便有進展，其實際的功效也非常難以定價，從而具有明確的商業價值。

從商業模式的角度來說，最有吸引力，最好講創業故事的領域是第一層的問題。最不性感，最難以銷售的是第四層的問題。然而最表面的問題，“普通人無法像自己就能寫信一樣，要求助寫信專家（開發者）代寫”不是在于普通人與寫信專家之間的差異。而是寫信這個事情，對于專家來說也是困難的。

這個行業最缺少的是對問題的深入分析，例如到處充斥著是 OOP 更好還是 FP 更好的無意義的爭論。在我看來 OOP 和 FP 都一些對不明問題的解決方案而已。單純討論解決方案是沒有意義的，關鍵是問題是什么。

所有 No code / Low code 從業者需要做的是把前面列舉的四層問題進一步展開，每一項都能分解出更具體的問題。當我們把問題都理清楚的那一天，對應的解決方案就會顯而易見。

文章來源于知乎創作者陶文

原文鏈接：https://zhuanlan.zhihu.com/p/82579865

若有侵權請告知，我們將及時刪除，本文僅供學習交流、我們注重分享，勿作商用，版權歸原作者。

繼續閱讀：

未經允許不得轉載：RPA中國 | RPA全球生態 | 數字化勞動力 | RPA新聞 | 推動中國RPA生態發展 | 流 > No code / Low code 看起來容易，其實遠比想象得更難