面对重复的代码、逻辑，如何提高短视频开发效率

在短视频开发迭代过程中，很多重复的代码、逻辑让开发者很苦恼，所以在这种情况下如何才能提高短视频开发效率，从重复中解放出来呢？下面列出了一些问题、思考以及解决方案，希望对大家有所帮助。

vscode中使用@没有路径提示

在短视频开发中，为了方便，我们经常会在webpack中配置@指向项目的src目录，但是vscode的路径提示并不认识@，导致写引入路径时没有提示，纯手敲。

解决方案：

下载vscode插件Path Intellisense，并且在vscode setting文件中如下配置即可：

引入公共组件的代码很繁琐

公共组件每次使用的时候，都需要写引入的代码：
import Material from ‘@/components/common/Material’
解决方案：
把公共组件注册成全局组件，就可以节省短视频开发引入组件的工作量。

// 注册全局公共组件
let context = require.context('@/components/common/', true, /\.vue$/)
context.keys().map(key => {
  const component = context(key).default
  Vue.component(component.name, component)
})

这里用到了require.context，根据公共组件目录来引入所有的公共组件

使用公共组件的代码很繁琐

我们使用一个组件时，它的组件名、传参、自定义事件等都需要手敲，如下：

<Material
title="议题材料"
:materials.sync="material"
:annotation.sync="annotation"
:vAuth="() => 35"
/>

解决方案：

公共组件的代码中，维护一个组件使用demo，以供使用时快速复制。以前的短视频开发工作量减少到了只需要复制、修改绑定值即可。强烈建议在团队中执行。

维护一个公共组件的文档、示例页

提供了以下功能：

1. 维护组件的出参、入参、方法。当然在短视频开发中维护这些信息需要很大的精力，而且这些信息很容易落后于代码。
2. 但我创建组件文档页的主要目的，是为了让开发者了解到，短视频开发有哪些已经封装的组件，并且很直观的看到它是什么样子并且实现了什么功能。避免因为不了解，而重复开发或者造轮子，让公共组件发挥更大的价值。
3. 提供demo代码的复制功能，快捷引入组件，减少短视频开发使用组件的工作量
4. 没有使用vuepress等框架：
   （1）为了把文档页整合进短视频开发中，而不是一个单独的项目，这样维护、浏览时很方便
   （2）对比与框架，这样开发便捷，自定义不受限制

有一些代码片段，出现的很频繁
短视频开发中，会发现一段js逻辑、html，在某种场景下，出现的很频繁，但他们其实已经很简洁，又不需要再去二次封装，所以我们可以使用vscode的snippets来帮助我们节省工作量。
但vscode原生的snippets的使用体验非常不好：

我们需要把代码根据逗号按行分隔开作为输入，不仅工作量很大，而且代码这样处理后已经无法直观的对短视频开发进度进行理解理解。

根据经验，你能发现的问题，一般情况下早已有了解决方案：所以我发现了一个宝藏插件：snippets

它可以很快捷方便的新建、编辑、插入代码片段。具体使用我就不再赘述，大家可以尝试下。

使用它我维护了多个常用的代码片段，让我的短视频开发效率提高了很多很多：

vue自定义组件模板

<template> 

</template>
<script>
export default {
  props: {
    abc: {
      type: Object,
      default: () => {}
    }
  },
  data() {
    return {
      abc: {}
    }
  },
  methods: {
    abc() {}
  }
}
</script>
<style lang="scss" scoped>

</style>

获取数据的api请求

abc()
    .then(res => {
      this.abc = res.data.list || []
    })
    .catch(err => {
      console.error('请求失败：' + err.message)
    })

用户操作后的api请求

包含短视频开发中操作的成功、错误提示

abc({
  abc: this.abc,
})
  .then(() => {
    this.$message({
      type: 'success',
      message: '操作成功'
    })
  })
  .catch(err => {
      this.failDialog(this, err)
  })

需要二次确认的api请求

包含短视频开发中二次确认弹窗和成功、失败提示

this.$confirm(`确定删除abc吗？`, '提示', {
    confirmButtonText: '确定',
    cancelButtonText: '取消'
})
  .then(() => {
    this.getData()
    this.$message({
      type: 'success',
      message: '操作成功'
    })
  })
  .catch(err => {
      this.failDialog(this, err)
  })

el-form表单验证

this.$refs.form.validate(valid => {
    if (!valid) {
      return
    }
})

$message

this.$message({
  type: 'warning',
  type: 'success',
  type: 'error',
  message: 'abc!'
})

el-form 校验规则

abc: [{
    validator(rule, value, callback) {
      if (!value) {
        callback(new Error('不能为空'))
      }
      callback()
    },
    trigger: 'change'
}],
abc: [{
    required: true,
    message: '不能为空',
    trigger: 'change'
}],

表格页模板

• html：搜索栏、表格、分页；
• js：获取数据逻辑、分页逻辑

并没有把公共组件封装成第三方库

如果把它们封装成第三方库，供多个项目公用

• 必须考虑足够全面，能够覆盖短视频开发各种细节、场景，但其实计划赶不上变化，尤其是业务组件；
• 必然会涉及到短视频开发库的多版本维护问题以及成本，增加了其他的工作量。
• 同时这些组件局限于我们当前的短视频开发，并没有很好地普适性去做开源、扩散，那封装成库的优势就很小了

所以我只是把它们维护在我们的短视频开发模板中，所有的新项目都会有这些公共逻辑能力，由于每个项目单独维护，维护成本也会很低。
过度封装的后果，就是随着时间的推移，短视频开发代码变得不可维护。很多时候就是需要在封装和可维护之间寻求平衡。