一號(hào)屎山--目錄雜亂

危害程度：??

├── App.vue
├── api
├── components
├── constants
├── main.js
├── pages
├── router
├── services
├── utils
│   └── hash.js
└── views

二號(hào)屎山--奇葩命名法

危害程度：??????????
1.全拼音命名法
”畢竟都是中國人嘛，全拼音命名大家應(yīng)該都看得懂吧“，舉個(gè)例子：dazhe.vue。但是同一個(gè)拼音可以翻譯出不同的意思出來，他們之間是一對(duì)多的關(guān)系，因此不適合作為組件名；當(dāng)然，全拼音命名還算是手下留情的，有的時(shí)候全拼音命名可能會(huì)很長，那就直接取首字母吧！

2.拼音首字母命名法
于是dazhe.vue變成了dz.vue，這個(gè)時(shí)候就成了猜謎語，有一首歌詞寫得好：女孩的心思男孩你別猜別猜別猜你猜來猜去也猜不明白，到了這里就是代碼的心思你別猜，直接放棄吧！

3.中西合璧命名法
有些同學(xué)覺得光中文那不太高大上啊，要把英語也加進(jìn)來才能顯示自己的水平，所以這樣命名：dzList.vue，照樣還是讓人看不懂

三號(hào)屎山--組件不拆分

危害程度：??????????
Vue將template、script、style組合在一個(gè).vue文件中，這天然就會(huì)使得每一個(gè).vue文件的行數(shù)會(huì)非常多，難以維護(hù)，Vue2中一個(gè)最明顯的屎山就是幾千行、甚至上萬行的代碼，用專業(yè)的術(shù)語來講就是不符合單一職責(zé)原則，一個(gè)組件應(yīng)該只干一件事情，一個(gè)函數(shù)應(yīng)該只處理一個(gè)邏輯，剩下的邏輯交給其他函數(shù)或者組件來做；時(shí)刻牢記“SOLID”原則是遠(yuǎn)離屎山的第一心法；

四號(hào)屎山--復(fù)雜的表達(dá)式

危害程度：??????

 <div
    class="files"
    :class="{ disabled: !isAllowRead && hasNotPassed && aaa && (bbb || ccc) }"
    @click="toDetail()"
  >
  <a/>
  <b v-if="!isAllowRead && hasNotPassed && aaa && (bbb || ccc)"/>
 </div>

=============================================================

<div
        class="files"
        :class="{ disabled: isFileDisabled }"
        @click="toDetail()"
      >
      <a/>
      <b v-if="isFileDisabled"/>
     </div>
     <script>
         export default {
             // 此處省略...
             computed: {
+              isFileDisabled(){
+                 return !isAllowRead && hasNotPassed && aaa && (bbb || ccc)
+              }
             }
         }
     </script>

五號(hào)屎山--大量重復(fù)節(jié)點(diǎn)

危害程度：??????

<template>
  <div>
    <span>姓名:{{ name }}</span>
    <span>年齡:{{ age }}</span>
    <span>性別:{{ gender }}</span>
    <span>身高:{{ height }}</span>
    <span>體重:{{ weight }}</span>
    <span>愛好{{ habit }}</span>
  </div>
</template>

 <div>
+    <span v-for="item in textConfigs" :key="item.valueKey">{{
+      response[item.valueKey]
+    }}</span>
  </div>
  
  data() {
    return {
+      textConfigs: [
+        { label: "性別", valueKey: "name" },
+        { label: "年齡", valueKey: "age" },
+        { label: "性別", valueKey: "gender" },
+        { label: "身高", valueKey: "height" },
+        { label: "體重", valueKey: "weight" },
+        { label: "愛好", valueKey: "habit" }
+      ]
    };
  },

六號(hào)屎山--if else switch

危害程度：????

if(!values.username){
    this.$message.error("用戶名不能為空")
} else if(!values.password){
    this.$message.error("密碼不能為空")
} else if(!values.phoneNumber){
    this.$message.error("手機(jī)號(hào)不能為空")
} else {
    this.submit();
}

可能有人會(huì)說，上面的代碼語義明確，寫得還不夠好嗎？但是如果需要增加更多的校驗(yàn)條件時(shí)，開發(fā)者不得不侵入到具體方法去修改代碼，使用策略模式優(yōu)化之后能夠讓校驗(yàn)條件與具體判斷邏輯解耦，當(dāng)需要增加校驗(yàn)條件時(shí)直接修改數(shù)組即可：

const validators = [
  { message: "用戶名不能為空", required: true, key: "username" },
  { message: "密碼不能為空", required: true, key: "password" },
  { message: "手機(jī)號(hào)不能為空", required: true, key: "phoneNumber" }
];

export default {
  methods: {
    validator(values) {
      const result = validators.some(el => {
        if (el.required && !values[el.key]) {
          this.$message.error(el.message);
          return true;
        }
      });
      return result;
    },
    submit(values) {
      if (this.validator(values)) {
        return;
      }

      // ... 調(diào)用接口
    }
  }
};

七號(hào)屎山--后端參數(shù)處理

危害程度：??????

 handleParams() {
      const params = {};
      params.id = this.formItem.id;
      params.startDate = this.formItem.startDate.format("YYYY-MM-DD");
      params.endDate = this.formItem.endDate.format("YYYY-MM-DD");
      params.price = this.formItem.price.toString();
      params.type = this.formItem.type;
      params.total = this.formItem.total;
      params.name = this.formItem.name;
      params.comment = this.formItem.comment;
      // ... 此處省略一萬行代碼
    }

  handleParams() {
      const { startDate, endDate, price, ...params } = this.formItem;
      params.startDate = startDate.format("YYYY-MM-DD");
      params.endDate = endDate.format("YYYY-MM-DD");
      params.price = price.toString();
      // ... 此處省掉一萬行代碼
    }

八號(hào)屎山--硬編碼

危害程度：????????

  computed: {
    isGood() {
      return this.type === 1;
    },
    isBad() {
      return this.type === 0;
    }
  }

// 貨物的品質(zhì)枚舉值
export const GOODS_TYPE = {
  good: 1, // 質(zhì)量好
  bad: 0   // 質(zhì)量差
};

九號(hào)屎山--無用代碼不刪除

危害程度：????

大段注釋不刪除，沒用的methods也不注釋，本著多一事不如少一事的原則，因?yàn)閂ue中父組件調(diào)用子組件方法比較常見，因此有些方法不使用了，自己也不去注釋或者刪除，害怕引發(fā)其他bug，或者干脆就不管，直接寫一個(gè)其他名稱的方法

無用的文件不刪除，比方說開始定義了一個(gè)list.vue,后面這個(gè)文件重構(gòu)了，直接增加了一個(gè)List.vue,目錄中同時(shí)存在這兩個(gè)文件，讓人摸不著頭腦，無形增加了項(xiàng)目復(fù)雜度，試想一下如果一個(gè)超大項(xiàng)目，一半的文件都是沒有引用到的，那是多么的可怕!

十號(hào)屎山--樣式大量重復(fù)

危害程度：??

.a{
    display:flex;
    align-items:center;
    justify-content:center;
}
.b{
     display:flex;
     align-items:center;
     justify-content:center;
     font-size:16px;
     color:red;
}

十一號(hào)屎山--不寫注釋

危害程度：????????

寫個(gè)注釋是舉手之勞，花不了多少時(shí)間，而且前面所有的屎山堆起來，如果有注釋的話還是可以快速理解其含義的，但是如果再加上不寫注釋，那就是天坑了，誰也救不了這個(gè)屎山；

羅馬的道路不是一日鋪成的，屎山的代碼也不是一天寫成的，而是在每個(gè)開發(fā)者無所謂的心態(tài)下堆成的，如果平時(shí)多注意注意至少也能保證自己寫的代碼”留有余香“。

image.png

image.png

作者：螞小蟻

鏈接：https://juejin.cn/post/7246686667750785083
來源：稀土掘金
著作權(quán)歸作者所有。商業(yè)轉(zhuǎn)載請(qǐng)聯(lián)系作者獲得授權(quán)，非商業(yè)轉(zhuǎn)載請(qǐng)注明出處。