回覆列表
  • 1 # 曉逆

    在程式設計中,為何說資料仍占主導地位?

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

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

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

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

  • 中秋節和大豐收的關聯?
  • 自閉症兒童有沒有時間意識?