關於低程式碼平臺，之前我也推送過兩篇相關的文章，我的觀點很簡單：東西是好的，有它所擅長和適用的領域，但軟體產品不存在銀彈，低程式碼平臺一樣如此！
現在在搜尋引擎上搜“低程式碼”這樣的關鍵詞，你會看到很多誇張的標題，比如：
- “人人都是產品經理”之後，“人人都是程式設計師”的時代要來了？
- 阿里、騰訊都在押注的新賽道，能讓程式設計師告別脫髮和996嗎？
- 還有諸多低程式碼平臺的公司拿到各種融資或地區性政府補貼的新聞
甚至我還在福報長的抖音賬號中，看到了程式設計師下午坐在外面喝咖啡，說有了低程式碼，現在大把時間休息的短視訊。。。
低程式碼平臺真的這麼神奇？我們在企業數字化轉型過程中的開發任務都可以用低程式碼平臺來解決嗎？我們開發者996的宿命就這樣被搞定了？
如果你正對低程式碼平臺抱有上面幻想的話，一定要好好看看下面的內容！
先表明觀點：如果你試圖使用低程式碼平臺去解決所有開發問題的時候，很有可能這樣的決定將在2-3年之後帶來巨大的災難！
為什麼這樣說呢？下面結合我們10年前的實踐，給大家說道說道！
偽新技術
你沒看錯，是結合10年前的實踐！所以，低程式碼平臺並不是什麼新概念，我們10年前就玩過了！
記得以前在宇宙行的時候，就有一陣推行過一套開發平臺，裡面也是提倡大家用拖拽的方式去實現各項業務功能。
領導們也都非常推崇，希望通過這套平臺的使用，對開發效率帶來革命性的變化。
當然當時的平臺，與如今的低程式碼平臺還是有一些差距，目前所見的平臺會更加完善（介面好看了，控制元件也多了），但從一名從業十多年的開發人員角度去看，並沒有質的進步，這樣的程度距離淘汰開發者還有很長的路要走。
效率毒藥
低程式碼平臺是效率毒藥！
按照各種產品的宣傳來看，低程式碼平臺的目標是要解放我們，讓我們更快的開發產品，那為什麼說低程式碼平臺是效率毒藥呢？宣傳是騙人的嗎？
宣傳並沒有騙人，當我們實際去使用的時候，你會發現，開發一些簡單應用的時候，確實會快很多！
同時，在我們過去的實踐過程中，開始時候的效率是可以的！這取決於兩方面的功勞：
- 小範圍的試錯
- 簡單應用的先行
但隨著推廣的鋪開，也逐步的會面臨這幾個問題：
- 平臺支援成了瓶頸：大量使用問題、各種平臺報錯都堆積到低程式碼平臺的負責團隊。對於平臺的人員支援，不可能給每個業務系統都配置一個支援人員吧？所以當應用面一旦擴撒，平臺支援團隊很快會成為整個系統內的效率瓶頸。
- 扯皮問題開始增多：當出了線上事故開始定則的時候，原本系統之間可能會存在扯皮，但有了低程式碼平臺之後，系統內的實現也多了一個扯皮方向。到底是元件Bug還是使用問題？使用問題的話，文件寫清楚這種特殊情況不行了嗎？這種新扯皮姿勢的出現，阻礙瞭解決問題的效率。
之所以說低程式碼平臺是效率毒藥，因為在一開始的時候，你是感覺不到的，只有在逐步深化應用，全面推行的時候，它的毒性就開始發作了！
創新毒藥
低程式碼平臺是創新毒藥！
關於創新，第一點弊端，你一定會想到，就是固化元件的問題，讓所有的實現都千篇一律。
但這個在如今的低程式碼平臺上，其實有好的解決方案，那就是各種自定義實現。
既然用平臺是為了讓業務開發更專注業務，同時在使用低程式碼平臺之後，這樣的元件創新任務，往往又都回到了平臺側的支援上。
於是，最經典的一幕就出現了：
產品經理：這個功能，我們想這樣...這樣...再這樣...可以不？
開發人員：平臺沒這個模組，實現不了
...
產品經理：平臺能做個模組支援下嗎？
低程式碼平臺：這個需求，我們下個版本可以考慮下
產品經理：下個版本什麼時候？
低程式碼平臺：半年後...要麼你先用xxx元件 + yyy元件這樣...那樣...最後...先湊合一下？
產品經理：...
這是當時很真實且頻繁出現的場景！業務總是千變萬化的，然而平臺的新功能總是滯後的，作為業務開發，必須通過平臺實現，很多時候因為缺乏靈活性，讓開發失去了原有的創新能力。同時，也成了開發人員拒絕業務需求的神兵利器。
記得在那個時期，基本上所有的專案都是差不多的樣子...毫無新意可言，這怎麼會促進業務創新呢？這樣的平臺幾乎成為了創新的毒藥！
擺正姿態
為什麼效率、創新這些低程式碼平臺原本所要追求的願景最終會成為毒藥，給團隊帶來負面影響呢？
這裡固然有銷售方的過渡吹噓，就如前幾年阿里中臺的亂吹亂用，讓不少買單企業罵娘！但作為引入這類平臺的管理者來說，也有不可推卸的責任。
根據過去的負面經歷，不妨思考一下：為什麼推薦給開發人員會出現那麼多反面的效果？
我認為造成這個核心問題還是由於平臺提供能力與使用人員能力的不匹配所造成的。
回想一下低程式碼平臺的目標是什麼？
- 上手速度快
- 開發效率高
- 研發成本低
- 部署時間短
- 維護成本低
綜合起來就是：有效提高團隊效率。但到底是提高什麼團隊的效率呢？既然推向開發團隊，受到如此多的白眼，那麼推向產品側？運營側？是否可行呢？
試想一下，低程式碼平臺的目標是要降低了上手門檻，那麼對於開發人員而言，他好不容易具備了門檻知識，突然又用低程式碼平臺來給他用，然後告訴他，你之前的開發方式不用了，可以花更多精力專注於業務的思考了。是不是這樣的目標就很奇特呢？從原本更靈活的開發手段，到使用低程式碼平臺的限制方式，不是浪費了原有開發人員所具備的更靈活的開發能力？然後還要開發人員專注去學習業務？那麼學習業務的效率和準確度能有保證嗎？是不是有種好不容易招了批練武奇才，學會了九陰白骨爪，然後給發了副手套，去撓癢癢麼？這是不是一種人才的降級使用呢？
再換個角度想想，如果低程式碼平臺推向產品側呢？本身他們有更專業的業務背景，然後依靠低程式碼平臺，拖拖拽拽就能完成一套業務系統的開發，這樣的使用方式，似乎更配得上低程式碼平臺降低上手門檻的目標？因為沒有佔用開發人員的資源，因此也為公司極大的降低了研發成本？大大提高了業務系統的開發效率？而開發團隊更應該去做的是低程式碼平臺無法做到的那些更具有創新意義，或更具備挑戰的開發任務，不是嗎？
似乎把低程式碼平臺推向產品側會得到很好的效果？願景很美好，但現實也是很骨感的！最近，我就嘗試著給幾位產品經理朋友，搞了一些小合作，因為正好公司運作也需要一些工具，然後推薦了幾個低程式碼平臺讓他們去嘗試，但結果並不完全令人滿意，不過似乎我也從中得到了一些新的啟示！
我發現，如果產品經理擁有一些開發背景、學過程式設計、或是軟體專業畢業的話，在使用低程式碼平臺的時候，效果就尤為突出。也許是因為他們的知識背景具備一定軟體開發的思維模式，結合對業務的理解，所以對於低程式碼平臺的應用就更為友好！
所以，對於低程式碼平臺，好東西是無可厚非的，但使用姿勢一定要正確！任何東西只有用對了地方，才能成為神器！放錯位置的神器，有時候連垃圾都不如。
那麼你覺得低程式碼平臺如何呢？你們的使用姿勢是怎麼樣的？有沒有不舒服的地方呢？留言說說你的想法吧！如果你想與更多有趣的靈魂碰撞，也可以加入我們的技術交流群一起探討我們的技術人生！
歡迎關注我的公眾號：程式猿DD，分享外面看不到的乾貨與思考！