前端開(kāi)發(fā)的流程與規(guī)范.doc

《前端開(kāi)發(fā)的流程與規(guī)范.doc》由會(huì)員分享，可在線閱讀，更多相關(guān)《前端開(kāi)發(fā)的流程與規(guī)范.doc（5頁(yè)珍藏版）》請(qǐng)?jiān)谘b配圖網(wǎng)上搜索。

前端開(kāi)發(fā)的流程與規(guī)范 在團(tuán)隊(duì)不斷成長(zhǎng)的過(guò)程中，需要處理的需求也在逐漸增長(zhǎng)，團(tuán)隊(duì)中成員如何分工配合決定了開(kāi)發(fā)的效率、產(chǎn)品的質(zhì)量，在這個(gè)時(shí)候我們就需要一個(gè)流程來(lái)規(guī)范、指導(dǎo)我們，下面就將咱們前端組的一些經(jīng)驗(yàn)跟大家分享一下，有不足之處歡迎大家指出來(lái)。 當(dāng)PRD確立下來(lái)后，前端組的同學(xué)們就需要做好準(zhǔn)備，好應(yīng)對(duì)高強(qiáng)度的開(kāi)發(fā)工作。在今年年初的時(shí)候前端組經(jīng)過(guò)激烈的討論針對(duì)新產(chǎn)品的開(kāi)發(fā)做了一些約定。制定 了前端開(kāi)發(fā)的一些相關(guān)的規(guī)范，包括不同產(chǎn)品的命名規(guī)范，前端文件存放目錄等等一系列的前期準(zhǔn)備。別看這些只是小事，但做好萬(wàn)全的準(zhǔn)備，是敏捷開(kāi)發(fā)中所必 的。 下面講講前端開(kāi)發(fā)組的流程。 1、分層開(kāi)發(fā) 在PRD確定后就需要進(jìn)行分層開(kāi)發(fā)的劃分，根據(jù)項(xiàng)目?jī)?nèi)容的不同，劃分組員的工作。大致分為，總體結(jié)構(gòu)搭建、模塊制作、頁(yè)面制作、底層JS搭建、JS交互效果、內(nèi)部測(cè)試、代碼優(yōu)化。 這樣做的好處是能根據(jù)項(xiàng)目的不同，劃分出不同的功能模塊，合理的進(jìn)行人員分配，讓合適的人做合適的事。降低開(kāi)發(fā)成本，提高開(kāi)發(fā)效率。 2、代碼編寫(xiě) 前期工作準(zhǔn)備好后，就開(kāi)始進(jìn)入代碼編寫(xiě)階段，我們采用LSM方式進(jìn)行，大致流程為 prototype產(chǎn)出后，就進(jìn)行前期的前端開(kāi)發(fā)（搭建大致的HTML結(jié)構(gòu)），然后設(shè)計(jì)出完設(shè)計(jì)稿后再進(jìn)行頁(yè)面樣式的完善，最后完成正式的頁(yè)面后交給開(kāi) 發(fā)，嵌套程序。這樣做的好處不僅能有效的提高開(kāi)發(fā)效率，實(shí)現(xiàn)逐層開(kāi)發(fā)，讓前端提前介入，減少整體消耗的時(shí)間，確保產(chǎn)品有更多的時(shí)間修改和完善。 確定了流程后還需要對(duì)產(chǎn)品原型進(jìn)行分析、拆分，把復(fù)用性高的部分找出來(lái)制作成代碼模塊，方便以后的套用。確認(rèn)二、三級(jí)頁(yè)面的風(fēng)格搭建統(tǒng)一框架。 設(shè)計(jì)拿到prototype后，就進(jìn)行通用模塊樣式的設(shè)計(jì)（包括按鈕、分頁(yè)、默認(rèn)字體顏色、連接顏色等），完成后并提交給前端，統(tǒng)一的搭建。 在代碼的編寫(xiě)過(guò)程中，最重要的是標(biāo)準(zhǔn)和規(guī)范的執(zhí)行遵守，在編寫(xiě)HTML時(shí)候充分發(fā)揮想象盡可能的滿(mǎn)足后期樣式表現(xiàn)的需要。 代碼編寫(xiě)過(guò)程中讓前端組提前進(jìn)入開(kāi)發(fā)流程中來(lái)，在prototype產(chǎn)出后就進(jìn)行HTML結(jié)構(gòu)的編寫(xiě)，頁(yè)面設(shè)計(jì)完成后，在進(jìn)行樣式表的開(kāi)發(fā)，這樣不僅能節(jié) 省很多的開(kāi)發(fā)時(shí)間，提高開(kāi)發(fā)效率，還能鍛煉前端組的同學(xué)對(duì)全局頁(yè)面的把控。在此同時(shí)也強(qiáng)調(diào)規(guī)范和模塊化的重要性，正所謂無(wú)規(guī)矩不成方圓，在一個(gè)團(tuán)隊(duì)協(xié)同開(kāi) 發(fā)過(guò)程中，必須要嚴(yán)格按照規(guī)范執(zhí)行，這樣能便于后期維護(hù)，減少維護(hù)成本。而模塊化，是敏捷開(kāi)發(fā)所必需的，重要性在這里也不做過(guò)多的描述。 3、內(nèi)部測(cè)試與后續(xù)優(yōu)化 所有頁(yè)面出完以后設(shè)計(jì)參與前端組的內(nèi)部測(cè)試，指出頁(yè)面與設(shè)計(jì)稿不匹配的地方，優(yōu)化部分細(xì)節(jié)頁(yè)面樣式。讓設(shè)計(jì)參與測(cè)試不僅能提高內(nèi)測(cè)的質(zhì)量，還能更早的發(fā)現(xiàn) 問(wèn)題并及時(shí)的修改，否則當(dāng)頁(yè)面提交開(kāi)發(fā)以后再做修改是一件很麻煩的事情。當(dāng)所有細(xì)節(jié)修改完畢后，就需要進(jìn)行制作文件的優(yōu)化以確保代碼的最優(yōu)化，盡可能地壓 縮圖片和減少外部HTTP請(qǐng)求。 總的流程結(jié)構(gòu)圖 這套流程制定出來(lái)就一直要求所有前端組同學(xué)嚴(yán)格按照流程執(zhí)行，也經(jīng)過(guò)了很長(zhǎng)時(shí)間的磨合跟改進(jìn)。雖然不是很完美，但是很適合我們現(xiàn)在開(kāi)發(fā)的需要，好處也是顯 而易見(jiàn)的，遵循并使用它對(duì)我們的發(fā)開(kāi)有很大的幫助，能更好的應(yīng)對(duì)高強(qiáng)度，高質(zhì)量的開(kāi)發(fā)需要。提高了團(tuán)隊(duì)的協(xié)作程度，代碼更可控，開(kāi)發(fā)效率更高。 ======================================================================================= 1.1 我的理解 傳統(tǒng)方式：產(chǎn)品經(jīng)理產(chǎn)出 PRD -> 交互產(chǎn)出 prototype -> 視覺(jué)產(chǎn)出 mockup -> 前端產(chǎn)出 demo LSM 方式：PRD -> prototype -> a). 前端做 html b). 視覺(jué)做 mockup -> 前端完善 demo 2.1 疑惑與討論 1). 后續(xù)環(huán)節(jié)受前面的影響。這點(diǎn)上，兩種方式都受影響。并且前端介入的時(shí)間越早，當(dāng) PRD 和 prototype 變動(dòng)時(shí)，整體耗費(fèi)的時(shí)間越多。解決此問(wèn)題的關(guān)鍵不是流程順序，而是保證流程產(chǎn)出物的穩(wěn)定性。PRD, prototype, mockup 的穩(wěn)定性，是減少返工的關(guān)鍵因素。 2). 網(wǎng)站的規(guī)范。這個(gè)和流程關(guān)系不大，難的是規(guī)范的制定。開(kāi)發(fā)一個(gè)具體頁(yè)面 page, page 處于某個(gè)應(yīng)用 app 下，app 從屬某個(gè)系統(tǒng) sys. 當(dāng)規(guī)范成熟后，開(kāi)發(fā)順序是：將 sys 規(guī)范應(yīng)用到 page -> 將 app 規(guī)范應(yīng)用到 page -> 進(jìn)行與特定 page 相關(guān)的工作。前兩步經(jīng)常很快，耗時(shí)不多。 3). 標(biāo)準(zhǔn)模塊，或者說(shuō)是 DPL（設(shè)計(jì)模式庫(kù)）。這個(gè)和規(guī)范類(lèi)似，與流程關(guān)系不大。 4). 當(dāng)規(guī)范成熟、標(biāo)準(zhǔn)模塊成型后，傳統(tǒng)方式的效率很高。LSM 方式中，前端根據(jù) prototype, 應(yīng)用 sys 和 app 的全局規(guī)范和標(biāo)準(zhǔn)，產(chǎn)出 html 是很快的。而視覺(jué)產(chǎn)出 mockup 是精雕細(xì)琢的過(guò)程，往往耗時(shí)較多。這導(dǎo)致的問(wèn)題是，前端根據(jù) prototype 能做的東西很少，依舊要等 mockup 出來(lái)后，才能開(kāi)始耗時(shí)最多的工作。 5). 感覺(jué)克軍的核心是推崇規(guī)范和標(biāo)準(zhǔn)模塊的重要性，而不是流程。重要的是將可重用的設(shè)計(jì)和代碼提煉歸納，成為共用的模式庫(kù)。 6). 如果說(shuō)有銀彈，我覺(jué)得是 DPL. 前端的重用提煉為框架類(lèi)庫(kù)，交互的重用提煉為交互模式庫(kù)，再加上視覺(jué)規(guī)范，就成型為一個(gè)個(gè)標(biāo)準(zhǔn)模塊。每個(gè)模塊，都凝結(jié)著交互、視覺(jué)和前端的提煉。 7). DPL 不稀奇。MS WinForms, ExtJS, Yahoo DPL 等，都是成熟案例。做到這一步后，產(chǎn)品經(jīng)理甚至可以直接從 DPL 中挑選模塊組建頁(yè)面。交互和視覺(jué)，只需要關(guān)注整體以及與該 page 特定的交互和視覺(jué)，前端則關(guān)注新功能開(kāi)發(fā)和頁(yè)面整合。流程已經(jīng)不重要。 8). 但是，Web 唯一不變的就是變化。高質(zhì)量的 DPL 很難得，能隨心所欲“變化”的 DPL 更難得?，F(xiàn)實(shí)世界里，大量工作依舊無(wú)法模式化，銀彈是不存在的。 3.1 我的想法 對(duì)前端開(kāi)發(fā)流程，我的想法是： 假設(shè) sys 級(jí)的規(guī)范和標(biāo)準(zhǔn)模塊已經(jīng)完成（包括全局樣式、布局規(guī)范、標(biāo)準(zhǔn)盒模型等），這時(shí)需要開(kāi)發(fā)一個(gè)項(xiàng)目，假設(shè)為淘江湖 SNS 項(xiàng)目。理想中的開(kāi)發(fā)流程為： a). PD 產(chǎn)出 PRD. b). 交互統(tǒng)攬全局，將 PRD 中的可復(fù)用部分，拎取出來(lái)，產(chǎn)出 base-prototype. c-1). 視覺(jué)根據(jù) base-prototype，產(chǎn)出 base-mockup. c-2). 前端根據(jù) base-prototype 和 base-mockup 產(chǎn)出 app-dpl（該項(xiàng)目的 DPL）。 c-3). 交互繼續(xù)具體頁(yè)面的 page-prototype 產(chǎn)出工作。 以上三步是并行和迭代進(jìn)行的。 d-1). 視覺(jué)根據(jù) page-prototype 產(chǎn)出 page-mockup. d-2). 前端根據(jù) page-mockup 產(chǎn)出 page-demo. 以上兩步迭代進(jìn)行。 流程的核心是迭代、是敏捷、是短周期。 最重要的一步是 base-prototype 的產(chǎn)出。交互要避免一個(gè)頁(yè)面一個(gè)頁(yè)面的產(chǎn)出順序，而應(yīng)該先有一個(gè)統(tǒng)攬全局、拎取通用部分的步驟。 以上流程可以簡(jiǎn)述為：sys -> app -> page. app 層的抽取很重要，可以提高團(tuán)隊(duì)的開(kāi)發(fā)效率和協(xié)作程度，讓團(tuán)隊(duì)更融合、更高效。 感覺(jué) LSM 強(qiáng)調(diào)的是前端工程師實(shí)現(xiàn) demo 時(shí)的微流程。告訴我們做一個(gè)頁(yè)面時(shí)，需要 html 整體 -> 局部模塊的 css/js, 逐層開(kāi)發(fā)，先整體后局部，先框架后細(xì)節(jié)。這是非常好的最佳實(shí)踐。