前言：

對於初入職場的前端小白來說，一整個項目來了，頓時感覺壓力山大，張皇失措，也總會感到手忙腳亂。其實不用怕，拆分步驟，把每個步驟做好，做細，一切都迎刃而解，猶如順藤摸瓜般暢快淋漓。

目錄：

• 概念的介紹（可略）
• 項目分哪幾個階段(每個階段註意什麽)
• 如何排期
• 解決問題的方法

概念的介紹：

PM（產品經理）
負責需求的提出和項目的引導。PM根據產品特點和發展目標提出一定的需求，並協調各方資源投入開發。
若需求層面有不清晰的地方，應當向PM溝通確認，如：需要做什麽、希望達到什麽效果、哪些內容應重點保證、哪些效果可以適當取舍等；

RD（後端）
負責後端接口和數據邏輯。一般復雜邏輯和內部數據會交由後端處理，並通過接口與前端交互。

FE（前端）
負責Web頁面（M頁）的界面展示和用戶交互。一般樣式、交互、動效等用戶側的效果/體驗由前端負責，並通過接口與後端進行數據交互。

QA（測試）
負責整體質量把控。在開發人員開發聯調完成後，一般需要由QA進行系統性的測試，從而糾偏糾錯&查缺補漏，保證上線質量。
若QA誤提bug或誤給人員，應協助處理：若為QA環境/測試方式問題可協助定位說明、若為接口問題可協助定位轉發、若為需求理解不一致可找PM確認；
若問題已解決，應及時關閉bug，使QA可以盡早驗證。

Native（客戶端，Android&iOS）
負責客戶端APP的界面展示、用戶交互等，並向M頁提供WebView容器。轉轉APP、58APP、趕集APP等開發人員即為native開發人員，當頁面運行於這些APP中時，對應native就是瀏覽器環境的提供者，比如我們想在原聲的app中設置title就需要調用native提供的方法。

ui（用戶界面）
負責項目的頁面樣式，動畫效果的設計。

項目分哪幾個階段：

通常一個項目簡單分為 四步：

• 需求階段
  ? 收集需求 ? 分析需求 ? 產出需求 ? 需求文檔 ? 評審需求 ? 分配資源 ? 技術調研 ? 評估工作量 ? 制定排期

• 開發階段
  ? 接口評審 ? 測試用例評審 ? Coding ? 自測 ? 聯調 ? 提測

• 測試階段
  ? 冒煙測試 ? 功能測試 ? 兼容性測試 ? 性能測試 ? 回歸測試

• 上線階段
  ? 總結

需求階段

PM明確需求並協調好各方人力之後，一般會發起需求評審，將開發、測試等相關人員聚集在一起，闡述需求具體內容並接受反饋和建議。
需求評審主要意義在於：

• 明確需求，確保各方理解一致。避免實現過程與預期效果背道而馳。
• 風險評估，問題及早暴露。若PM預期方案中存在較大的技術問題，技術人員可在評審時予以指出，從而及早思考對策。
• 交流碰撞，方案權衡。技術人員反饋各內容實現難度和實現成本，PM權衡哪些內容優先實現，哪些內容采用替代方案，哪些內容予以舍棄。

需求評審環節FE應做的事：

閱讀、梳理需求文檔。PM一般會先發需求文檔，後進行需求評審。評審前應先閱讀好文檔，並梳理其中的疑惑點和技術難點。
明確需求。評審過程應充分理解自己所需要完成的內容，不清晰之處應向PM確認、明確。
溝通反饋。有潛在的技術問題/風險，應及時向PM反饋，使其提前思考應對/替代方案。
理解目的。理解PM此次需求的主要目的，明白需求中哪些內容應重點保證，哪些內容可以適當取舍，避免在某些棘手卻無關緊要的小功能上面浪費過多精力。
註意：
需求評審主要目的在於需求，具體實現細節應在會後相關人員自行溝通，避免耽誤其他人時間。

排期

需求明確之後，然後排期，即：預期什麽時候開始投入開發、什麽時候能達到什麽進度、什麽時候可以上線等。

開發階段

梳理需求，對整體效果進行功能拆分和模塊拆分，包括：樣式、動效、交互、數據接口、native接口、外部資源等，把功能細化。
兼容性測試：多為樣式兼容性。盡可能在各終端下進行測試，尤其是低端安卓機下，出現問題的可能性比較大。

測試階段

有些難點邏輯以及測試點及時和QA同學溝通，反饋

上線階段

主動把“測試用例”（也就是所有的功能點）在 重新走一遍

如何排期:

一個項目的工作量約五天,你最好把排期細化，假如你5天沒有做完，那大家會覺得你不靠譜久而久之，覺得你能力不行，如果你訂了五天，但是四天就搞定了，在同事之間大大增加信任 也會增加自己的信心，可見一個好的排期多麽重要。
通常情況下，FE需要等UI出圖然後排期，但排期前也可以做些整理

理清需求中：
依賴哪些外部資源，如：需要rd提供哪些接口、需要pm提供哪些數據（埋點、分享文案、分享圖片...）、ui圖中哪些需要切圖，如何布局，哪部會後期可能頻繁改動，是否需要sdk新增native接口支持等等。

需要實現哪些效果，如：下拉刷新、無限加載、tab吸頂、動畫特效等
有哪些交互，如：按鈕點擊響應、下拉響應等
有哪些模塊，如：Banner模塊、分類入口模塊、商品列表模塊等

時間&風險評估
評估各模塊各功能的工作量和可能存在的風險，工作量估算為時間，風險項預留一定時間，累加得到大概的整體所需工時。
結合自身其它工作安排和其它項目進度，估算可投入新項目的時間段，得到初步排期。

推動依賴資源
對於需要依賴的外部資源，應當提前聯系相關人員，使其提前做好準備，避免需要時缺失影響後續流程。
根據依賴資源的預期就緒時間，調整排期。

技術調研
對於需求中較不熟悉較無把握存在較大風險的內容，優先進行技術調研。
這樣，一是可以更科學地評估工作量，及早修正排期；二是可以避免無謂的支出，比如若將難題留到最後，可能會發現難題實在無法解決，不得不調整需求修改方案，導致此前開發全部都要推倒重來。

解決問題的方法

1.對於新手來講編碼中我們要關心兩件事，一，數據的變化 。二，數據變化後結構樣式的變化。
2.很多看似很棘手的問題，往往都是自己粗心所導致的比如變量名字不對啊，少打個符號，環境問
題也不容忽視，二分法要常用，簡單講就是先拿掉一部分代碼，看另一部分有沒有誤。
3.若開發過程中發現項目工作量與預期有嚴重出入，或遇到高優先級項目介入等特殊情況，導致無法按照預期時間點完成項目內容，應當盡早向項目其他人員反饋，方便其修改時間安排。
4.事情一件一件做，最好不要多線程容易漏掉事情，專心做一件才會做的更好。
5.把每天要做的事情寫在有道或者印象筆記裏，也知道哪些需要做，哪些不需要做，到最後周報也不會忘記。
6.多用google搜索，到最後你會發現google搜索的人，技術就是比百度搜索的人要好一點。
7.溝通方法很重要，在講述一個問題時要把問題的背景以及目的等說清楚，可以很快讓聽者明白你的意圖。

初入前端，面對一個項目應註意哪些？