[[342444]]

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

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

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

1

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

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

幾次會議上，我也簡單的提了下，要不要咱們寫一下需求文檔，最起碼我們團(tuán)隊每個人能知道開發(fā)的整個應(yīng)用每個功能是什么。其實，說了白說，公司不會因為你的一句話就會讓專門的人來寫需求文檔，有點不太現(xiàn)實，沒辦法，只能干自己的活，拿自己的錢就完事了。

2

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

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

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

3

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

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

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

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

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

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

3、Swagger(接口文檔)

4、Bitbucket(公共倉庫)

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

6、JenKins(自動化部署)

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

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

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

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

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

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

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

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

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

小結(jié)

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