序言
不斷總結完善方法論可以在類似的事物中提供指導和依據，下面是我作為前端游戲程式員對作業流程的經驗總結，考慮比較復雜的情況，據實際情況酌情簡化或者增加細節，本文多是經驗所得，主觀性較強，歡迎討論交流和批評！
流程
大概流程如圖所示，部分細節在下面說明
需求宣講
一般比較復雜的需求會要求策劃對需求進行宣講，需重點聽下需求涉及哪些領域，主要功能、流程，并初步判斷可行性、復雜度、成本等并提出相關建議
需求分析
先根據需求手冊和視覺稿流程、功能、細節、實作方式捋一遍，有必要的話（據經驗需求手冊并不把每個細節都講清楚）拽上策劃同學把有疑問的地方對一遍，
預研
在遇到不熟悉的領域或者一些復雜的技術，要提前驗證是否能夠實作和實作成本甚至做一個demo，另外，有些問題可能有多個解決方案調研選擇更合適的，
建模
可以在抽象的層面上大致的提供完成需求的理論模型，方便開發者伙伴之間溝通合作，并為開發編碼提供藍本，模型是編程語言之上對業務的抽象，理想情況下編碼前要“胸有成竹”，建模方法有很多，由于公司沒有要求特定方法，我一般采用類似DDD的方法，領域包含核心功能，支撐，和給外面用通用部分，必要時輔以流程和狀態圖，追求實用，
依賴確認
在開發前，先確認下配置表、協議、美術資源、依賴的介面的實作情況，理想情況是都準備好了，但是實際情況可能在開發中陸續交付，根據情況做好打算，另外，也有些別的模塊，可能要依賴此模塊，也要同其他開發者交代大概的時間，
反向宣講
此時需求基本確認完畢，準備開始開發了，做最后的確認，以要求中途不會變更需求和其他依賴交付的延期，并給出大概的開發周期，以方便其他伙伴準備作業日程，
開發
我大多從總體框架開始，即盡量從最上層的抽象入手，然后是確認邊界，包含各個抽象的職責范圍，職責的極端情況等，隨即就是對抽象具象化，我的習慣是從資料層開始，包含資料的增改刪查，以及各州資料變更必要的通知，然后是邏輯層，最后是表現層，這是個人經驗總結下來最高效的順序，我想大概是因為絕大多是情況下是資料驅動表現，開發完成（某個階段），需要進行階段性的測驗，對于前端來說，我一般會模擬下后臺發的資料，以盡量確定聯調出現的問題不是前端的問題，最后就是聯調和需求完整的自測，
驗收
開發和自測完成，要通知伙伴進行驗收，通常會有PM，策劃，美術（多是確認美術效果）及其他依賴此需求的小伙伴，處理驗收反饋和bug，然后轉測，通常還會處理一波反饋和bug，
歸檔
歸檔的目的一個是在于方便其他人了解需求和功能，這部分用的最多的就是通用部分的介面查詢，另外一個是方便自己review，以減少日后review的成本，出于此目的，我的檔案通常依順序包含如下幾部分：
- 需求檔案&視覺稿，以方便了解需求
- 參與者，以方便日后找解決問題的人
- 公共介面，方便外面查詢和使用
- 工程制圖，大部分是建模的制圖，方便日后自己和他人review
- 備注，常用的包含一些TODO，以及其他的說明
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/552940.html
標籤：其他
下一篇：返回列表