前端之路：平凡中的小事 🏆 掘金技術徵文|雙節特別篇

前言

哈哈，十一最後一天送上一篇雞湯，也是本年最後一篇與技術無關的博客了，各位看官請對照下菜。

發現

天天沉浸在業務代碼中不能自拔的你，是否有的時候會越作越迷茫，不知道在哪裏提高本身。

天天重複着 curd，雷同的代碼，枯燥而無味，朝九晚九，披星戴月，失去了編程的樂趣。

下面列舉幾個雞肋問題給各位看官做一點下酒菜，各自全部需哈。

小程序路由改造

我最開始寫小程序路由的時候，難用的一批，要全路徑 + 拼接參數什麼的，難用的一匹有沒有

wtf，做爲混吃等死的落魄前端，多寫一行重複代碼感受就是浪費生命，恰好這個小程序項目用到了 gulp，直接上手開始改造

function fileDisplay(filePath) {
  // 根據文件路徑讀取文件，返回文件列表
  try {
    console.log(filePath);
    const pa = fs.readdirSync(filePath);
    pa.forEach((ele, index) => {
      let relPath = `${filePath}/${ele}`;
      const info = fs.statSync(relPath);
      if (info.isDirectory()) {
        fileDisplay(relPath);
      } else if (relPath.indexOf('index.json') > -1) {
        const cObj = require(relPath);
        if (!cObj.component) {
          relPath = relPath.replace('.json', '');
          relPath = relPath.replace(`${currentPath}/`, '');
          pages.push(relPath);
          if (cObj.name && !pagesObject[cObj.name]) {
            pagesObject[cObj.name] = relPath;
          } else {
            const relPathList = relPath.split('/');
            pagesObject[relPathList[relPathList.length - 2]] = relPath;
          }
        }
      }
    });
  } catch (err) {
    console.log(err);
  }
}

// 生成的文件路由 map
export default {
  home: 'pages/home/index',
  authorization: 'pages/authorization/index',
  guide: 'pages/guide/index',
  map: 'pages/train-schedule/map/index',
  confirm: 'pages/ordering-meals/order/confirm/index',
  detail: 'pages/ordering-meals/order/detail/index',
  list: 'pages/ordering-meals/order/list/index',
};
複製代碼

上述方法在 gulp 監聽文件修改的時候觸發，會自動生成如上所示的路由配置，主要是經過 json 配置參數來判斷是不是頁面，再結合下面的路由改造，便可使用別名跳轉路由。

// 封裝路由
import routerMap from '../constant/router.config';
import qs from 'qs';

const tranfor = (params) => {
  if (params) return `?${qs.stringify(params)}`
  return ''
};

const push = (url, params = {}) => {
  let rUrl = '';
  if (url.substr(0, 1) === '/') {
    rUrl = url.slice(1, url.length);
  } else {
    rUrl = routerMap[url];
  }
  wx.navigateTo({
    url: `/${rUrl}${tranfor(params)}`,
  });
};

export default {
  push,
};
複製代碼

// 使用路由
import router from '@/utils/route'; 

router.push('shop', {data:1});
複製代碼

如上，小小的改造讓你在使用原生小程序開發中避免了路由書寫的麻煩，其實過程跟方法都很是 easy，並且在如今多端框架流行的狀況下，寫原生小程序已經愈來愈少了。

請求接口本地緩存

以前的公司有遇到過因爲運維不成熟或者開發在頻繁修改問題部署，致使測試環境是否是就處於宕機的狀態，同時又沒有 mock 接口，也沒有開發文檔，不要太酸爽

wtf，簡直就是地獄模式，開發全靠運氣。後臺一掛，前端兩眼一黑乾瞪眼。

對於混吃等死的前端來講，又是一件不能忍受的事情，因而寫了一個代理插件

時間過久遠，具體的代碼已經遺失，簡單說明一下思路

具體思路步驟：

1. 前端工程開發環境請求走代理插件
2. 代理插件將請求全部信息都轉發到後端服務器
3. 在後端服務返回信息的時候，根據接口 url 與參數做爲惟一標識，存在則更新本地數據，不然保存在本地
4. 當服務器正常請求返回的時候，直接將信息返回給前端展現
5. 當服務器宕機的時候，代理接口返回 404 或者其餘錯誤碼，直接將本地的數據返回給前端，同時返回參數添加 mock 標記，表示服務器出現問題，走的時候本地緩存

這樣就能正常愉快的開發了，而且在開發過程當中宕機或者頻繁發佈都不會過於影響本地開發環境的調試。

大型項目熱更新速度太慢

沒錯，又是我接手的一個很是大的後臺項目，好幾百個頁面，每次改動一次熱更新的速度大約是在 3 - 5mins 左右。

wtf，雖然是一個很好的摸魚項目，也只是我臨時過渡的一個項目，又不能所有項目重構一遍。

開玩笑，所有重構怎麼配得上個人混吃等死的稱號

果斷查資料，最後上了 babel-plugin-dynamic-import-node 插件。

"babel": {
"env": {
  "development": {
    "plugins": [
      "dynamic-import-node"
    ]
  }
},
"presets": [
  "react-app"
],
"plugins": [
  [
    "import",
    {
      "libraryName": "antd",
      "libraryDirectory": "es",
      "style": "css"
    }
  ],
  "transform-decorators-legacy"
]
},
複製代碼

經過按需加載將熱更新速度提升到 3s 左右，穩得一匹。

自定義表單

重複性的後臺表單類型頁面開發，簡直就是 curd 的表明。

自定義表單開發也有不少博文介紹，這裏就不具體展開了，只談談思路。

在你摸透業務模型以後，能夠結合當前的業務規則，去開發一套邏輯模板，經過必定的規則來渲染出不一樣的表單，後期每一個新業務接手的時候，能夠經過這樣相似的插件或者其餘工具快速生成你須要的表單頁面以及相似的頁面，豈不美哉。

上述列舉了一些雞肋的問題，僅僅提供一個小思路，在你平常開發中是否也會遇到這種很麻煩但又簡單的問題，有沒有考慮過使用封裝工具的方法來提升你的效率呢？

沉溺於業務代碼沒法自拔的同時，要抽身出來作一些小工具，慢慢的將自身的效率提高上去，造成良性循環。

善於發現你工做的小細節，不積跬步，無以致千里；不積小流，無以成江海，當你把細節處理好了，總體纔會上升。

二段突破

勇於承擔責任

這裏所說的責任，不只僅是犯錯以後的承擔，而是貫穿你負責的整個項目過程的。

在座的各位必然有划水摸魚的時候，可是在開發本身的項目中，不只僅只是爲了完成任務而作，間歇性但又要持續性的保持對項目的懷疑、否認想法，優化提升本身的項目

1. 項目是否按時完成預期的目標
2. 當前項目是否具備足夠的拓展性以支持下一輪的業務迭代
3. 項目自己的代碼質量是否符合預期
4. 當前項目可否有公共的模塊或者方法能夠提取出去，供給其餘項目使用
5. 當前項目是否有足夠的容錯、及時的線上錯誤反饋機制
6. 生產環境的性能、安全性是否知足
7. 等等………………你可以想到對此項目有關的一切細節

作完上述，你就能夠安心划水了，劃個痛快

持續關注新技術

前端的技術革新突飛猛進，時刻保持對業務新技術的關注，也是對你將來項目的一種減負

當接手新的項目的時候，你須要作結合團隊與業務的實際狀況，作一個綜合的考慮，簡單舉一個例子：

多端開發小程序跟 h5 的時候，你會有不少種選擇，好比 Uniapp、Taro、Remax、Chameleon 等等各類各樣的選擇。

你團隊技術是以 vue 仍是 react 爲主，業務主要集中在支付寶仍是微信小程序，後期是否須要自身 app 接入小程序的能力等等各類各樣的緣由會致使你選擇的多端框架不一樣。

可是隻有你的視野夠廣，對團隊、業務理解夠深的狀況下，才能選擇一個符合當前頁面的最優技術。

whatever，持續關注新技術確定沒錯

寫在最後

因爲九月份出現各類狀況，這是今年最後一篇與技術無關的雞湯博客，後續會繼續以前的系列。

適當雞湯，利於下飯

歡迎各位同窗轉載，文末或者文章內部標註來源便可。

🏆 掘金技術徵文|雙節特別篇