要

在大資料，云計算，人工智能盛行的環境下，程式員該何去何從？企業自有的研發團隊又該如何規劃？這兩個問題在五年前，我就認真的思考和深入的分析過，程式開發模式基本經歷了以下階段，

傳統的程式開發階段

在對需求進行調研和分析后，最終得到系統的設計架構和技術選型；接下來就是程式員從第一行代碼純手工的撰寫，這種模式下存在以下幾個問題：

1、效率低，代碼撰寫速度取決于程式員的熟練程度，

2、質量低，因為是純手工撰寫，出錯是不可避免的，大量的時間在debug,同時還會為系統運行埋下了隱患

3、風格標準不一致，因為系統的復雜性，決定了不可能一個完成所有的代碼撰寫，而每個人的習慣和能力不同，就會使得不同的人寫出來的代碼各有特色，

4、系統迭代難度大，隨著系統的運行和實際業務的校驗，免不了對系統進行升級和功能的增加，這時可能會遇到升級的程式員根本不是最初的程式員，這就不得不先讀懂程式的本來開發思路，然后才能進行修改，

5、系統整體掌控難度大，對于專案的管理人，要花費大量的時間對程式員的開發規范進行統一，不斷的開會才能讓不同角色的程式員最大程度的了解整個系統的運行，

6、成本高，對于軟體系統的開發，最大的成本就人工和管理成本，傳統的開發模式下要確保開發進度，人員增加是重要的解決方式，畢竟完全用加班的方式是不能長久的，

細功能模塊和開源框架階段

正是傳統的開發模式和手段存在上面的問題和弊端，所以就有了后來出現的各種功能模塊及各種開源框架，這在一定程度上對傳統開發模式下的問題進行了改善，可以體現在效率，穩定性，成本等方面；但是由于功能模塊的細分程度越來越小，程式員對這些模塊的整合能力和駕馭能力顯得更加重要，

在這個技術爆炸的時代，IT技術更是日新月異，對于企業而言用最新的技術不是追求的目標，解決問題才是落腳點和出發點，

如何進行程式開發

程式員該如何編碼程式呢？我認為程式員要寫代碼，但是不是最終用戶操作的系統本身，而是系統或程式工廠的開發，就像我們能買到的很多商品，技術專家設計出生產線，商品只是生產線生產出來，同樣，程式開發是否也可以有這樣的生產線呢，如果有那就解決了太多的問題，比如成本問題，標準規范的問題，代碼質量的問題，人員問題等，

經過上面的分析，得到一個結論，那就是程式員要做聰明的程式員，要寫有能力的代碼；企業要建造自己的程式工廠，這才是聰明的開發模式，

IT技術企業要有程式開發工廠，這樣可以最大程式的壓縮系統開發成本，也就有了市場競爭力了，這種生產線有人稱為“低代碼平臺”，我認為完全可以做到無限接近無代碼開發，讓開發發變得簡單，再簡單，