瞎聊軟件設計

      也作了兩三年開發了，隨便聊聊本身的感想。

      首先，什麼是軟件？這個問題每一個人都有本身的理解。軟件也叫程序，程序是一個具體化的概念，而軟件是一個抽象的概念。程序最先被髮明出來，是用來破譯密碼的，只能作簡單而重複的計算。而今天的軟件就不只僅是用於作簡單重複的計算了，它被用來處理變幻無窮的業務。那麼只能作簡單重複運算的程序，要怎麼去處理突飛猛進的業務呢？有一個辦法就是對業務進行抽象。

      咱們的業務再怎麼變幻無窮，總有一些不變的規律。就比如咱們所處的世界，它應該是咱們所能接觸的最複雜的事物，可是咱們的祖先仍是總結出了其中不變的規律，叫作 道。一陰一陽之謂道。這個規律總結的好，由於它成功指引了咱們幾千年的醫學、哲學的發展，在能夠預見的將來還將繼續影響咱們的生活。因此說，咱們的業務再怎麼變化，其中總有些東西是不變的，若是咱們的軟件設計能很好地把握住這些不變的東西，那麼咱們的軟件就能夠應對任何的變化。固然這是最理想的狀況。

      要從一個複雜的業務邏輯中抽取出儘量不變的邏輯是很困難的，它每每須要經歷無數次的嘗試，就像道的總結，是由咱們無數的祖先經歷長時間的嘗試才提煉出來的，因此這一點毋庸置疑。可是要作到從變化的事物中提取出不變，或者變化儘量小的業務邏輯，則總仍是有一些規律可循的。其中一個很重要的原則即是高內聚，低耦合，不過我這裏並不打算探討這個問題，我只想聊一些更淺顯的內容。

      以開發常見的WEB應用爲例，一個有多個使用者參與，而且須要身份認證的系統，首先有兩個模塊是必定要有的，就是session管理和權限的管理。設計一個這樣的系統，這兩個模塊是首先應該被考慮的，即時項目初期沒有精力作，也應該預留接口，這即是業務變化當中不變的部分。

      應對變化的部分，咱們應該有一個原則，就是要把不規則的數據想辦法轉換爲規則的數據進行處理，那麼這裏就有兩個方向的思路應該探索：① 在實現用戶最終目標的前提下，咱們是否能夠經過讓用戶在使用思路上作一些細小的調整，來讓咱們的數據變得更規則；② 咱們是否能夠經過提取更好的業務模型，來使數據變得更規則。處理規則的數據有一個顯而易見的好處，業務邏輯簡單，明瞭，寫出的代碼不容易出現錯誤。

      我寫程序最討厭if語句，我一般會想各類方法來避免if的使用。由於使用if意味着你在處理特例，也就意味着你沒有抽取出適當的業務模型，也就意味着你的代碼還有優化的空間。

      那麼什麼樣的數據算是規則的數據呢？我想這個寫程序的人都有本身的理解，並且程序寫的好的人，對這個的理解也是大同小異。不過我仍是要說幾點通常規律（WEB項目數據都在數據庫，因此我以數據庫的數據爲例來講明）。

      （1）看數據的數目。一個事物在數據庫有且只有一條主數據。例如我提出一個申請，這個申請裏面可能同時申請了多個內容，那麼咱們就應該是首先有一個記錄申請信息的主表，這個表對應着一條申請記錄；而後有一個輔表，記錄我申請的多個內容的詳細信息。那種只用一張表把申請信息全存起來，而後經過去重的方式獲取申請列表，是很是糟糕的作法。

      （2）看數據關係。數據之間的關係要明確，一對一的關係儘可能在主表中放外鍵，一對多的關係則在輔表中放外鍵。數據儘量以樹狀組織。數據的組織遵照高內聚，低耦合原則。

      （3）數據表的設計要直截了當，直觀明瞭，須要什麼結構的數據就存儲什麼結構的數據。例如咱們經過一個流程產生了一個資產，那麼咱們就在數據庫設計一個資產表，存放一條資產數據，這樣在我須要查看資產信息的時候也就很方便了，不用說須要資產信息時還到流程裏面去找。

      以上是我在實際工做中遇到過的問題，而後對這些問題所做的思考。也許對多數人來講，這是理所固然的事情，但我確實遇到過好多莫名其妙的業務設計，最後都是本身挖坑本身填，這些不變的道理仍是不少人沒有認識到。