程式=資料結構+演算法
這句話如何理解？一個專案可以理解為一個程式，那麼資料分為兩種資料：專案本身要獲取的資料、為了實現專案而做的中間資料。演算法呢？聽起來很厲害的樣子？實際做專案時候很少接觸到所謂的演算法，所以大家理解它為行為就好了。所以，個人認為對大多數做業務的同學來說：程式=資料+行為。多思考一下我上面說的，看看能否頓悟。
個人獨立負責過多箇中小型網際網路專案，接下來就分享一下個人在做專案的時候如何進行系統設計。
如果是負責整個專案的需求分析、系統設計工作，那麼第一要務是把需求文件看透，分析出這個專案的主業務流程，覺得自己可以掌握個七七八八的時候，把這個專案的業務流程圖畫出來，在畫圖的過程中，我相信你一定會對需求的細節有更深一層的理解和掌握，這樣也方便你後續的系統設計工作，所以先把業務主線抓住！剩下的細節再慢慢考慮。
如果是負責專案中的某一個功能點，那麼也得對這個功能的相關功能有一個大概的瞭解，同時在詳細閱讀需求文件的過程中，如果你有疑問，也不要自己憋著，有問題就問，包括合理的或者不合理的。參考敏捷開發中一個故事的描述：誰想要什麼功能以便能夠做什麼？例如：作為一個產品經理，我想要一個使用者打標籤的功能以便我可以根據不同的使用者分類推薦不同的內容，做更進一步的精細化運營。那麼在分析這個功能的同時，資料即使用者的標籤，行為呢？給使用者打標籤！那麼設計一張使用者標籤表，一個使用者可以打多個標籤，使用者已經有這個標籤就不再重複標記了。相信說到這裡大家已經知道這個表怎麼設計了，這個功能就是這麼簡單。
一個完整的專案由多個獨立的功能模組組成的，這些獨立的功能模組之間保持著一定的組合關係，便形成的一個完整的專案。程式設計師一般都由獨立負責設計和開發一個模組做起，再慢慢摸清楚多個模組之間的上下游關係，便有了設計一個小型系統的能力。當然一開始不用著急是否設計的合理，以滿足功能需求為前提，再慢慢考慮系統設計的合理性，功能模組之間的依賴性。想做到高內聚，低耦合也非一朝一夕的事情。當然，成長的道路不會一帆風順，只有持續學習，砥礪前行，終會有成為大神的那一天。
上面都說的是如何進行功能設計，如何根據功能設計表呢？其實把功能設計好了，表設計也就自然而然的出來了。為了實現這個功能，我們依賴哪些上游資料？這個功能最終要記錄哪些資料？考慮好這兩個問題，表設計也就出來了。
程式=資料結構+演算法
這句話如何理解？一個專案可以理解為一個程式，那麼資料分為兩種資料：專案本身要獲取的資料、為了實現專案而做的中間資料。演算法呢？聽起來很厲害的樣子？實際做專案時候很少接觸到所謂的演算法，所以大家理解它為行為就好了。所以，個人認為對大多數做業務的同學來說：程式=資料+行為。多思考一下我上面說的，看看能否頓悟。
個人獨立負責過多箇中小型網際網路專案，接下來就分享一下個人在做專案的時候如何進行系統設計。
如果是負責整個專案的需求分析、系統設計工作，那麼第一要務是把需求文件看透，分析出這個專案的主業務流程，覺得自己可以掌握個七七八八的時候，把這個專案的業務流程圖畫出來，在畫圖的過程中，我相信你一定會對需求的細節有更深一層的理解和掌握，這樣也方便你後續的系統設計工作，所以先把業務主線抓住！剩下的細節再慢慢考慮。
如果是負責專案中的某一個功能點，那麼也得對這個功能的相關功能有一個大概的瞭解，同時在詳細閱讀需求文件的過程中，如果你有疑問，也不要自己憋著，有問題就問，包括合理的或者不合理的。參考敏捷開發中一個故事的描述：誰想要什麼功能以便能夠做什麼？例如：作為一個產品經理，我想要一個使用者打標籤的功能以便我可以根據不同的使用者分類推薦不同的內容，做更進一步的精細化運營。那麼在分析這個功能的同時，資料即使用者的標籤，行為呢？給使用者打標籤！那麼設計一張使用者標籤表，一個使用者可以打多個標籤，使用者已經有這個標籤就不再重複標記了。相信說到這裡大家已經知道這個表怎麼設計了，這個功能就是這麼簡單。
一個完整的專案由多個獨立的功能模組組成的，這些獨立的功能模組之間保持著一定的組合關係，便形成的一個完整的專案。程式設計師一般都由獨立負責設計和開發一個模組做起，再慢慢摸清楚多個模組之間的上下游關係，便有了設計一個小型系統的能力。當然一開始不用著急是否設計的合理，以滿足功能需求為前提，再慢慢考慮系統設計的合理性，功能模組之間的依賴性。想做到高內聚，低耦合也非一朝一夕的事情。當然，成長的道路不會一帆風順，只有持續學習，砥礪前行，終會有成為大神的那一天。
上面都說的是如何進行功能設計，如何根據功能設計表呢？其實把功能設計好了，表設計也就自然而然的出來了。為了實現這個功能，我們依賴哪些上游資料？這個功能最終要記錄哪些資料？考慮好這兩個問題，表設計也就出來了。