項(xiàng)目分析

1.需求分析

　　　根據(jù)原型設(shè)計(jì)稿，得到需求　

2.數(shù)據(jù)分析

?　　分析顯示數(shù)據(jù)和隱藏?cái)?shù)據(jù)，確定數(shù)據(jù)結(jié)構(gòu)

3.api分析

?　　完成原型上的數(shù)據(jù)，所需要的接口

4.組件分析

?　　vue的組件一般分為：

　　　　接入型 比如說一個(gè)容器組件,它里面包含了其他的組件，它本身只承擔(dān)一個(gè)布局容器的作用

　　　　展示型 純展示型的數(shù)據(jù)，它能接收數(shù)據(jù)，展示出來，但是無法與用用戶進(jìn)行交互

　　　　交互型 比如各類加強(qiáng)版的表單組件，通常強(qiáng)調(diào)復(fù)用

　　　　功能型 比如?<router-view>，<transition>，作為一種擴(kuò)展、抽象機(jī)制存在。

?

概念的介紹：

PM（產(chǎn)品經(jīng)理）
負(fù)責(zé)需求的提出和項(xiàng)目的引導(dǎo)。PM根據(jù)產(chǎn)品特點(diǎn)和發(fā)展目標(biāo)提出一定的需求，并協(xié)調(diào)各方資源投入開發(fā)。
若需求層面有不清晰的地方，應(yīng)當(dāng)向PM溝通確認(rèn)，如：需要做什么、希望達(dá)到什么效果、哪些內(nèi)容應(yīng)重點(diǎn)保證、哪些效果可以適當(dāng)取舍等；

RD（后端）
負(fù)責(zé)后端接口和數(shù)據(jù)邏輯。一般復(fù)雜邏輯和內(nèi)部數(shù)據(jù)會(huì)交由后端處理，并通過接口與前端交互。

FE（前端）
負(fù)責(zé)Web頁(yè)面（M頁(yè)）的界面展示和用戶交互。一般樣式、交互、動(dòng)效等用戶側(cè)的效果/體驗(yàn)由前端負(fù)責(zé)，并通過接口與后端進(jìn)行數(shù)據(jù)交互。

QA（測(cè)試）
負(fù)責(zé)整體質(zhì)量把控。在開發(fā)人員開發(fā)聯(lián)調(diào)完成后，一般需要由QA進(jìn)行系統(tǒng)性的測(cè)試，從而糾偏糾錯(cuò)&查缺補(bǔ)漏，保證上線質(zhì)量。
若QA誤提bug或誤給人員，應(yīng)協(xié)助處理：若為QA環(huán)境/測(cè)試方式問題可協(xié)助定位說明、若為接口問題可協(xié)助定位轉(zhuǎn)發(fā)、若為需求理解不一致可找PM確認(rèn)；
若問題已解決，應(yīng)及時(shí)關(guān)閉bug，使QA可以盡早驗(yàn)證。

Native（客戶端，Android&iOS）
負(fù)責(zé)客戶端APP的界面展示、用戶交互等，并向M頁(yè)提供WebView容器。轉(zhuǎn)轉(zhuǎn)APP、58APP、趕集APP等開發(fā)人員即為native開發(fā)人員，當(dāng)頁(yè)面運(yùn)行于這些APP中時(shí)，對(duì)應(yīng)native就是瀏覽器環(huán)境的提供者，比如我們想在原聲的app中設(shè)置title就需要調(diào)用native提供的方法。

ui（用戶界面）
負(fù)責(zé)項(xiàng)目的頁(yè)面樣式，動(dòng)畫效果的設(shè)計(jì)。

?

項(xiàng)目分哪幾個(gè)階段：

通常一個(gè)項(xiàng)目簡(jiǎn)單分為 四步：

需求階段

PM明確需求并協(xié)調(diào)好各方人力之后，一般會(huì)發(fā)起需求評(píng)審，將開發(fā)、測(cè)試等相關(guān)人員聚集在一起，闡述需求具體內(nèi)容并接受反饋和建議。
需求評(píng)審主要意義在于：

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

需求評(píng)審環(huán)節(jié)FE應(yīng)做的事：

閱讀、梳理需求文檔。PM一般會(huì)先發(fā)需求文檔，后進(jìn)行需求評(píng)審。評(píng)審前應(yīng)先閱讀好文檔，并梳理其中的疑惑點(diǎn)和技術(shù)難點(diǎn)。
明確需求。評(píng)審過程應(yīng)充分理解自己所需要完成的內(nèi)容，不清晰之處應(yīng)向PM確認(rèn)、明確。
溝通反饋。有潛在的技術(shù)問題/風(fēng)險(xiǎn)，應(yīng)及時(shí)向PM反饋，使其提前思考應(yīng)對(duì)/替代方案。
理解目的。理解PM此次需求的主要目的，明白需求中哪些內(nèi)容應(yīng)重點(diǎn)保證，哪些內(nèi)容可以適當(dāng)取舍，避免在某些棘手卻無關(guān)緊要的小功能上面浪費(fèi)過多精力。
注意：
需求評(píng)審主要目的在于需求，具體實(shí)現(xiàn)細(xì)節(jié)應(yīng)在會(huì)后相關(guān)人員自行溝通，避免耽誤其他人時(shí)間。

排期

需求明確之后，然后排期，即：預(yù)期什么時(shí)候開始投入開發(fā)、什么時(shí)候能達(dá)到什么進(jìn)度、什么時(shí)候可以上線等。

開發(fā)階段

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

測(cè)試階段

有些難點(diǎn)邏輯以及測(cè)試點(diǎn)及時(shí)和QA同學(xué)溝通，反饋

上線階段

主動(dòng)把“測(cè)試用例”（也就是所有的功能點(diǎn)）在 重新走一遍。

?

如何排期:

通常一個(gè)項(xiàng)目簡(jiǎn)單分為 四步：

• 需求階段
  ? 收集需求 ? 分析需求 ? 產(chǎn)出需求 ? 需求文檔 ? 評(píng)審需求 ? 分配資源 ? 技術(shù)調(diào)研 ? 評(píng)估工作量 ? 制定排期

• 開發(fā)階段
  ? 接口評(píng)審 ? 測(cè)試用例評(píng)審 ? Coding ? 自測(cè) ? 聯(lián)調(diào) ? 提測(cè)

• 測(cè)試階段
  ? 冒煙測(cè)試 ? 功能測(cè)試 ? 兼容性測(cè)試 ? 性能測(cè)試 ? 回歸測(cè)試

• 上線階段
  ? 總結(jié)

簽到活動(dòng)排期.jpg

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

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

需要實(shí)現(xiàn)哪些效果，如：下拉刷新、無限加載、tab吸頂、動(dòng)畫特效等
有哪些交互，如：按鈕點(diǎn)擊響應(yīng)、下拉響應(yīng)等
有哪些模塊，如：Banner模塊、分類入口模塊、商品列表模塊等

時(shí)間&風(fēng)險(xiǎn)評(píng)估
評(píng)估各模塊各功能的工作量和可能存在的風(fēng)險(xiǎn)，工作量估算為時(shí)間，風(fēng)險(xiǎn)項(xiàng)預(yù)留一定時(shí)間，累加得到大概的整體所需工時(shí)。
結(jié)合自身其它工作安排和其它項(xiàng)目進(jìn)度，估算可投入新項(xiàng)目的時(shí)間段，得到初步排期。

推動(dòng)依賴資源
對(duì)于需要依賴的外部資源，應(yīng)當(dāng)提前聯(lián)系相關(guān)人員，使其提前做好準(zhǔn)備，避免需要時(shí)缺失影響后續(xù)流程。
根據(jù)依賴資源的預(yù)期就緒時(shí)間，調(diào)整排期。

技術(shù)調(diào)研
對(duì)于需求中較不熟悉較無把握存在較大風(fēng)險(xiǎn)的內(nèi)容，優(yōu)先進(jìn)行技術(shù)調(diào)研。
這樣，一是可以更科學(xué)地評(píng)估工作量，及早修正排期；二是可以避免無謂的支出，比如若將難題留到最后，可能會(huì)發(fā)現(xiàn)難題實(shí)在無法解決，不得不調(diào)整需求修改方案，導(dǎo)致此前開發(fā)全部都要推倒重來。

解決問題的方法

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

轉(zhuǎn)載于:https://www.cnblogs.com/Abner5/p/6912861.html

總結(jié)

以上是生活随笔為你收集整理的【转】前端开发流程的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。