值得參考的項目開發流程
- 2019 年 12 月 30 日
- 筆記
摘要： 科學的開發流程可以提高效率，減少不必要的加班。
- 原文：對項目開發流程的思考和小結
- 作者：zzzzou
Fundebug經授權轉載，版權歸原作者所有。
最近在項目開發中遇到的問題
- 對要開發的產品的最終形態沒有明確的了解，沒有明確的目的性，導致多次返工，重新設計。
- 沒有明確的開發順序，開發的模塊東一塊西一塊不流暢不連貫,導致模塊之間耦合太高，代碼散落多處難以繼續開發和維護。
- 沒有系統設計結構圖，沒有區分數據層面、控制層面、業務層面、展示層面、交互層面、界面層面，不能隨時了解當下的開發位置和進度，無法預計後續開發的時間和下一個合適的開發位置。
- 代碼寫的過分冗餘，不夠優美，主要是因為沒有寫偽代碼來說明一個函數中每一部分的邏輯以及邏輯上下的關係。
- 代碼寫的過分硬編碼，不夠抽象，當發現要抽象的時候，需要重新修改之前的編碼。
- 沒有考慮數據交互的結構設計，數據結構設計應該單獨拎出來作為單獨函數封裝以便後續擴展
- 花過多的時間在界面設計上，時間浪費在過多的樣式調整上。
- 每次編碼沒有寫上測試的內容，開發進度被多次延誤，不能保證代碼的正確性，基礎性的bug過多。
仔細的梳理流程後，大致整理了如下幾個步驟。
第一部分、分析和規劃設計
如下2步，需要畫圖、筆記、文字記錄、演算、推理、畫流程圖、畫架構圖
1、產品選型
明確產品界面、交互設計、功能設計、模塊區分，尋找相仿的產品上手體驗、操作，感知功能的使用和交互的體驗，目的是為了了解即將要做的產品有大致的模型,對產品模型了解的越細緻越好
2、分離架構
對產品從各個維度分離架構，從功能，目錄，邏輯拆分，抽象，業務流的明確，數據流的流向，交互體驗的設計，從整體拆分成局部，針對每個局部再繼續拆分，從局部整合成系統，考慮整體和局部之間的相互影響關係
循環這2步，最終得到一個產品系統，應該對產品系統非常了解，從整體到局部，從需求到邏輯，端到端的數據流向，交互體驗設計，數據庫表結構設計
第二部分、實施
3、文檔編寫
按照系統的各個區域和子系統，編寫對應的文檔注釋，說明此子系統的功能、大致邏輯、含有的接口。
此外，流程應該按照先數據庫層面 –> 邏輯控制層面 –> 數據展示層面 –> 交互體驗層面 –> 界面設計層面的順序來規劃和思考。
同時考慮擴展性的問題，子系統是否可插拔，組件之間是否強依賴，必要的時候完成架構層面大的抽象。
文檔需要大概明確此子系統模塊的測試結果是什麼，提前演算模塊的測試步驟和結果，後續細化的代碼必須要通過此測試要求。
4、技術選型
明確每一個子系統和組件需要使用到的工具、框架、第三方庫、以及重要的語法或者類設計、或者編程技巧、或者設計模式等等。
5、開發順序確認
明確這個系統的各個部分的開發順序，獨立的子系統先開發，耦合依賴強烈的系統最後開發，簡單的先開發，難的後開發。 規劃好開發進度計劃。 先開發數據庫層面的代碼，再開發數據控制層面，再開發數據交互層面，再是數據展示，交互體驗設計，界面開發應該放到最後，界面開發最花時間。
6、偽代碼編寫
使用中文表達邏輯，加上必要的編程語法混合表達。
偽代碼的編寫是必須的，而且偽代碼要寫到可以直接演算出代碼結果的程度，即可以通過編寫偽代碼來幾乎100%的確定是否符合模塊測試的要求。
偽代碼必須要完成數據交互的結構設計。
偽代碼必須要對函數有明確的定義和解釋，可以說明此函數的作用。
7、編碼
編碼必須符合偽代碼的邏輯，編碼應該多次測試，慢步前進。
注意編碼的版本控制。
編碼應該盡量保持優美的邏輯和語法使用。
編碼的變量命名應該特別注意。
每一次的編碼應該最低按照一個函數單元，即最小編碼單位是一個函數，一旦決定編碼，就至少完成一個函數單元，或者取消本次函數的編寫。
每個函數的完成，都必須要達到偽代碼對此函數的定義和解釋，注意高內聚和低耦合的問題。
如果沒有高內聚，要適當拆分邏輯和代碼。
如果沒有低耦合，要適當抽象代碼，合併其他同類函數。
8、代碼review，優化代碼
以上每一步，如果出現重大問題和困難，應該向上返回尋找解決方案，因為這些順序有強烈的依賴性，所以向上找到源頭重新設計規劃。
也正因為步驟之間的順序強依賴性，後一步都強烈依賴於前一步，所以前面的步驟必須打好基礎，才可以減少返工重新設計和規劃的問題。
不是每一步都必須要做到完美，也不是每一個項目都需要使用到每一步，就像PMP一樣，是一個套路，需要合理按需使用，但是整體的規划到實施的邏輯是要保證的。
多按照這種套路來完成目的，大部分的事件都在鍛煉思考和規劃設計能力，編碼只是最後實現的一塊而已。
總結
- 開發最小單元應該是一個函數
- 慢步前進，多做測試
- 先有數據，再有邏輯
- 不要花太多時間在界面上
- 偽代碼非常重要，必須要寫
- 文檔注釋非常重要，必須要寫
- 數據庫設計永遠是第一步，每次修改、規劃設計、增加功能、維護、都首先考慮數據庫，所有的代碼都圍繞着數據庫的數據進行設計、開發
- 編碼應該是最後的實現手段，應該是最後的環節
- 多思考，少編碼，思考的越多，錯誤越少。
- 適當的冗餘和抽象
版權聲明
轉載時請註明作者 Fundebug以及本文地址： https://blog.fundebug.com/2019/05/06/steps-of-develop-product/
您的用戶遇到BUG了嗎？
.copyright *{box-sizing:border-box}
