一些提升開發效率的小體會

最近在工做中遇到了比較緊急的項目，短期以及不能再刪減（甚至還可能會變）的需求就意味着要儘量地提高開發效率。前端由於與交互相關，所以會受到大部分需求變動的影響。如何儘量地減小因需求變動而產生的工做量，一直以來都困擾着前端開發人員。

因爲本身平時的代碼風格還不夠規範以及知識領悟不深，天然我也沒少受苦，但也所以對提升開發效率方面有了一些體會。本文即是總結與覆盤，用於往後提醒本身。

如何提升效率

對於咱們作開發的同窗來講，提升工做效率最有效的方法就是下降 BUG 率；而下降 BUG 率最有效的方法就是減小代碼量。還記得 GitHub 上以前大火的項目 No Code 嗎？資深的谷歌工程師告訴咱們，一行代碼都沒有的程序是最安全的穩定的。

其次若是代碼拓展性足夠強，那麼在面對需求變動時的工做量就會相對減小（做爲前端，不變動時不存在的）。而加強代碼拓展性比較經常使用的方法就是通用組件的封裝與抽象。

下面就是有關於這兩部分的一些總結和思考。

下降 BUG 的方法

良好的代碼風格應該是下降 BUG 最有效的方法，能夠參考《代碼整潔之道》一書。下面的一些方法是我在平時工做中所總結出來的幾點。

1. 減小代碼量

代碼量越少也就越難出現 BUG。在平時的工做中，應該儘量地減小編寫的代碼量。在前端中，最簡單的就是儘可能使用 ES6 語法。相比 ES5，經過 ES6 的解構、箭頭函數、async/await 能夠減小 30% 以上的代碼量。在有大量（3 個以上）的 if 判斷時，可使用對象的形式。

// 常規賦值操做
let a = 1
let b = 2
let c = 3
// 使用解構賦值
let [a,b,c] = [1,2,3]

// 使用 if
if(a === '1'){
  ....
}else if(a === '2'){
  ...
}else if(a === '3'){
  ....
}
...

// 使用對象進行分類處理， 邏輯上會更簡潔一點
// PS：這個方法在 React 進行組件渲染的時候很是有用
const handleAction = (act) => {
  const actions = {
    '1': action1,
    '2': action2,
    '3': action3
  }
  const action = actions[act]
  action()
}
// 根據狀況進行處理
handleAction('1')
複製代碼

在 React 的項目中，若是使用了 Redux。那麼應該儘量地使用 function 組件來減小代碼。同時這麼作也可讓咱們在進行 UI 移植的時候省下不少改動（最近有一個項目是部分功能的遷移，Redux -> dva 在移植 function 組件時幾乎沒有什麼改動），並且如今有了 Hook，function 組件中不能控制 state 的問題也能解決。

2. 設定默認值

缺乏默認值很是容易形成 BUG，這是以前一個項目中血和淚的教訓。特別是 React 項目中使用了上面介紹的對象的方法進行組件切換時，若是沒有設置默認值就會直接形成頁面崩潰。

class A extends React.Component {
  const Components = {
    // 特別是根據 Response 來進行組件切換時，應該設置 default 防止意外狀況
    A: Component1,
    B: Component2,
    C: Component3,
    'default': () => <div />
  }

  render(){
    const {render} = this.state
    // 若是沒有默認值，一旦對象匹配不到，頁面直接崩潰
    const RenderComponent = Components[render] || Components.default
    return (
      <RenderComponent /> ) } } 複製代碼

其次函數參數的默認值除了能減小 BUG 外也能幫助減小代碼量。對於使用次數較多的方法，直接設置默認值可讓咱們在調用時省去參數的傳入。

// 當 0.0.0.1 和 api service 方法較多時，設爲默認參數能夠減小參數的傳入
function customizeFetch(service='api', base = '0.0.0.1'){
  ...
}

customizeFetch()
複製代碼

3. 拆分函數與抽象方法

說到拆分函數，用的最多的應該是 request 的應用部分。好比對 fetch 的封裝。

// 封裝好的 fetch (有柯里化的影子在)
function customizeFetch(server = "api", base = "0.0.0.1") {
  return function(api = "", options = {}, withAuth = false) {
    const url = `${base}/${server}/${api}`;
    const opts = {
      method: options.method || "POST",
      headers: {
        // 能夠設置默認參數，好比頭什麼的
        ...options.headers
      },
      body: {
        ...options.body
      }
    };

    return fetch(url, opts).then(response => response.json());
  };
}

// 當咱們進行調用時，對於業務來講寫起來基本一致
// 因爲使用透傳，其實在 service 還能偷懶寫成一個方法
// 產品列表
const fetchAPI = customizeFetch("api1");
const getProductList = opts => {
  const options = {
    body: { ...opts }
  };
  return fetchAPI("getProductList", options);
};

// 新聞列表
const fetchAPI = customizeFetch("api2);
const getNewsList = opts => {
  const options = {
    body: { ...opts }
  };
  return fetchAPI("getNewsList", options);
};
複製代碼

4. 強類型和強檢查

eslint 的好處就不用提了吧？再配合 prettier 可讓代碼格式統一（umi 的 lint 雖然在不習慣時會以爲很煩，可是一旦習慣後對代碼風格的提高仍是頗有幫助的）。若是再用上 TypeScript 更是可讓咱們在編碼時檢查到錯誤。TypeScript 雖然在剛開始使用時很不習慣，特別是對於類型的強要求（所有 any 的話等於沒有類型）很頭痛。不過適應以後就能體會到 TypeScript 帶來的快感了。

在引入 TypeScirpt 以後，最容易出現的 xxx from undefined 錯誤就能徹底避免。能夠幫助咱們節省下許多調試的時間。

應對需求變動

前端的組件化開發，在更多的程度上是爲了應對需求的變動（我的認爲）。而因爲前端是最接近用戶的，所以只要需求有變是逃不過要進行一番修改的。所以讓修改的工做量減小以及減小因修改帶來的 BUG，也是提升效率的方法。

1. 提高反作用，儘可能使用 Stateless 組件

對於 React/Vue 項目，只要使用了 Redux/Vuex 這類狀態管理工具，咱們就能很容易地把組件作成不依賴於 state 的 stateless 組件。這類組件很「純」基本只依賴於傳入的 props，即使有 state 也是屬於自治範圍，不會參與業務邏輯計算。這麼一來就能儘量地讓 UI 層更加純淨，職責更單一。（固然這只是一種美好的願望，實際上根據反作用切換組件狀態或者其餘業務邏輯操做仍是會讓業務邏輯下沉到 UI 層去）

讓 UI 層儘量地變得簡單，而處理業務邏輯的部分就應該轉移到 Redux 的 action 的部分中。Reducer 的部分也應該儘可能純淨，不作業務處理。這樣若是當需求有變化的時候，修改的部分就能儘量地被縮小在 action 部分，同時在作項目移植時也會比較方便（基本 action 層很大可能會重寫）。固然實際中並不可能剝離得很是乾淨，UI 層每每也會跟着一塊兒變更，不過仍是能夠減小修改的範圍。

2. 通用業務組件的封裝與抽象

另外一個就是根據項目需求提煉出通用的業務組件，好比短信驗證碼、可編輯 label 的表單控件、權限驗證組件、搜索組件等。這類組件基本與業務相關，基本是某個組件庫的再封裝（好比 antd），這個也是如今許多同窗平時會作的。這樣在某一個業務中能夠減小咱們的開發量。具體的可使用 HOC 等方法來進行封裝和抽象（好比權限驗證組件）。

提煉組件當然不錯，可是也要避免過分封裝。曾經在寫 Vue 的時候封裝了一個可配置的表單組件，結果當業務須要兩個表單控件的互相控制以及按鈕狀態控制時就傻眼了。所以在設計封裝組件時也要考慮到以後業務的變化。

以上即是最近這段時間的一些工做感悟，算是做爲本身的一個備忘。編程本來的目的就是提升作事的效率，而提升開發的效率又是每個程序員都要面臨的難題。因此編程是一件十分有意思的事情，其中一點就是能夠不斷地挑戰和提高本身。