回覆列表
  • 41 # 善良的糧農

    如果低程式碼是趨勢,那麼機器支配人類就是必然,如果未來不是機器支配人類,那就得相信有神,相信有神就有相信有鬼。那麼如何燒香可以讓神知道,給我送一大筆錢呢

  • 42 # 愛T館

    低程式碼本來就不是新鮮的東西,十幾年前就有了,低程式碼本質是要解決一些有套路和定式的資訊系統需求,國內有人覺得低程式碼是未來,為什麼呢,因為只有中國才需要那麼大量的資訊系統,國外的資訊系統領域基本被巨頭形成標準和壟斷地位。國內標準還沒形成。但說到軟體開發的未來是低程式碼,這個是錯誤的認知,軟體開發的本質在於創造和透過資料預測未來走勢,很多領域並不是低程式碼可以做到的例如AI 股票預測,輔助製造,甚至是一些設計,辦公領域的軟體。只有那些可被結構化儲存而又不用複雜處理的資料(只做增刪查改)才能被低程式碼處理。

  • 43 # 極客雞kun

    因為大家都想用自己的邏輯適用在軟體上,而不去考慮自己的邏輯是不是普世的,自己的業務流程是不是冗餘複雜的。這種情況下很多低程式碼開發平臺就無法支援複雜的機能。

    一個公司的高層裡,越多的人理解itsm的定義。低程式碼開發能越容易在公司內展開。

  • 44 # DL潮鞋

    但是,低程式碼開發並不是傳統軟體開發的替代品,並不適用於所有情況。它可以用於快速原型設計和構建簡單應用程式,但對於需要高度定製或效能的複雜或關鍵系統可能不太合適。

    此外,一些人可能對低程式碼開發持懷疑態度,因為他們擔心所得到的程式碼質量和可維護性以及依賴特定供應商的低程式碼平臺的長期可行性。

    總的來說,在決定低程式碼開發是否是合適的方法之前,應該考慮專案的具體需求和目標。雖然它可能不適用於每一種情況,但低程式碼開發對於某些型別的專案可以是一個有價值的工具,可以幫助組織提高開發速度和效率。

  • 45 # SoeWiPaPa

    因為邏輯需要自洽,如果自洽了,那就不是低程式碼了,而只是一次extends。

  • 46 # 我站在未來等你。

    程式設計師之所以高工資,不是因為程式設計難學,程式設計就那幾個語法。難的是功能實現方法,還要排除各種可能的bug,也就簡單的功能可以用低程式碼,但凡後期要最佳化還得用程式碼重寫

  • 47 # 鳳兮空靈

    昨天有朋友打電話問我有時間沒有,原來是他不知道有個軟體怎麼用,我說我沒時間,此外,我也沒用過那個軟體。說話間,我隨口推薦了一位專業人員,說請那人應該能解決。可朋友告訴我,那人雖然是it專業人員,但是那位專業人員卻無法理解和體會他的一些想法,所以,不願意請那位專業人員,只願意找我這種雖然不是it專業的,但卻是更能明白和理解朋友想法的來解決問題。

    我在與it人員接觸與交流中,也感受到這方面問題,他們在應用方面存在的主要問題是:不是做不到,而是想不到。有時,費了許多功夫,也無法讓it人員明白自己的想法,還不如自己直接動手來解決。

    這就是當今出現低程式碼這種東西的本質原因。

  • 48 # Jh8848

    其一,有一部分廠家在拿低程式碼當噱頭,把低程式碼的名聲給搞差了。廣義上來講,低程式碼早就有了。EXCEL算不算入門級的低程式碼平臺?VB、DELPHI之流算不算低程式碼平臺?成熟的IT公司自己用的快速開發平臺/框架算不算低程式碼?低程式碼平臺本身就是一個開發工具,它的作用更多的是降低開發人員的工作量,提升開發效率(不是執行效率),讓專案團隊可以把更多的時間聚集到業務本身上去。但是業務功能還是要依靠專案團隊自身去理解和實現。就好比同樣是寫文章,莫言用的是紙筆,我們用電腦,效率是快了,但是我們能拿到諾貝爾獎嗎?

    其二,業務的廣度和深度的平衡問題。很多IT企業都應當有過類似的感受,同一個產品,同一個團隊,在不同的行業實施的效果會有天壤之別。這不是產品本身的問題,所以很多大的IT企業的同一產品,針對不同的行業都會出來專門的行業版本。很難做到面面俱到。但是對於低程式碼平臺來說,就會面臨著抉擇——如果與某一垂直行業繫結太多,廣度不夠(其實很多IT企業自用的快速開發平臺都是這種情況);如果想囊括主流行業,深度不夠。到底把輪子造成什麼樣?到底需要造多少個輪子?現在已經完成的或是已經規劃的輪子就夠用了嗎?這是大多數人的擔憂,也是現在的程式碼平臺的隱患。當然,也有一些廠家希望自己作成標準,讓使用者適應自己的輪子,只能說理想很豐滿。

    其三,目前市面上的很多低程式碼平臺,功能非常的全,各種場景的功能元件+視覺化開發工具+工作流+BI.....應有盡有,但是這些琳琅滿目的功能對於使用者來說,都是必須的嗎?使用者只是想喝牛奶,不是要建一個奶牛場。更何況,低程式碼平臺的二次編譯/二次開發,從執行效率上來說,真的好嗎?

    其四,低程式碼平臺最大的問題,在於低程式碼平臺也是需要有人去開發的。而程式碼平臺省去的往往只是最基礎的程式碼,複雜的業務邏輯還是需要有經驗的人去做的,而這樣一來的開發難度並不亞於傳統的開發模式。同時,低程式碼平臺的開發主體是誰?是使用者自己,還是IT公司?如果是使用者自己,如果只是滿足一些碎片化的需求,可能他們會考慮,如果做大型系統,他們錢都花了,為什麼不買現成的成熟產品,自己反而要去買個半成品,承擔失敗的風險?如果是IT公司,那和外包外購有什麼區別?

    低程式碼平臺,只能說看起來很美。

  • 49 # 54smdd666

    補充:前幾天試用了chatGPT,被AI的智慧程度給震驚到了,以後可能只需要演算法/架構師這樣的角色了,一般的碼農會被AI給替代了!

    輕流、appsmith、budibase、retool 都用過,就是公司內部做資訊管理,折騰1年多,現在除了Budibase還在用,其它都完全放棄了。

    0程式碼平臺功能太受限制,如果你只是打算用來代替excel做資訊管理、錄入和簡單工作流什麼的那是足夠用的,但是你很快會發現還有很多需求它實現不了的…

    低程式碼平臺功能比較強大,大部分支援JS可以做比較多的功能,但是,各個平臺都有各自的功能缺陷,有些還有效能問題很慢,但是讓我們放棄的主要原因還是程式碼(雖然程式碼不多)不好管理、無法重用,而且學習成本其實並不比nodejs + vue什麼的低多少。

    所以,對於懂程式碼的人來說還不如用類似nodejs+vue之類的進行開發,對於不懂程式碼的就用輕流之類的當excel表什麼的來用就好了。

  • 50 # shxiaosan

    我的erp裡兩個億的訂單,你低程式碼下試試?

  • 中秋節和大豐收的關聯?
  • 照理說下午應該是一天氧氣最充足的時候,慢跑可以攝入更多氧氣,但為什麼醫生建議早上跑步比較好?