[[342444]]

本文轉(zhuǎn)載自微信公眾號(hào)「小鹿動(dòng)畫學(xué)編程」，作者小鹿。轉(zhuǎn)載本文請(qǐng)聯(lián)系小鹿動(dòng)畫學(xué)編程公眾號(hào)。

有很多在校生給我留言，希望小鹿分享一下工作的前端開發(fā)流程以及規(guī)范。對(duì)于在校生說，很難接觸到一些企業(yè)中的工作流程，所以今天爬上來，談?wù)勄岸讼嚓P(guān)的開發(fā)流程和規(guī)范，不對(duì)，是項(xiàng)目經(jīng)理小姐姐非要爬上來給我講一講，前端的開發(fā)規(guī)范和工作流程。

對(duì)于前端開發(fā)規(guī)范和工作流程，無容置疑，不同公司是不一樣的，有的公司領(lǐng)導(dǎo)認(rèn)為沒必要，有的公司領(lǐng)導(dǎo)卻非常重視。對(duì)于兩種不同的公司，分別展開談?wù)劙伞?/p>

1

之前實(shí)習(xí)的時(shí)候，在一家一千多人的二線城市公司，入職之后，感覺這種公司應(yīng)該挺規(guī)范的，畢竟在二線屬于大點(diǎn)的公司了，但是我和想象的還是有點(diǎn)差距的。

對(duì)于開發(fā)流程，沒有正規(guī)的開發(fā)流程，客戶要什么功能，只能和產(chǎn)品經(jīng)理溝通，然后產(chǎn)品經(jīng)理直接下發(fā)開發(fā)開發(fā)任務(wù)，實(shí)習(xí)了四個(gè)多月，我至今沒看到過需求文檔，有時(shí)候在開發(fā)的時(shí)候，遇到一些不理解的需求，根本不知道找誰問這個(gè)項(xiàng)目的需求問題。

幾次會(huì)議上，我也簡(jiǎn)單的提了下，要不要咱們寫一下需求文檔，最起碼我們團(tuán)隊(duì)每個(gè)人能知道開發(fā)的整個(gè)應(yīng)用每個(gè)功能是什么。其實(shí)，說了白說，公司不會(huì)因?yàn)槟愕囊痪湓捑蜁?huì)讓專門的人來寫需求文檔，有點(diǎn)不太現(xiàn)實(shí)，沒辦法，只能干自己的活，拿自己的錢就完事了。

2

在這穿插點(diǎn)小插曲，可能寫到這，很多人會(huì)問小鹿，為什么非要認(rèn)為開發(fā)功能一定要寫需求文檔，而且還要讓專業(yè)的人能力強(qiáng)的人來寫呢?

而且寫需求文檔既浪費(fèi)時(shí)間又耗費(fèi)人力，感覺有點(diǎn)不劃算呀。如果我們把眼光放近看，確實(shí)費(fèi)力不討好。如果你知道二八原則，之前文章中多次提到過，20% 的原因會(huì)影響到 80% 的結(jié)果，一旦需求搞不明白或者不加以重視，后期用再穩(wěn)定的技術(shù)，讓再牛B的人開發(fā)，都是在做無用功。

以上簡(jiǎn)單的談了一下之前公司的項(xiàng)目開發(fā)規(guī)范，不，沒有規(guī)范。這往往會(huì)出現(xiàn)很多的問題，比如會(huì)經(jīng)常出現(xiàn)以下這種問題，就是你可能用一星期或者更長(zhǎng)時(shí)間開發(fā)的一個(gè)功能，到最后發(fā)現(xiàn)并不是客戶所想的，所以你不得不去重新理解需求，重新進(jìn)行開發(fā)，說白了，浪費(fèi)你不少對(duì)技術(shù)的感情。

3

目前所在的公司，無論是在開發(fā)規(guī)范還是工作流程上，我個(gè)人認(rèn)為，無論是對(duì)團(tuán)隊(duì)還是對(duì)個(gè)人，還是非常的清晰和規(guī)范的。

先說說開發(fā)規(guī)范，前端的開發(fā)規(guī)范之前在公眾號(hào)發(fā)表過，這就是我們現(xiàn)在的整個(gè)前端開發(fā)規(guī)范。

老大教科書般告訴我，什么是開發(fā)規(guī)范 ?

對(duì)于工作開發(fā)的流程，和大家分享一下。主要用到的工具有一下幾個(gè)：

1、Confluence(產(chǎn)品迭代)

2、Zeplin(UI設(shè)計(jì))

3、Swagger(接口文檔)

4、Bitbucket(公共倉庫)

5、Jira(任務(wù)分配)

6、JenKins(自動(dòng)化部署)

對(duì)于一個(gè)新的產(chǎn)品或者新的版本，首先產(chǎn)品經(jīng)理寫需求文檔，然后通過 Confluence 發(fā)布到公司內(nèi)網(wǎng)，所有人(開發(fā)、測(cè)試等)都可以看到新的需求。

然后開始前后臺(tái)團(tuán)隊(duì)人員開會(huì)，分配開發(fā)任務(wù)，每個(gè)功能誰來做，開發(fā)周期幾天，一般開發(fā)周期是工時(shí)✖️1.5倍，需要預(yù)留出改 bug 的時(shí)間。

預(yù)估好開發(fā)工時(shí)，可以各自進(jìn)行開發(fā)了，從總倉庫開始 fork 項(xiàng)目，開始在本地進(jìn)行 clone 克隆，每開發(fā)完一個(gè)項(xiàng)目，都要進(jìn)行原子化的提交，所謂的原子化，每次提交只能提交你修改的一個(gè)功能或者一個(gè) bug。

提交 commit 也是有規(guī)范的，必須說明你是新增功能還是修改了一個(gè) bug 或者其他操作需要選擇對(duì)應(yīng)的配置選項(xiàng)，然后寫提交描述，全部將本地提交完成之后，然后給總倉庫提交一個(gè) Pr，老大審核過后，你寫的代碼就能正常的合并到總倉庫中去了。

此時(shí)你寫的功能，測(cè)試的小姐姐開始進(jìn)行第一次測(cè)試，如果有問題，會(huì)通過 Jira 分配任務(wù)到你的賬戶下(這周小鹿的 bug 確實(shí)有點(diǎn)多，以圖為例，扎心了，哈哈哈)，如下：

這么一看一清二楚了吧，哪些 bug 還沒開始改，哪些正在改，以及改完待測(cè)試的有哪些，都會(huì)一清二楚的進(jìn)行分類。

當(dāng)你改完 bug 之后，將改 bug 任務(wù)拖入到待測(cè)試，然后測(cè)試小姐姐哪里就會(huì)知道，哦，小鹿這個(gè) bug 改完了，我可以進(jìn)行測(cè)試了，如果測(cè)試通過，測(cè)試小姐姐會(huì)把你的任務(wù)拉如到待上線的一欄中。

整個(gè)開發(fā)流程就是這個(gè)樣子的，每個(gè)人都在這條流水線上有序的干著屬于自己的那一部分，以上聊的是改 bug 的工作流程。

其實(shí)我們前端在開發(fā)新頁面時(shí)，也有一套工作流程，首先我們?cè)?Zeplin 看到 UI 設(shè)計(jì)圖，然后根據(jù)設(shè)計(jì)圖進(jìn)行開發(fā)，開發(fā)完成之后，提交代碼，在 Jira 中將開發(fā)任務(wù)拖至待 UI 確認(rèn)，UI 確認(rèn)無誤后，你就可以對(duì)該頁面進(jìn)行開發(fā)一些交互的功能。

小結(jié)

以上主要大概的寫了下現(xiàn)在的開發(fā)流程和前端開發(fā)規(guī)范，里邊還有很多需要注意的細(xì)節(jié)沒有詳細(xì)的說到，因?yàn)槊總€(gè)公司都是不一樣的，以后可能你進(jìn)入一家公司會(huì)有自己的工作流程和開發(fā)規(guī)范，今天寫這篇文章主要目的，還是讓在校生主要了解一下以后工作后的開發(fā)流程。