前端項目開發之經驗之談

前言

在不一樣的開發開發不一樣複雜程度的項目，一直想寫一篇項目開發中的一些我的總結以及經驗分享，本文主要講述咱們做爲前端開發在項目中須要注意的點以及一些我的的經驗之談。

關於流程

每一個公司都有本身的開發流程，在流程中須要注意的事項有不少，尤爲面對較爲複雜的項目，一個不注意，可能就會給本身挖坑，例如：對需求解讀的不完全，致使時間預估嚴重不夠等，所以，每一個環節都建議你們嚴謹認真，切不可粗枝大葉，一年之中，一個失誤就有可能讓你一個季度或者一年的努力白費，下面我羅列下我的認爲每一個環節須要注意的事項。

評審：

1. 需求評審前儘量先仔細解讀需求，瞭解需求產生的背景、做用、價值以及具體所須要作的事，瞭解每一個需求背後的背景、價值等有助於你培養對產品的大局觀，瞭解需求的詳細內容，有助於你更好的把控這個需求，掌握其所需的工做量和難度以及風險。
2. 交互評審時，明確每個交互點以避免遺漏致使工時評估不許確，若項目緊急可適當拒絕一些沒必要要的交互，此外，針對頁面初始化時的展現，最好跟交互明確下，是先出來頁面展現佔位數據，仍是頁面數據回傳前使用加載中動畫不顯示頁面或者是否須要啓用頁面龍骨架展現，這些細節都須要跟交互明確好並讓ui設計。
3. ui評審時，根據需求儘量對有疑問的點進行提問解決，針對一些場景，確認全部的交互點，以避免對咱們的設計開發形成影響，必要時可適當拒絕一些沒必要要的ui需求，減小工做量，原則上只要有助於提升產品體驗的ui需求都儘量知足。

技術方案：

技術方案儘量的詳盡，讓人直觀的能瞭解到你對這個業務的總體設計、分層、封裝等。技術方案是在不斷完善的，所以開發的同時，也儘量的去同步更新你的詳細技術方案，以便於在代碼檢視的時候去爲同事講述。我的認爲前端的技術方案設計應該包含如下幾點：

1. 需求簡述：
   簡單描述需求的背景、價值以及前端的開發需求；
2. 需求涉及的項目，是否須要啓動新項目，或者項目拆分等；
3. 總體的業務流程圖；
4. 總體的技術方案：
   路由規劃、全局組件、模塊通用組件、通用方法、通用hook等，重點描述下複雜的組件和方法的設計；
5. 風險評估以及回退方案；
6. 測試注意點；
7. 其餘；

開發

開發中一些經驗之談：

1. 不着急寫代碼，先充分解讀需求和ui，在腦子裏有個大體的圖；
2. 總覽全部ui，提取通用部分，將組件或者方法設計的更具備通用性；
3. 根據路由規劃設計總體的目錄結構，或者先構建目錄結構再設計你的路由規劃，作好結構的分層；
4. 涉及到接口返回的枚舉變量，儘可能把使用到的枚舉定義成有意義的變量或者map再使用；
5. 高階容器組件儘量封裝完善；
6. 開發評估時間時，儘量給予對產品需求的必定理解，瞭解其複雜度，做者以前在一個項目上就犯了這個錯誤，只是簡單過了一遍ui去預估了工時，當詳細瞭解他的需求時才發現需求複雜程度之高遠非看到的ui那麼簡單，致使時間預估太少，只能本身拼命加班趕工，所以面對稍微較大的需求時，嚴謹認真；

目錄結構

項目開發的目錄結構相當重要，我的習慣喜歡將目錄跟路由掛鉤，目錄結構直觀能看出路由規劃，所以在開發前，我的會先根據ui設計建立頁面的總體目錄結構，根據總體結構來設計路由。

枚舉配置

項目中時常會有許多枚舉變量，例如狀態、類型等，我的建議將這些狀態定義成有意義的枚舉變量再進行使用，不要直接拿來用，防止過段時間回過頭來看代碼時，一臉茫然，在定義枚舉時，建議簡單枚舉平鋪定義，針對一個類型枚舉過多的狀況可使用map，例如：

const TYPE_ENUMS_MAP = {
  going: 1,
  willBegin: 2,
  finished: 3,
  ...
};

// 少許時，平鋪定義;
const WORK_HAS_FINISHED = 1;
複製代碼

組件拆分

當下前端開發開發，一般都會使用vue、react，使用組件化的開發方式，我的建議合理把握組件拆封的顆粒度，不用過小，也不能太大，過小可能致使傳參的層級過多，太大可能致使單個組件或者頁面內容太多，不利於維護或者複用，合理把握顆粒度，合理規劃目錄，遇到模塊內幾個頁面通用的組件提取爲模塊組件，遇到可能全局都會用到的組件提取爲全局組件，頁面私有的組件放在頁面目錄下，設爲普通頁面組件，合理的顆粒度劃分，合理的存放結構有助於你代碼的合理複用和維護。

mock開發

mock開發是高效聯調的必要條件，後端接口未徹底開發完成前，咱們能夠利用mock平臺先使用mock接口調試代碼，我的推薦公司部署yapi平臺。此前，須要先後端先定義和約定好接口入參和反參的結構，這一步很重要，必定要在開發前提早讓後端同窗錄入接口並check接口的可用性和合理性，再投入開發，開發時，爲了不接口路徑的替換，咱們一般會給腳手架提供mock環境，mock環境下接口走mock代理到mock平臺（yapi），這裏有兩種方法來區分路徑：

1. 經過環境變量來區分接口路徑：

const serviceConf = {
   url: '/user/getUserInfo',
   mockUrl: 'http://mock.yapi.com/10/user/getUserInfo',
};

2. 經過代理的方式：
配置接口代理(以yapi爲例，yapi的接口規則, https://yapi.dev.com/{項目編號}/{接口相對路徑})：
mock.conf.js:
module.exports = {
  100: [
    '/user/getUserInfo',
  ]
}
配置完代理配置，再動態的讀取代理配置，生成接口代理傳入腳手架的proxy中。該方法的好處是不會將調試的
mock代碼打入最後的包中，相比於第一種方式更合理。

此外，爲了能動態響應配置的變動，咱們可使用nodeMon來監聽咱們的配置並動態的重啓項目；
nodemon --watch mockProxy.conf.js --exec .....
複製代碼