编程道拓扑bcd.top 0x01/ 开局第一篇： 随便聊聊/ 随笔

Posted 2020-11-22 fepapa

0x01 开局

编程道拓扑（bcd.top）是一个前端从业者的思考和总结， 如果你喜欢， 欢迎关注！

作者是一个前端从业者， 本系列会总结作者在工作和学习中的一些思考， 会有具体的技术点， 也会有关于编程的一些鸡汤思考。 开局第一篇， 先来点思考！

编程道核心是什么

笔者观点： 复用世界， 但是不要复制自己

我现在的观点是， 编程就是复用， 复用别人的工作， 复用别人的经验，当然， 请不要简单的理解成 粘贴复制， 粘贴复制在笔者或者大部分的从业者看来应该都是没有什么技术含量的， 笔者这里的观点是， 要站在巨人的肩膀上。

复用这个世界
? ? 别人造好的轮子， 就要用起来，特别是流行的轮子， 比如说 lodash , rxjs 这种在github上start很多的轮子，把他们用在工作中， 事半功倍。当然， 肯定会有读者认为造轮子的才是大神， 用轮子的都是平庸之辈。您的观点前半段是对的， 造轮子的确实是大神， 但是用轮子的不一定是平庸之辈， 这些轮子使用者可以把大神的轮子用在自己的工作中， 迅速解决需求， 满足公司的业务， 这是很值得肯定的， 至少公司肯定了。况且如果没有众多的轮子使用者， 谁来称托造轮子的是大神呢。

不要复制自己 - do not repeat yourself
? ? 亲爱的读者， 您可以复用大神的轮子， 甚至复用整个世界， 但是 do not repeat yourself, 着里说的不要重复， 就是不要粘贴代码， 尽量不要再您的代码钟出现重复的代码， 所有编程语言发明了各种各样的技术， 让您可以复用自己的代码， 比如 变量（var） 方法(function) ?类(class)， 这些技术发明出来， 本质上就是给您复用您代码的工具

模块化

没有绝对正确， 只有相对合适
**
模块化也是为了复用， 但是模块化是一个双刃剑， 模块化是理想化的， 会让代码优雅， 可读性高， 但是在工作中，不一定适用。特别是前端。

模块化是好东西， 这个毋庸置疑， 但是在特殊场景下， 比如说后台管理系统开发层面， 刚好您在的团队人员流动比较强， 如果你模块化做的很细，有以下缺点：

• 当新人来接手代码的时候， 需要不断的跳转， 看起来很累
• 需要移植的时候， 要拷贝多个文件， 如果大部分逻辑在一个文件里面，那么只需要粗暴的拷走一个即可。
• 逻辑在同一个文件里面开发， 速度快

看吧， 这里细致的模块化就成了缺点。但是笔者需要再次强调， 模块化是一个很好的东西， 可以让您的代码组织更紧凑，也更优雅。但是也请记得， 没有绝对正确的技术， 只有相对合适的方案， 在必要时候， 我们也要做一些妥协和让步。

GET 请求url的处理

// solution 1 
axios.get(`you/path/?para1=value1&para2=value2`)

// solution 2
axios.get({
    url: "your/path",
  params: {
    para1: value1,
    para2: value2
  }
})

我们开上面的伪代码，两个方案的目的都是向服务器发送get请求， 第一种方案采用的是直接拼写完整的url， 第二个方案采用的是结构化的方案。

方案1的优点是只管， 就算刚入行的前端从业者， 也能知道这个药干嘛的， 方案二的优点是 结构化， 我们可以使用对象的方法， 和你方便的处理params, 而不是去处理这个字符串。丧失的就是直观。

再次抛出上节的观点， 没有绝对正确的技术， 只有相对合适的方案， 到底选那个， 看您的团队接收成都吧， 但是， 强烈建议， 要统一， 一个团队的风格要统一。

prototype 原型链上挂在方法

前端从业者， 肯定遇到过这种选择吧， 在原型链上挂在方法， 确实很香， 用起来特别顺手， 这里我们简单讨论一下吧

	prototype 挂在方法	import 方式引入
使用便捷	毋庸置疑， 这种事方便的	需要单独引入， 再使用
优化成都	无法做摇树优化	很方便左摇树优化（rxjs 为了左摇树优化， 后来的版本就取消了prototype挂在的方式）
侵入性	对全局有侵入性	没有

所有， 如果您挂在原型链上的方法很少， 不用考虑性能， 也不担心侵入性对其他实例的影响， 您可以放心大胆的选择原型链挂在的方法， 如果这些条件不满足， 那还是忘掉便利性， 使用import单独引入的方式吧。

注意： 笔者不建议在共有对象原型链上挂在方法， 比如在 Object Error Date 等对象上， 因为这个影响太大了， 您可以在您自己写的对象原型链上挂载， 或者三方流行lib上挂在， 比如 vue。

esm 使用风格

笔者在工作中发现部分同事不是很注重代码风格和统一性问题， 当然很多时候确实是太忙了， 没有时间注意这些， 下面是笔者建议的风格

import a from "a"
import { b1, b2 } from "b"

// variable block

// function block

// main logic

export default e;
export {
    e1,
  e2,
  e3
}

• 导入始终在文件头
• 然后是依次是 变量 方法 主逻辑
• 导出统一放在文件末尾

站在大神的肩膀上

当使用大神们的轮子的时候， 尽量按照他们设计的方式去使用。

最近笔者的一个同事在使用element-ui（老版本） 的table的时候， 她希望在table外面有个过滤， 灵活的控制表格中行的显示与隐藏， 当时他一直想着能否把filter方法使用起来， 甚至想过要去更改element-ui的源代码， 但是在公司， 哪里有那么多时间去研究。

? ? 最后公司一个老同事给了一个方案，无研究成本解决问题。 不要想那么多， 直接修改传入el-table的的 数据， 不想显示的行， 直接去掉， 想显示的时候， 再插回来， 在去掉数据的时候甚至可以把该条数据当前位置记录下俩， 插回来的时候插回原来的位置， 效果更棒， 和tabel原生的方案更好。
? ? 当时笔者也想到一个方案， 那就是不要使用el-table, 自己定制一个组件，使用v-for循环列表， 然后再行数据里面加一个flag用于标识是否显示， 当不需要显示的时候， 直接修改改行的flag, ?对数据的处理更少， 但是就要多一个组件，最快的还是老同事给的方案。

下一遍写什么

准备把笔者这些年遇到的好资源分享一下