摘要：本期直播主題是《揭秘華為云低代碼技術微認證》，向開發者們講述低代碼的發展歷程，介紹華為低代碼平臺應用魔方AppCube的開發能力，解讀華為低代碼的認證和學習體系
本期直播詳解
本期直播主題是《揭秘華為云低代碼技術微認證》，華為云PaaS服務產品部資深專家董鑫武向開發者們講述低代碼的發展歷程，介紹華為低代碼平臺應用魔方AppCube的開發能力，解讀華為低代碼的認證和學習體系，并與華為云PaaS服務產品部DTSE工程師李強強一起，拆解和演示了使用AppCube開發一款低代碼應用的全部程序，
低代碼的前世今生
軟體開發從機器語言時代開始，歷經以匯編語言為代表的低級語言時代、以Java等面向物件的語言為代表的高級語言時代、以Oracle等為代表的第四代語言，逐漸發展到現在的低代碼/零代碼時代，
低代碼編程技術的出現，將軟體開發的復雜性留給了開發平臺的研發，致力于減少影響軟體開發效率的不確定性因子，如人員來回溝通、業務與技術的Gap、人員技能差異、新技術復雜集成等，以期達到提升開發效率的目的，
相對傳統開發方式而言，低代碼在軟體開發全流程中的差異點大致如下：
AppCube低代碼：元資料驅動，前后端解耦
AppCube 是元資料驅動的全云化一站式程式低代碼開發和運行平臺，支持應用構建、代碼撰寫、編譯、測驗、發布、上線，平臺提供自定義創建或擴展資料模型的能力，提供拖拽式、圖元化編排業務邏輯介面的能力，提供基于H5開發前端頁面的能力，不提供開發手機原生app的能力，專業的開發者可以使用TypeScript語言輔助開發，
使用AppCube進行應用構建的步驟，大致分為創建應用專案、設計界面、系結資料模型、編排業務邏輯和測驗發布，
直播中詳細講解了每一階段對應的AppCube功能模塊及相關的使用步驟，服務編排舉例如下，歡迎查看回放觀看全部內容，
完成了應用開發之后，通常需要安排測驗和商用運行部署，為保證資料安全，不中斷在網現行業務，AppCube為開發者提供開發、沙箱、商用三套環境，
百聞不如一見：應用開發實操演示
結束理論介紹后，兩位老師以園區訪客出入審批應用場景為主線，為開發者講解此應用系統是如何逐步開發出來的，在正式開始動手進行應用構建前，董鑫武老師先分析了該應用涉及到的用戶角色、相關業務互動流程和關鍵的互動頁面，并交待了使用AppCube進行該應用開發的作業順序，
預知詳情，歡迎觀看實操回放，
百見不如一干：試試通過華為云低代碼微認證吧
董鑫武和李強強老師本次講解的實戰內容，其實也是華為云低代碼技術微認證的一部分，微認證適合所有對低代碼開發感興趣的社會人員和高校師生，通過微認證后，開發者能夠了解低代碼技術，并通過實戰提升自身的低代碼開發能力，目前，部分企業已經將通過該微認證作為員工上崗條件之一，感興趣的開發者可以搜索“使用AppCube低代碼平臺開發園區訪客應用”，訪問華為云學院網站報名學習認證，
價值問題摘錄
本期直播程序中問答區非常活躍，受直播時間限制，專家老師挑選了部分問題進行回答，受篇幅限制，本文摘錄其中三個價值問題，
Q：我身邊有很多專業人員說低代碼開發都是給不懂技術的業務人員用的，根本做不了需要運用大量函式和演算法的核心開發，但是根據 Gartner 的官方預測：“到 2025 年，70% 的新應用將由低代碼或無代碼技術完成開發”，關于未來低代碼運用的廣泛程度，您是怎么看的呢？
A：上一期也有類似問題，當前低代碼其實是面向專業軟體開發工程師的，不是面向專業人員的，因為使用低代碼平臺還是需要用到比較專業的開發邏輯、開發思想，普通的業務人員還不掌握這些知識，并不能開發出真正的具備復雜性的應用，
Gartner認為零代碼是低代碼的一部分，部分業務人員也可以用低代碼平臺構建出相關的應用，但這部分業務人員通常也受過軟體開發相關的教育和訓練，國內現在零代碼比較多，大家傾向認為業務人員可以使用零代碼去開發，這個現象也確實存在，但就像我上期說的，我們看待低代碼要回歸理性，應用中要用到的函式、演算法，尤其是比較核心的演算法，不適合使用低代碼開發，低代碼更適合以微服務的方式去“呼叫”這些能力，而不是去“開發”這些能力，否則效率會比較低下，不建議，
關于70%這個數字，個人是這么看的，這里面說的低代碼是一個理念，并不是只有低代碼平臺開發出來的應用才叫低代碼，在應用開發程序中，符合低代碼這一理念的，也可以稱作低代碼應用，比如在開發時使用了封裝好的東西，做了配置式的開發，或者用了已經抽象好了的底層的業務邏輯，我認為都屬于低代碼的范疇，基于這樣的理解，我認為“到 2025 年，70% 的新應用將由低代碼或無代碼技術完成開發”這樣的預測是合理的，
未來低代碼重點還是應該聚焦軟體開發工程師，零代碼在業務人員當中使用，國內零代碼的發展情況比國外稍微好一些，它釋放了軟體生產力，未來的前景是好的，不過離真正普及還需要一定的時間：剛開始需要低代碼去開發可復用的組件、邏輯，當這些可復用的單元越來越成熟，再由業務人員去進行拖拽式開發，這樣才會有一定發展，先低代碼打好可視化的基礎，然后零代碼，應該是這樣的程序，
Q：使用低代碼開發出的系統，性能會不會很差？低代碼開發出的系統，耦合性是否過強，導致后續維護困難？還有就是作為開發者關心的測驗問題？（01:07:55）
A：AppCube平臺部署是具備彈性伸縮能力的，平臺也會提供測驗機制去保障相關的性能，華為云在這方面是比較成熟的，AppCube最開始為電信運營商的計費、CRM等系統定制提供服務，那些系統對性能的要求也都比較高，
一般來說，選擇了低代碼平臺之后，開發出來的應用確實會對低代碼平臺有一定的依賴，但就應用本身來說，用AppCube低代碼開發出來的應用前后端是解耦的，這方面不會有問題，
至于測驗，AppCube有提供沙箱環境，這樣應用在正式上線之前可以進行充分測驗，提前暴露可能存在的功能問題，
Q：如果用AppCube開發一套系統，例如停車場收費系統，大約需要多少費用，和市場上已有的系統相比有什么優勢嗎？（01:35:04）
A：停車場收費系統主要是計費的業務，這類業務系統需要大量的資料處理，在性能方面也對后端的要求是非常高的，市場上現有的系統大多是傳統全代碼方式開發的，使用低代碼，可能是對老舊系統做改造，或者是全新開發，
如果是全新開發，那關于計費的核心演算法的部分，最好是把演算法用傳統方式開發好，然后以微服務的方式接入到低代碼當中，如果用戶是第一次使用低代碼平臺，可能會感覺跟全代碼的方式很不一樣，甚至還要花很多時間去學習和熟悉低代碼平臺的使用，并不一定能感覺到低代碼到底給他帶來多大優勢，但隨著對平臺的熟悉、隨著系統計費規則、邏輯不斷擴充，低代碼的優勢會越來越顯現出來，隨著應用資產沉淀越來越多，低代碼帶來的效率提升效果越明顯，
如果是在傳統系統做改造，情況類似，
我們不要認為引入低代碼可以解決一切問題，計費系統比較復雜，里面的演算法開發目前還是適合全代碼方式，業務邏輯之類的可以使用低代碼去編排復用，PC端、手機端等不同終端的頁面也可以用低代碼去開發，這樣是可以提升開發效率的，綜合來說，開發一套計費系統，要根據全代碼和低代碼的特點去將兩者結合使用，
下期直播預告
下節課，我們為開發者帶來DTSE Tech Talk No.8《零代碼玩轉汽車營銷》主題直播，介紹如何使用AppCube零代碼和業務大屏的可視化模板和組件，多角度展示汽車車輛資訊，包括外觀、引數配置等，針對車展等場景，新增配置預約試駕/登記試駕功能，實時展示最新登記成功資訊，
10月20日，我們不見不散，
點擊關注，第一時間了解華為云新鮮技術~
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/517590.html
標籤：其他
下一篇：探索智能化測驗技術