要 在大數據,雲計算,人工智慧盛行的環境下,程式員該何去何從?企業自有的研發團隊又該如何規劃?這兩個問題在五年前,我就認真的思考和深入的分析過。程式開發模式基本經歷了以下階段。 傳統的程式開發階段 在對需求進行調研和分析後,最終得到系統的設計架構和技術選型;接下來就是程式員從第一行代碼純手工的編寫, ...
要
在大數據,雲計算,人工智慧盛行的環境下,程式員該何去何從?企業自有的研發團隊又該如何規劃?這兩個問題在五年前,我就認真的思考和深入的分析過。程式開發模式基本經歷了以下階段。
傳統的程式開發階段
在對需求進行調研和分析後,最終得到系統的設計架構和技術選型;接下來就是程式員從第一行代碼純手工的編寫,這種模式下存在以下幾個問題:
1、 效率低,代碼編寫速度取決於程式員的熟練程度,
2、 質量低,因為是純手工編寫,出錯是不可避免的,大量的時間在debug,同時還會為系統運行埋下了隱患
3、 風格標準不一致,因為系統的複雜性,決定了不可能一個完成所有的代碼編寫,而每個人的習慣和能力不同,就會使得不同的人寫出來的代碼各有特色,
4、 系統迭代難度大,隨著系統的運行和實際業務的校驗,免不了對系統進行升級和功能的增加,這時可能會遇到升級的程式員根本不是最初的程式員,這就不得不先讀懂程式的本來開發思路,然後才能進行修改。
5、 系統整體掌控難度大,對於項目的管理人,要花費大量的時間對程式員的開發規範進行統一,不斷的開會才能讓不同角色的程式員最大程度的瞭解整個系統的運行。
6、 成本高,對於軟體系統的開發,最大的成本就人工和管理成本。傳統的開發模式下要確保開發進度,人員增加是重要的解決方式,畢竟完全用加班的方式是不能長久的。
細功能模塊和開源框架階段
正是傳統的開發模式和手段存在上面的問題和弊端,所以就有了後來出現的各種功能模塊及各種開源框架,這在一定程度上對傳統開發模式下的問題進行了改善,可以體現在效率,穩定性,成本等方面;但是由於功能模塊的細分程度越來越小,程式員對這些模塊的整合能力和駕馭能力顯得更加重要。
在這個技術爆炸的時代,IT技術更是日新月異,對於企業而言用最新的技術不是追求的目標,解決問題才是落腳點和出發點。
如何進行程式開發
程式員該如何編碼程式呢?我認為程式員要寫代碼,但是不是最終用戶操作的系統本身,而是系統或程式工廠的開發。就像我們能買到的很多商品,技術專家設計出生產線,商品只是生產線生產出來。同樣,程式開發是否也可以有這樣的生產線呢,如果有那就解決了太多的問題,比如成本問題,標準規範的問題,代碼質量的問題,人員問題等。
經過上面的分析,得到一個結論,那就是程式員要做聰明的程式員,要寫有能力的代碼;企業要建造自己的程式工廠,這才是聰明的開發模式。
IT技術企業要有程式開發工廠,這樣可以最大程式的壓縮系統開發成本,也就有了市場競爭力了。這種生產線有人稱為“低代碼平臺”,我認為完全可以做到無限接近無代碼開發。讓開發發變得簡單,再簡單。
附:
代碼構建平臺已經能夠具備了基本工廠能力:
前後端分離
數據合法性校驗(前臺數據合規性,後臺邏輯校驗)
關聯對象的引用
主子視圖展示
靈活的數據檢索
多前端同步生成(客戶端(Client),瀏覽器(Browser),移動端(H5)
二維碼掃描能力
單據互推能力
消息引擎(微信,釘釘,郵件等)
業務邏輯熱插拔
代碼標準化與業務個性化統一能力
工作流引擎
列印模板定義
個性報表輸出
代碼構建平臺入口
代碼構建平臺操作
不同單據類型構建
單據類型包括:
1、主子表(多子表) 具備單據互推能力(可配置),外部數據秒級導入,二維碼掃描快速建立,
2、單表(檔案)支持移動智設備平滑適配
3、對象引用(表頭)
4、對象引用(表體)
個性化前端代碼管理
前端js事件監聽可管理
後端邏輯適配
主子表桌面端編輯
有移動端適配UI
移動端對象引用
以上僅代表個人觀點,有任何疑問 歡迎留言