之前写过几篇关于如何写出可维护项目的文章（[构建大型前端业务项目的一点经验](https://juejin.cn/post/7016948081321050148)、[编写可维护的现代化前端项目](https://juejin.cn/post/6844903996910485511)、[接手前端新项目？这里有些注意点你可能需要留意一下](https://juejin.cn/post/6844903678852202510)），近来看到很多公司裁员，忽然惊醒，之前是站在项目角度考虑问题，却没站在咱们程序员本身看待问题，险些酿成大错，如果人人都能做到把项目维护得井井有条，无论什么人都能看明白都能快速接手，那咱们的竞争力在哪里呢？这个时候我再看项目中那些被我天天骂的代码，顿时心中就无限景仰起来，原来屎山才是真能能够保护我们的东西，哪有什么岁月静好，只是有人替你负屎前行罢了为了能让更多人认识到这一点，站在前端的角度上，我在仔细拜读了项目中的那些暗藏玄机的代码后，决定写下此文，由于本人功力尚浅，且之前一直走在错误的道路上，所以本文在真正的高手看来可能有些班门弄斧，在此献丑了🐶 ## 用 TypeScript，但不完全用 `TypeScript`大行其道，在每个团队中，总有那么些个宵小之辈想尽一切办法在项目里引入 `ts`，这种行为严重阻碍了屎山的成长速度，但同是打工人我们也不好阻止，不过就算如此，也无法阻止我们行使正义众所周知，`TypeScript` 别名 `AnyScript`，很显然，这就是`TypeScript`创始人`Anders Hejlsberg`给我们留下的暗示，我们有理由相信`AnyScript` 才是他真正的目的 ```ts const list: any = [] const obj: any = {} const a: any = 1 ``` 引入了 `ts`的项目，由于是在原可运行代码的基础上额外添加了类型注释，所以代码体积毫无疑问会增大，有调查显示，可能会增加 `30%`的代码量，如果充分发挥 `AnyScript` 的宗旨，意味着你很轻松地就让代码增加了 `30%` 毫无用处但也挑不出啥毛病的代码，这些代码甚至还会增加项目的编译时间（毕竟增加了`ts`校验和移除的成本嘛）你不仅能让自己写的代码用上 `AnyScript`，甚至还可以给那些支持 `ts` 的第三方框架/库一个大嘴巴子 ```ts export default defineComponent({ props: { // 现在 data 是 any 类型的啦 data: { type: Number as PropType, }, }, setup(_, { emit }) { // 现在 props 是 any 类型的啦 const props: any = _ ... } }) ``` 当然了，全屏 `any`可能还是有点明显了，所以你可以适当地给部分变量加上具体类型，但是加上类型不意味着必须要正确使用 ```ts const obj: number[] = [] // ... // 虽然 obj 是个 number[]，但为了实现业务，就得塞入一些不是 number 的类型，我也不想的啊是不是 // 至于编辑器会划红线报错？那是小问题，不用管它，别人一打开这个项目就是满屏的红线，想想就激动 obj.push('2') obj.push([3]) ``` ## 命名应该更自由命名一直是个困扰很多程序员的问题，究其原因，我们总想给变量找个能够很好表达意思的名称，这样一来代码的可阅读性就高了，但现在我们知道，这并不是件好事，所以我们应该放纵自我，既摆脱了命名困难症，又加速了屎山的堆积进度 ```ts const a1 = {} const a2 = {} const a3 = 2 const p = 1 ``` 我必须强调一点，命名不仅是变量命名，还包含**文件名、类名、组件名**等，这些都是我们可以发挥的地方，例如类名 ```html

``` 乍一看似乎没啥毛病，要说有毛病似乎也不值当单独挑出来说，没错，要的就是这个效果，让人单看一段代码不好说什么，但是如果积少成多，整个项目都是 `box`呢？全局搜索都给你废了！如果你某些组件再一不小心没用 `scoped` 呢？稍不留意就不知道把什么组件的样式给改了，想想就美得很关于 `css`我还想多说一点，鉴于其灵活性，我们还可以做得更多，总有人说什么 `BEM` 不 `BEM`的，他们敢用我们就敢写这样的代码 ```scss &-card { &-btn { &_link { &--right { } } &-nodata { &_link { &--replay { &--create {} } } } } &-desc {} } ``` 好了，现在请在几百行（关于这一点下一节会说到）这种格式的代码里找出类名 `.xxx__item_current.mod-xxx__link` 对应的样式吧 ## 代码一定要长屎山一定是够高够深的，这就要求我们的代码应该是够长够多的大到一个文件的长度，小到一个类、一个函数，甚至是一个 `if` 的条件体，都是我们自由发挥的好地方。什么单文件最好不超过 `400`行，什么一个函数不超过 `100`行，简直就是毒瘤， ![1.jpg](https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/605301677ade4f8da68a8c80d70cfa8f~tplv-k3u1fbpfcp-watermark.image?) 所以这就要求我们要具备将十行代码就能解决的事情写成一百行的能力，最好能给人一种多即是少的感觉 ```ts data === 1 ? 'img' : data === 2 ? 'video' : data === 3 ? 'text' : data === 4 ? 'picture' : data === 5 ? 'miniApp' ``` 三元表达式可以优雅地表达逻辑，像诗一样，虽然这段代码看起来比较多，但逻辑就是这么多，我还专门用了三元表达式优化，不能怪我是不是？什么`map`映射枚举优化听都没听过你也可以选择其他一些比较容易实现的思路，例如，多写一些废话 ```ts if (a > 10) { // 虽然下面几个 if 中对于 a 的判断毫无用处，但不仔细看谁能看出来呢？看出来了也不好说什么，毕竟也没啥错 // 除此之外，多级 if 嵌套也是堆屎山的一个小技巧，什么提前 return 不是太明白 if (a > 5) { if (a > 3 && b) { } } if (a > 4) { } } ``` 除此之外，你还可以写一些中规中矩的方法，但重点在于这些方法根本就没用到，这种发挥的地方就更多了，简直就是扩充代码体积的利器，毕竟单看这些方法没啥毛病，但谁能想到根本就用不到呢？就算有人怀疑了，但你猜他敢随便从运行得好好的业务项目里删掉一些没啥错的代码吗？ ## 一次编写，到处引用大家应该都知道，一个公共的方法或变量最好放在公共文件夹中，这样方便引用，提升聚合度，本来这种做法是会极大阻碍屎山进程的，但俗话说事在人为，哪有什么绝对正确的东西，不过看是谁在当搅屎棍罢了例如在一个项目中，分为好几个页面，首页和详情页，我在写详情页的时候，发现有一个变量在首页已经存在了，一般做法是把这个变量提升到公共文件中去，这样将来如果涉及到各自修改的话，能做到心中有数，但我偏不，我TM直接在详情页里引用首页的变量我不仅在业务组件里引用，甚至还可以在公共组件里引用，一般做法是业务组件引用公共组件/方法/变量，嘿，我偏要公共组件引用业务组件组件/方法/变量这样导致的后果就是，一个本该私有的变量/方法，被不知道多少个页面组件、模块组件、公共文件所引用，万一需要修改，处理不好的话直接塌方，任何一个参与改动的人都战战兢兢如履薄冰，要么就是复制粘贴重写一份，要么就是要写很多没少意义的兼容逻辑，无论选择哪种，都将成为屎山的忠实贡献者 ## 组件、方法多多滴耦合为了避免其他人复用我的方法或组件，那么在写方法或组件的时候，一定要尽可能耦合，提升复用的门槛例如明明可以通过 `Props`传参解决的事情，我偏要从全局状态里取，例如`vuex`，独一份的全局数据，想传参就得改 `store`数据，但你猜你改的时候会不会影响到其他某个页面某个组件的正常使用呢？如果你用了，那你就可能导致意料之外的问题，如果你不用你就得自己重写一个组件组件不需要传参？没关系，我直接把组件的内部变量给挂到全局状态上去，虽然这些内部变量确实只有某一个组件在用，但我挂到全局状态也没啥错啊是不是嘿，明明一个组件就能解决的事情，现在有了倆，后面还可能有仨，这代码量不就上来了吗？方法也是如此，明明可以抽取参数，遵循函数式编程理念，我偏要跟外部变量产生关联 ```ts // 首先这个命名就很契合上面说的自由命名法 function fn1() { // ... // fn1 的逻辑比较长，且解决的是通用问题， // 但 myObj 偏偏是一个外部变量，这下看你怎么复用 window.myObj.name = 'otherName' window.myObj.children.push({ id: window.myObj.children.length }) // ... } ``` ## 翻译翻译，什么叫 `mutable` 翻译翻译？好，我翻译下 >~~Immutable Data 就是一旦创建，就不能再被更改的数据~~ > >Mutable Data 就是一旦创建，就能随时被更改的数据得益于 `javascript` 的灵活性，`un-immutable` 大大滴有市场，借助这把利器，我们可以让数据的流动如空气般无处不在，如何使用 `Mutable Data`相信很多初学者早已无师自通，我就不多说了，只希望你们莫忘初心难的是，能在使用这把利器的同时，还能驾驭好它如何做到？我们以 `vue`为例的话，那么只需要三个单词：`Watch`、`Watch` 还是踏马的 `Watch`！ ```js export default { watch: { '$route.name': fuction(){ this.handleChange() }, 'userName': fuction(){ this.handleChange() }, 'dateTime': fuction(){ this.handleChange() }, 'color': fuction(){ this.handleChange() }, 'queryKey': fuction(){ this.handleChange() }, }, methods: { handleChange() { // ... } } } ``` 当然，如果你用 `vue-ts`的话，就更省心了 ```ts @Watch('$route.name') @Watch('userName') @Watch('dateTime') @Watch('color') @Watch('queryKey') handleChange() { // ... } ``` 至于 `react`，无非是换成`useEffect`，总之本质上都是踏马的 `watch`，能 `mutable` 的绝不 `immutable`，能 `watch`的绝不主动调用！注意，千万不要加 `debounce`，想象一下，`watch` 的所有字段可能会同时触发，而 `handleChange` 恰好又是一个耗性能的方法…… ## 魔术字符串是个好东西实际上，据我观察，排除掉某些居心不轨的人之外，大部分人还是比较喜欢写魔术字符串的，这让我很欣慰，看着满屏的不知道从哪里冒出来也不知道代表着什么的硬编码字符串，让人很有安全感 ```ts if (a === 'prepare') { const data = localStorage.getItem('HOME-show_guide') // ... } else if (a === 'head' && b === 'repeating-error') { switch(c) { case 'pic': // ... break case 'inDrawer': // ... break } } ``` 基于此，我们还可以做得更多，比如用变量拼接魔术字符串，`debug`的时候直接废掉全局搜索 ```ts if (a === query.name + '_head') { } ``` 大家都是中国人，为什么不试试汉字呢？ ```ts if (data === '正常') { } else if (data === '错误') { } else if (data === '通过') { } ``` 一般人认为魔术字符串就是写死的字符串，但其实还可以玩得更魔幻一点 ```ts enum EventType { Move, Skip, Batch } ``` 枚举是个好东西，可以避免直接书写无意义的字符，但前提是你真的是按照正常人思维来使用的正常人是怎么用的呢？例如，我们有一段 `vue`逻辑就是用判断这个枚举值的 ```ts handleEvent(value: EventType) { if (value === EventType.Move) { // ... } else if (value === EventType.Skip) { // ... } else if (value === EventType.Batch) { // ... } } ``` 看着没啥问题，挺好的，但在模板里，诶，我嫌麻烦，我这样写 ```vue