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