在編程中，為何說數據仍占主導地位？

作為一個曾經的程序猿后轉型為系統集成設計和售前崗位的人來說，對這個問題印象深刻。主要從兩個方面做一下非專業性的思路回答，可能更容易理解：

1.從傳統程序設計領域的軟件開發思路來說，在做一套系統的設計和開發時需要考慮什么問題呢？當然是需求和目標。好，那我們假設需要為某企業做一套的專屬OA系統，第一步需要對這個企業的具體需求做全面調研，我們要弄清楚為啥這個企業需要定制OA而非買成熟產品。首先搞清楚OA系統覆蓋企業哪些部門、哪些業務、有哪些關鍵問題。弄清業務對象、業務流和業務目標之后，我們在梳理設計功能之前一定會接觸數據流，例如財務部和庫房協同完成產品交易到賬后的發貨，其流程假設為財務部確認合同訂單（金額、數量、貨品型號等）—生成發貨單—庫房審核確定—安排裝箱發貨。這樣一個簡單的業務流中就包含了各類數據和表單，確認了數據內容和數據流，我們才能夠根據財務部和庫房的需要進行上傳合同、填報發貨單、提交發貨申請、審核等功能設計。因此在正常的設計流程來說，我們首先接觸到的一定是數據而非功能。

2.從程序設計的合理性、科學性和后續擴展需要來說，在一套系統的設計、開發、維護更新過程中，最為復雜的并不是頻繁修改的功能和業務流，而是數據之間的關系。設想程序在設計和開發前，我們對于數據的全面性和數據類型并沒有梳理明晰，隨著系統開發的深入，不需要用戶提出變更，只是簡單的重新反復確認數據字段和數據表結構關系就會造成大量的返工和代碼修改，更不要提后續的程序穩定問題。即便系統順利開發完成，那么在后續使用過程中一旦出現功能變更和業務流的簡單調整，對于不完善的數據庫調整可能導致某一業務流甚至整套系統的癱瘓。面向小型系統耗費人力和時間可能還可以解決，如果是大型系統（如銀行系統、ERP等），這樣可能使整個體系變得不可“觸碰”，最后變成災難性的問題，更不要提系統后期的擴展性和可維護性。

因此在編程中，按照科學合理的系統設計思路和開發邏輯，是一定要清晰的確定數據結構的。隨著目前互聯網和信息化行業發展，系統變得越來越復雜，即便是目前在大型項目中最為方便持續運維和適應性最強的數據中臺、微服務架構等技術中，將大型系統拆分為一個一個松耦合的小型業務體系，也需要對數據內容進行不斷驗證、明晰，確定各個業務流程上下文界限和數據內容，從而保證后續系統之間的銜接和穩定。所以在編程中不能說數據仍占主導地位，而是在后續很長一段時間內都會是主導地位。