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

《前端開發(fā)的流程與規(guī)范.doc》由會員分享，可在線閱讀，更多相關《前端開發(fā)的流程與規(guī)范.doc（5頁珍藏版）》請在裝配圖網上搜索。

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