前言
哈哈，十一最后一天送上一篇鸡汤，也是本年最后一篇与技术无关的博客了，各位看官请对照下菜。
发现
每天沉浸在业务代码中不能自拔的你，是否有的时候会越做越迷茫，不知道在哪里提升自己。
每天重复着 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，简直就是地狱模式，开发全靠运气。后台一挂，前端两眼一黑干瞪眼。
对于混吃等死的前端来说，又是一件不能忍受的事情，于是写了一个代理插件
时间太久远，具体的代码已经遗失，简单说明一下思路
具体思路步骤：
- 前端工程开发环境请求走代理插件
- 代理插件将请求所有信息都转发到后端服务器
- 在后端服务返回信息的时候，根据接口 url 与参数作为唯一标识，存在则更新本地数据，否则保存在本地
- 当服务器正常请求返回的时候，直接将信息返回给前端展示
- 当服务器宕机的时候，代理接口返回 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 的代表。
自定义表单开发也有很多博文介绍，这里就不具体展开了，只谈谈思路。
在你摸透业务模型之后，可以结合当前的业务规则，去开发一套逻辑模板，通过一定的规则来渲染出不同的表单，后期每个新业务接手的时候，可以通过这样类似的插件或者其他工具快速生成你需要的表单页面以及类似的页面，岂不美哉。
上述列举了一些鸡肋的问题，仅仅提供一个小思路，在你日常开发中是否也会遇到这种很麻烦但又简单的问题，有没有考虑过使用封装工具的方法来提高你的效率呢？
沉溺于业务代码无法自拔的同时，要抽身出来做一些小工具，慢慢的将自身的效率提升上去，形成良性循环。
善于发现你工作的小细节，不积跬步，无以至千里；不积小流，无以成江海，当你把细节处理好了，整体才会上升。
二段突破
敢于承担责任
这里所说的责任，不仅仅是犯错之后的承担，而是贯穿你负责的整个项目过程的。
在座的各位必然有划水摸鱼的时候，但是在开发自己的项目中，不仅仅只是为了完成任务而做，间歇性但又要持续性的保持对项目的怀疑、否定想法，优化提高自己的项目
- 项目是否按时完成预期的目标
- 当前项目是否具有足够的拓展性以支持下一轮的业务迭代
- 项目本身的代码质量是否符合预期
- 当前项目能否有公共的模块或者方法可以提取出去，供给其他项目使用
- 当前项目是否有足够的容错、及时的线上错误反馈机制
- 生产环境的性能、安全性是否满足
- 等等………………你能够想到对此项目有关的一切细节
做完上述，你就可以安心划水了，划个痛快
持续关注新技术
前端的技术革新日新月异，时刻保持对业务新技术的关注，也是对你未来项目的一种减负
当接手新的项目的时候，你需要做结合团队与业务的实际情况，做一个综合的考虑，简单举一个例子：
多端开发小程序跟 h5 的时候，你会有很多种选择，比如 Uniapp、Taro、Remax、Chameleon 等等各种各样的选择。
你团队技术是以 vue 还是 react 为主，业务主要集中在支付宝还是微信小程序，后期是否需要自身 app 接入小程序的能力等等各种各样的原因会导致你选择的多端框架不同。
但是只有你的视野够广，对团队、业务理解够深的情况下，才能选择一个符合当前页面的最优技术。
whatever，持续关注新技术肯定没错
写在最后
由于九月份出现各种情况，这是今年最后一篇与技术无关的鸡汤博客，后续会继续之前的系列。
适当鸡汤，利于下饭
欢迎各位同学转载，文末或者文章内部标注来源即可。
