总结的点都杂七杂八，但愿能找到对你有所帮助的，没有的也没关系嘛！😄

1. vue强制渲染某个组件

$forceupdate 使 Vue 实例重新渲染。注意它仅仅影响实例本身和插入插槽内容的子组件，而不是所有子组件。

由于某些场景 $forceupdate 不起作用，所以用下面的hack方法。一般来说，这种强制渲染某个组件的情况不多，在组件内部应该处理好内部的渲染。
这个例子还是因为使用某个库后发现了一个bug，后面才想到以下hack方法的。

<my-comp v-if="show"></my-comp>
<script>
data() {
    return {
        show: true
    }
},
methods: {
    reRender() {
        this.show = false
        this.$nextTick(() => {
            this.show = true
        })
    }
}
</script>

• 必须用v-if，v-show不行
• 在$nextTick回调中重新赋值，否则vue会忽略show的第一次赋值

2. vue里的ref和v-for一起使用时，得到的引用将会是一个包含了对应数据源的这些子组件的数组

当 ref 和 v-for 一起使用的时候，你得到的引用将会是一个包含了对应数据源的这些子组件的数组。

<div v-for="item in list" :ref="item.code" @click="handleClick(item.code)">{{item.title}}</div>

handleClick(code) {
   ~~let dom = this.$refs
~~ // 错误的写法
 let dom = this.$refs
[0]
 }
  vue的一些api在特殊情况下会出现不一致的情况，这点比较蛋疼，需要对文档比较熟悉。
3. Gitlab不仅仅可以作为代码仓库，还可以作为项目管理工具，通过标签，里程碑，提交历史，代码审核流程等。
以后在公司里，如果做项目管理或者code review都可以用gitlab来做。
4. css 背景图片background-size的几种适用范围
css 背景图片background-size的几种适用范围
5. 作为TL，安排工作计划，协调各种资源也是需要花费时间的，这些时间需要考虑在内，必然会减少编写代码的时间。这一点要清楚。
6. 怎么评估工期
需求非常明确而且经常这样做：自己评估时间 * 1.5
需求不够清晰，有可能变，但是代码和技术方案熟悉：自己评估的时间 * 2
需求不够清晰，代码和技术方案也是新的，需要探索：自己评估的时间 * 2.5 or 3
 自己评估的时间一般会留点 buffer，自我感觉应该没问题，
 实际上开发过程可能会有各种会议、需求和技术方案变更或者突发事件。所以多留一点 buffer 会更好，因为这个时间点可能是下游运营活动上线时间点，评估后业务方觉得太长可以砍需求拆成两期或者调整上线预期，但一旦设置了时间点，不应该跳票。如果你比预期早完成上线，皆大欢喜，如果你一次次的告知业务方还需要延期一两天，效果正好相反。
7. 无缝滚动组件
无缝滚动组件
8. 前端的工作要紧密结合产品和ui，整个前端展现出来的效果是三者相互合作创造出来的，而不是某一方。前端的一部分价值不仅仅体现在写代码上面，还体现在和ui，产品共同创造好的界面和交互效果。
9. 软件具有熵增的特性（体系总是自发地像混乱度增大的方向变化），长期维护的项目总会遇到可维护性逐渐降低的问题。
10. 代码风格统一工具
使用 editorconfig 协助兼容开发工具的代码格式化。
使用 eslint 检查代码。
使用 prettier 格式化代码。（可以理解为prettier是 eslint —fix 的加强版，用 prettier 来代替 eslint-fix）
手动修改剩下的有问题的地方，或者有些地方很难用规则来判断的时候，就需要手动修改。
11. 使用husky和prettier统一代码风格
npm install --save-dev prettier pretty-quick husky
package.json里配置
"husky": {
    "hooks": {
        "pre-commit": "pretty-quick --staged"
    }
},
需要注意的事，安装包之后，package-lock.json也需要提交commit，否则hooks不会执行（不知道为什么）!
12. 使用.editorconfig，一定要用indent_style = space，如果用tab，不管怎么设置编辑器，tab都为4
13. 提高团队代码质量的想法
code review 要更加仔细，保证每个人的代码质量，哪怕进度慢一点（同时，自己写代码的时间减少了，但是这样是值得的，如果只是自己写代码，只能保证自己的代码，但是code review能帮大家的代码都提高，团队共同提高的效益肯定比自己一个人要大）
在code review 发现的问题，在会议上提出来，让大家商量解决办法，同时避免以后出现相同的问题，这样大家的代码质量都能提高
目前的问题：
大家会写大量重复的代码，不管是js还是css，碰到两处以上会调用的代码，应该要封装起来
变量命名不按照规范，并且不注意语义化。代码不仅仅是写给计算机执行的，同时是写给人看的，最要命的是给别人看。好的代码，一看变量，就大概知道这个变量是干嘛的，或者方法是干什么的，而不好的变量命名只会让程序出现歧义
写代码不注意代码量，一写千里，一个单文件组件能写到2000行，方法的行数也要注意。这里建议：单文件组件行数不大于1000，超出应该要拆分出来；方法行数不能超出100行，超出拆分
多个if else 应该用switch，看起来更舒服，逻辑更清晰
拼接字符串尽量用模版字符串语法
不要使用 var 定义变量（用eslint控制）
data 方法里不要的变量定义尽量精简；如果是模板里没有使用，不需要在data里定义，可以直接挂在vue实例上，或者写一个局部变量代替
学会使用计算属性，ex:
data() {
    return {
        arr: [
            {status: true, foo: 1},
            {status: false, foo: 2}
        ]
    }
}
computed {
    // 用计算属性代替，而不是每次手动计算一次
    activeArr() {
        return this.arr.filter(i => i.status)
    }
}
Prefer early exit
// bad
function someFunction(someCondition) {
  if (someCondition) {
    // Do Something
  }
}

// good 逻辑更清晰，避免过度else if
function someFunction(someCondition) {
  if (!someCondition) {
      return;
  }
  // Do Something
}
14. 精读《为什么专家不再关心技术细节》
技术细节学习难度不大，在需要深入的时候再深入了解最佳。
想要做成事，需要更宏观的技术思维，所以专家渐渐变得眼光宽阔，格局很大。
专家拥有快速学习技术细节的能力，只是这已不是其核心竞争力，所以与其写技术细节的文章，比如写方法论的思考带来的价值更大。
指引方向比走路更重要，专家都要逐渐成为引路人。
技术最终为业务服务，懂技术细节和让业务先赢没有必然的关系，所以在深入技术细节之前，要先理解业务，把握方向，防止技术细节出现路线问题。
15. rgba转16进制函数
function hexify(color) {
  var values = color
    .replace(/rgba?\(/, '')
    .replace(/\)/, '')
    .replace(/[\s+]/g, '')
    .split(',');
  var a = parseFloat(values[3] || 1),
      r = Math.floor(a * parseInt(values[0]) + (1 - a) * 255),
      g = Math.floor(a * parseInt(values[1]) + (1 - a) * 255),
      b = Math.floor(a * parseInt(values[2]) + (1 - a) * 255);
  return "#" +
    ("0" + r.toString(16)).slice(-2) +
    ("0" + g.toString(16)).slice(-2) +
    ("0" + b.toString(16)).slice(-2);
}

var myHex = hexify('rgba(255,232,186,0.4)'); // "#f5faf3"
16. material-design-icons-iconfont 包和 eslint 包有冲突，安装了eslint后 material-design-icons-iconfont 就被删除了，需要重新安装一次。
17. eslint 检查.vue文件
安装eslint-plugin-vue
在.eslintrc.js里加上plugin
在lint里加上 --ext .js,.vue
plugins: [
    'vue'
]
eslint ./src --fix --ext .js,.vue
18. vue-cli3 创建的项目，将static文件夹移除了，静态文件可以放到public文件夹，可以直接用localhost:8080/xxx.json访问
19. 用ts的时候也不是说所有的变量都要加类型限制，只需要在自定义的变量，多方调用的地方加，而第三方的类型，如果有类型声明可以加，不加影响也不大。
20. $emit 加自定义参数
$emit 加自定义参数
21. renderless component
renderless component 
探索Vue高阶组件
22. eslint 检查以下代码报错解决方法
{ path: '/login', name: 'Login', component: () => import('@/views/login/Login'), hidden: false }
解决方法，在.eslintrc.js里添加以下代码，并安装该插件
parserOptions: {
    parser: "babel-eslint"
}

npm install babel-eslint --save-dev
23. iview里validate找不到该属性的ts报错解决办法
import {Form} from 'iview'
// iview 里有比较全的 ts 类型定义，可以用起来
type IForm = Form

(this.$refs.form as IForm).validate((valid: boolean | undefined): void => {
  if (valid) {
    this.$Message.success('Success!');
    const resp = login({username: '', password: ''})
  }
})
stackoverflow参考
24. pont-engine 配合 swagger
pont-engine
25. npm安装包的时候如果指定包的依赖版本使用~而不使用^?
链接
npm install xx -E
26. this.$refs.xxx.$el TS报错的问题
this.$refs.xxx as Vue).$el