如何看待本輪吧以沖突

輪巴以沖突是指巴勒斯坦和以色列之間的沖突。這場沖突已經造成了雙方的傷亡和破壞。具體情況如下：

- 根據新浪新聞的報道，本輪巴以沖突已經造成雙方超過4200人死亡 [?](https://news.sina.cn/2023-10-09/detail-imzqnpfr4927525.d.html)。巴以沖突的加劇導致了巴勒斯坦和以色列之間的緊張局勢持續升溫。

- 根據第一財經的報道，巴以沖突的根源可以追溯到歐洲猶太隔離區和殖民時代的分治問題 [?](https://yicai.com/news/101873416.html)。這場沖突已經持續了很長時間，但至今仍未找到解決之道。

- 根據全球速報的報道，本輪巴以沖突的導火索是以色列警方與巴勒斯坦民眾在耶路撒冷老城阿克薩清真寺爆發的沖突 [?](https://www.thepaper.cn/newsDetail_forward_23053560)。自那以后，巴以地區的緊張局勢不斷升溫。

- 根據新華網的報道，巴以新一輪沖突已經造成超過1900人死亡 [?](http://www.news.cn/world/2023-10/11/c_1129909679.htm)。這場沖突涉及到以色列和巴勒斯坦之間的多次空襲和火箭彈襲擊。

- 根據股吧話題的討論，巴以沖突的持續升級可能對全球經濟產生影響，如國際油價的波動、黃金價格的上漲等 [?](https://gubatopic.eastmoney.com/topic_v3.html?htid=7870)。

根據以上搜索結果，本輪巴以沖突已經造成了雙方的傷亡和破壞。巴以沖突的根源復雜，涉及歷史、領土爭端等多個因素。解決巴以沖突需要各方共同努力，通過對話和談判來實現和平與穩定。

發博客地址

系列文章地址

引自《阿里規約》的開頭片段：

現代軟件架構的復雜性需要協同開發完成，如何高效地協同呢？無規矩不成方圓，無規范難以協同，比如，制訂交通法規表面上是要限制行車權，實際上是保障公眾的人身安全，試想如果沒有限速，沒有紅綠燈，誰還敢上路行駛。對軟件來說，適當的規范和標準絕不是消滅代碼內容的創造性、優雅性，而是限制過度個性化，以一種普遍認可的統一方式一起做事，提升協作效率，降低溝通成本。代碼的字里行間流淌的是軟件系統的血液，質量的提升是盡可能少踩坑，杜絕踩重復的坑，切實提升系統穩定性，碼出質量。

(一)命名規范

1.1.1 項目命名

全部采用小寫方式，以中劃線分隔。

正例：mall-management-system

反例：mall_management-system / mallManagementSystem

1.1.2 目錄命名

全部采用小寫方式，以中劃線分隔，有復數結構時，要采用復數命名法，縮寫不用復數。

正例：scripts / styles / components / images / utils / layouts / demo-styles / demo-scripts / img / doc

反例：script / style / demo_scripts / demoStyles / imgs / docs

【特殊】VUE 的項目中的 components 中的組件目錄，使用 kebab-case 命名。

正例：head-search / page-loading / authorized / notice-icon

反例：HeadSearch / PageLoading

【特殊】VUE 的項目中的除 components 組件目錄外的所有目錄也使用 kebab-case 命名。

正例：page-one / shopping-car / user-management

反例：ShoppingCar / UserManagement

1.1.3 JS、CSS、SCSS、HTML、PNG 文件命名

全部采用小寫方式，以中劃線分隔。

正例：render-dom.js / signup.css / index.html / company-logo.png

反例：renderDom.js / UserManagement.html

1.1.4 命名嚴謹性

代碼中的命名嚴禁使用拼音與英文混合的方式，更不允許直接使用中文的方式。說明：正確的英文拼寫和語法可以讓閱讀者易于理解，避免歧義。注意，即使純拼音命名方式也要避免采用。

正例：henan / luoyang / rmb 等國際通用的名稱，可視同英文。

反例：DaZhePromotion [打折] / getPingfenByName() [評分] / int 某變量=3

杜絕完全不規范的縮寫，避免望文不知義：

反例：AbstractClass“縮寫”命名成 AbsClass；condition“縮寫”命名成 condi，此類隨意縮寫嚴重降低了代碼的可閱讀性。

(二)HTML 規范（Vue Template 同樣適用）

1.2.1 HTML 類型

推薦使用 HTML5 的文檔類型聲明。建議使用 text/html 格式的 HTML，避免使用 XHTML。XHTML 以及它的屬性，比如 application/xhtml+xml 在瀏覽器中的應用支持與優化空間都十分有限。

規定字符編碼
IE 兼容模式
規定字符編碼
doctype 大寫

正例：

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="X-UA-Compatible" content="IE=Edge" />
    <meta charset="UTF-8" />
    <title>Page title</title>
  </head>
  <body>
    <img src="images/company-logo.png" alt="Company" />
  </body>
</html>

1.2.2 縮進

縮進使用 2 個空格（一個 tab）。

嵌套的節點應該縮進。

1.2.3 分塊注釋

在每一個塊狀元素，列表元素和表格元素后，加上一對 HTML 注釋。注釋格式：

<!-- 英文 中文 start -->

<!-- 英文 中文 end -->

正例：

<body>
  
  <header>
    <div class="container">
      <a href="#">
        
        <img src="images/header.jpg" />
      </a>
    </div>
  </header>
  
</body>

1.2.4 語義化標簽

HTML5 中新增很多語義化標簽，所以優先使用語義化標簽，避免一個頁面都是 div 或者 p 標簽。

正例：

<header></header>
<footer></footer>

反例：

<div></div>

1.2.5 引號

使用雙引號(" ") 而不是單引號(' ')。

正例： <div class="news-div"></div>

反例： <div class='news-div'></div>

(三) CSS 規范

1.3.1 命名

類名使用小寫字母，以中劃線分隔。
id 采用駝峰式命名。
scss 中的變量、函數、混合、placeholder 采用駝峰式命名。

ID 和 class 的名稱總是使用可以反應元素目的和用途的名稱，或其他通用的名稱，代替表象和晦澀難懂的名稱。

不推薦：

.fw-800 {
  font-weight: 800;
}

.red {
  color: red;
}

推薦：

.heavy {
  font-weight: 800;
}

.important {
  color: red;
}

1.3.2 選擇器

1)css 選擇器中避免使用標簽名。從結構、表現、行為分離的原則來看，應該盡量避免 css 中出現 HTML 標簽，并且在 css 選擇器中出現標簽名會存在潛在的問題。

2)很多前端開發人員寫選擇器鏈的時候不使用直接子選擇器（注：直接子選擇器和后代選擇器的區別）。有時，這可能會導致疼痛的設計問題并且有時候可能會很耗性能。然而，在任何情況下，這是一個非常不好的做法。如果你不寫很通用的，需要匹配到 DOM 末端的選擇器，你應該總是考慮直接子選擇器。

不推薦：

.content .title {
  font-size: 2rem;
}

推薦：

.content > .title {
  font-size: 2rem;
}

1.3.3 盡量使用縮寫屬性

不推薦：

border-top-style: none;
font-family: palatino, georgia, serif;
font-size: 100%;
line-height: 1.6;
padding-bottom: 2em;
padding-left: 1em;
padding-right: 1em;
padding-top: 0;

推薦：

border-top: 0;
font: 100%/1.6 palatino, georgia, serif;
padding: 0 1em 2em;

1.3.4 每個選擇器及屬性獨占一行

不推薦：

button{
  width:100px;height:50px;color:#fff;background:#00a0e9;
}

推薦：

button{
  width:100px;
  height:50px;
  color:#fff;
  background:#00a0e9;
}

1.3.5 省略 0 后面的單位

不推薦：

div{
  padding-bottom: 0px;
  margin: 0em;
}

推薦：

div{
  padding-bottom: 0;
  margin: 0;
}

1.3.6 避免使用 ID 選擇器及全局標簽選擇器防止污染全局樣式

不推薦：

#header{
  padding-bottom: 0px;
  margin: 0em;
}

推薦：

.header{
  padding-bottom: 0px;
  margin: 0em;
}

(四) LESS 規范

1.4.1 代碼組織

1)將公共 less 文件放置在 style/less/common 文件夾。

例：// color.less,common.less

2)按以下順序組織：

1、@import;

2、變量聲明;

3、樣式聲明;

@import "mixins/size.less";

@default-text-color: #333;

.page {
  width: 960px;
  margin: 0 auto;
}

1.4.2 避免嵌套層級過多

將嵌套深度限制在 3 級。對于超過 4 級的嵌套，給予重新評估。這可以避免出現過于詳實的 CSS 選擇器。避免大量的嵌套規則。當可讀性受到影響時，將之打斷。推薦避免出現多于 20 行的嵌套規則出現。

不推薦：

.main{
  .title{
    .name{
       color:#fff
    }
  }
}

推薦：

.main-title{
   .name{
      color:#fff
   }
}

(五) JavaScript 規范

1.5.1 命名

1)采用小寫駝峰命名 lowerCamelCase，代碼中的命名均不能以下劃線，也不能以下劃線或美元符號結束。

反例： _name / name_ / name$

2)方法名、參數名、成員變量、局部變量都統一使用 lowerCamelCase 風格，必須遵從駝峰形式。

正例： localValue / getHttpMessage() / inputUserId

其中 method 方法命名必須是動詞或者動詞+名詞形式。

正例：saveShopCarData / openShopCarInfoDialog

反例：save / open / show / go

特此說明，增刪查改，詳情統一使用如下 5 個單詞，不得使用其他（目的是為了統一各個端）。

add / update / delete / detail / get

附：函數方法常用的動詞：

get 獲取/set 設置, add 增加/remove 刪除 create 創建/destory 移除 start 啟動/stop 停止 open 打開/close 關閉, read 讀取/write 寫入 load 載入/save 保存, create 創建/destroy 銷毀 begin 開始/end 結束, backup 備份/restore 恢復 import 導入/export 導出, split 分割/merge 合并 inject 注入/extract 提取, attach 附著/detach 脫離 bind 綁定/separate 分離, view 查看/browse 瀏覽 edit 編輯/modify 修改, select 選取/mark 標記 copy 復制/paste 粘貼, undo 撤銷/redo 重做 insert 插入/delete 移除, add 加入/append 添加 clean 清理/clear 清除, index 索引/sort 排序 find 查找/search 搜索, increase 增加/decrease 減少 play 播放/pause 暫停, launch 啟動/run 運行 compile 編譯/execute 執行, debug 調試/trace 跟蹤 observe 觀察/listen 監聽, build 構建/publish 發布 input 輸入/output 輸出, encode 編碼/decode 解碼 encrypt 加密/decrypt 解密, compress 壓縮/decompress 解壓縮 pack 打包/unpack 解包, parse 解析/emit 生成 connect 連接/disconnect 斷開, send 發送/receive 接收 download 下載/upload 上傳, refresh 刷新/synchronize 同步 update 更新/revert 復原, lock 鎖定/unlock 解鎖 check out 簽出/check in 簽入, submit 提交/commit 交付 push 推/pull 拉, expand 展開/collapse 折疊 begin 起始/end 結束, start 開始/finish 完成 enter 進入/exit 退出, abort 放棄/quit 離開 obsolete 廢棄/depreciate 廢舊, collect 收集/aggregate 聚集

1.5.2 代碼格式

1)使用 2 個空格進行縮進。

正例：

if (x < y) {
  x +=10;
} else {
  x +=1;
}

2)不同邏輯、不同語義、不同業務的代碼之間插入一個空行分隔開來以提升可讀性。

!! 說明：任何情形，沒有必要插入多個空行進行隔開。

1.5.3 字符串

統一使用單引號(')，不使用雙引號(")。這在創建 HTML 字符串非常有好處。

正例：

let str='foo';
let testDiv='<div id="test"></div>';

1.5.4 對象聲明

1)使用字面值創建對象。

正例： let user={};

反例： let user=new Object();

2)使用字面量來代替對象構造器。

正例：

var user={
  age: 0,
  name: 1,
  city: 3
};

反例：

var user=new Object();
user.age=0;
user.name=0;
user.city=0;

1.5.5 使用 ES6,7

必須優先使用 ES6,7 中新增的語法糖和函數。這將簡化你的程序，并讓你的代碼更加靈活和可復用。

!! 必須強制使用 ES6, ES7 的新語法，比如箭頭函數、await/async ，解構， let ， for...of 等等

1.5.6 括號

下列關鍵字后必須有大括號（即使代碼塊的內容只有一行）：if, else, for, while, do, switch, try, catch, finally, with。

正例：

if (condition) {
  doSomething();
}

反例：

if (condition) doSomething();

1.5.7 undefined 判斷

永遠不要直接使用 undefined 進行變量判斷；使用 typeof 和字符串 'undefined' 對變量進行判斷。

正例：

if (typeof person==='undefined') {
    ...
}

反例：

if (person===undefined) {
    ...
}

1.5.8 條件判斷和循環最多三層

條件判斷能使用三目運算符和邏輯運算符解決的，就不要使用條件判斷，但是謹記不要寫太長的三目運算符。如果超過 3 層請抽成函數，并寫清楚注釋。

1.5.9 this 的轉換命名

對上下文 this 的引用只能使用 'self' 來命名。

1.5.10 慎用 console.log

因 console.log 大量使用會有性能問題，所以在非 webpack 項目中謹慎使用 log 功能。

(一) Vue 編碼基礎

vue 項目規范以 Vue 官方規范（https://cn.vuejs.org/v2/style-guide/）中的 A 規范為基礎，在其上面進行項目開發，故所有代碼均遵守該規范。

請仔細閱讀 Vue 官方規范，切記，此為第一步。

2.1.1 組件規范

1) 組件名為多個單詞。

組件名應該始終由多個單詞組成，且命名規范為KebabCase格式。這樣做可以避免與現有和未來的 HTML 元素沖突，因為所有 HTML 元素名稱都是由單個單詞組成的。

正例：

export default {
  name: 'TodoItem'
};

反例：

export default {
  name: 'Todo'
};

export default {
  name: 'todo-item'
};

2) 組件文件名為 PascalCase 格式

正例：

components/
|- MyComponent.vue

反例：

components/
|- myComponent.vue
|- MyComponent.vue

3) 基礎組件文件名以 base 開頭，使用完整單詞而不是縮寫。

正例：

components/
|- base-button.vue
|- base-table.vue
|- base-icon.vue

反例：

components/
|- MyButton.vue
|- VueTable.vue
|- Icon.vue

4) 和父組件緊密耦合的子組件應該以父組件名作為前綴命名

正例：

components/
|- todo-list.vue
|- todo-list-item.vue
|- todo-list-item-button.vue
|- user-profile-options.vue （完整單詞）

反例：

components/
|- TodoList.vue
|- TodoItem.vue
|- TodoButton.vue
|- UProfOpts.vue （使用了縮寫）

5) 在 Template 模板中使用組件，應使用 PascalCase 格式，并使用自閉合組件。

正例：

<MyComponent />
<Row><table :column="data"/></Row>

反例：

<my-component /> <row><table :column="data"/></row>

6) 組件的 data 必須是一個函數

當在組件中使用 data 屬性時（除了 new Vue 外的任何地方），它的值必須是一個返回對象的函數。因為如果直接是一個對象，子組件之間的屬性值會相互影響。

正例：

export default {
  data () {
    return {
      name: 'jack'
    }
  }
}

反例：

export default {
  data: {
    name: 'jack'
  }
}

7) Prop 定義應該盡量詳細

必須使用 camelCase 駝峰命名
必須指定類型
必須加上注釋，表明其含義
必須加上 required 或者 default，兩者二選其一
如果有業務需要，必須加上 validator 驗證

正例：

props: {
  status: {
    type: String,
    required: true,
    validator: function (value) {
      return [
        'succ',
        'info',
        'error'
      ].indexOf(value) !==-1
    }
  },
  userLevel: {
    type: String,
    required: true
  }
}

8) 為組件樣式設置作用域

正例：

<template>
  <button class="btn btn-close">X</button>
</template>

<style scoped>
  .btn-close {
    background-color: red;
  }
</style>

反例：

<template>
  <button class="btn btn-close">X</button>
</template>

<style>
  .btn-close {
    background-color: red;
  }
</style>

9) 如果特性元素較多，應主動換行。

正例：

<MyComponent foo="a" bar="b" baz="c"
    foo="a" bar="b" baz="c"
    foo="a" bar="b" baz="c"
/>

反例：

<MyComponent foo="a" bar="b" baz="c" foo="a" bar="b" baz="c" foo="a" bar="b" baz="c" foo="a" bar="b" baz="c"/>

2.1.2 模板中使用簡單的表達式

組件模板應該只包含簡單的表達式，復雜的表達式應重構為計算屬性或方法。復雜表達式會使你的模板變得不那么聲明式。我們應該盡量描述應該出現的是什么，而不是如何計算那個值。而且計算屬性和方法使得代碼可以重用。

正例：

<template>
  <p>{{ normalizedFullName }}</p>
</template>

computed: {
  normalizedFullName: function () {
    return this.fullName.split(' ').map(function (word) {
      return word[0].toUpperCase() + word.slice(1)
    }).join(' ')
  }
}

反例：

<template>
  <p>
    {{
      fullName.split(' ').map(function (word) {
        return word[0].toUpperCase() + word.slice(1)
      }).join(' ')
    }}
  </p>
</template>

2.1.3 指令都使用縮寫形式

指令推薦使用縮寫形式，用 : 表示 v-bind: ，用 @ 表示 v-on: ，用 # 表示 v-slot:

正例：

<input
  @input="onInput"
  @focus="onFocus"
>

反例：

<input
  v-on:input="onInput"
  @focus="onFocus"
>

2.1.4 標簽順序保持一致

單文件組件應該始終按照 <template>、<script>、<style> 的順序排列。

正例：

<template>...</template>
<script>...</script>
<style>...</style>

反例：

<template>...</template>
<style>...</style>
<script>...</script>

2.1.5 必須為 v-for 設置鍵值 key

2.1.6 v-show 與 v-if 選擇

如果需要頻繁切換元素的可見性，使用 v-show ；如果在運行時條件很少改變，使用 v-if。

2.1.7 script 標簽內部結構順序

components > props > data > computed > watch > filter > 鉤子函數（按執行順序排列） > methods

2.1.8 Vue Router 規范

1) 頁面跳轉數據傳遞使用路由參數

頁面跳轉，例如從 A 頁面跳轉到 B 頁面，需要將 A 頁面的數據傳遞到 B 頁面，推薦使用路由參數進行傳參，而不是將需要傳遞的數據保存在 vuex，然后在 B 頁面取出 vuex 中的數據，因為如果在 B 頁面刷新會導致 vuex 數據丟失，導致 B 頁面無法正常顯示數據。

正例：

let id='123';
this.$router.push({ name: 'userCenter', query: { id: id } });

2) 使用路由懶加載（延遲加載）機制

{
  path: '/uploadAttachment',
  name: 'uploadAttachment',
  meta: {
    title: '上傳附件'
  },
  component: ()=> import('@/view/components/uploadAttachment/index.vue')
}

3) router 中的命名規范

path、childrenPoints 命名規范采用kebab-case命名規范（盡量保持 vue 文件的目錄結構一致，因為目錄和文件名都是kebab-case，這樣很方便找到對應的文件）

name 命名規范采用KebabCase命名規范且與 component 組件名保持一致！（要保持 keep-alive 特性，keep-alive 按照 component 的 name 進行緩存，所以兩者必須高度保持一致）

export const reload=[
  {
    path: '/reload',
    name: 'reload',
    component: Main,
    meta: {
      title: '動態加載',
      icon: 'icon iconfont'
    },
    children: [
      {
        path: '/reload/smart-reload-list',
        name: 'SmartReloadList',
        meta: {
          title: 'SmartReload',
          childrenPoints: [
            {
              title: '查詢',
              name: 'smart-reload-search'
            },
            {
              title: '執行reload',
              name: 'smart-reload-update'
            },
            {
              title: '查看執行結果',
              name: 'smart-reload-result'
            }
          ]
        },
        component: ()=>
          import('@/views/reload/smart-reload/smart-reload-list.vue')
      }
    ]
  }
];

4) router 中的 path 命名規范

path 應采用kebab-case命名規范，并以 / 開頭，即使是 children 中的 path 也要以 / 開頭。例如：

目的：經常需要找到某個 vue 文件時，可以立即找到它。如果 path 不以 / 開頭，由 parent 和 children 組成，可能需要在 router 文件中多次搜索才能找到。而以 / 開頭，可以立即搜索到對應的組件。

{
  path: '/file',
  name: 'File',
  component: Main,
  meta: {
    title: '文件服務',
    icon: 'ios-cloud-upload'
  },
  children: [
    {
      path: '/file/file-list',
      name: 'FileList',
      component: ()=> import('@/views/file/file-list.vue')
    },
    {
      path: '/file/file-add',
      name: 'FileAdd',
      component: ()=> import('@/views/file/file-add.vue')
    },
    {
      path: '/file/file-update',
      name: 'FileUpdate',
      component: ()=> import('@/views/file/file-update.vue')
    }
  ]
}

(二) Vue 項目目錄規范

2.2.1 基礎

Vue 項目中的所有命名必須與后端命名保持一致。
比如權限：后端 privilege，前端無論是 router、store、api 等都必須使用 privilege 單詞！

2.2.2 使用 Vue CLI 腳手架

使用 Vue CLI 3 來初始化項目，項目名按照上述命名規范命名。

2.2.3 目錄說明

目錄名按照上述命名規范，其中 components 組件使用大寫駝峰命名，其余目錄（除 components 組件目錄外）使用 kebab-case 命名。

src                               源碼目錄
|-- api                              所有 API 接口
|-- assets                           靜態資源，包括 images、icons、styles 等
|-- components                       公共組件
|-- config                           配置信息
|-- constants                        常量信息，項目中的所有枚舉、全局常量等
|-- directives                       自定義指令
|-- filters                          過濾器，全局工具
|-- datas                            模擬數據，臨時存放
|-- lib                              外部引用的插件存放及修改文件
|-- mock                             模擬接口，臨時存放
|-- plugins                          插件，全局使用
|-- router                           路由，統一管理
|-- store                            Vuex，統一管理
|-- themes                           自定義樣式主題
|-- views                            視圖目錄
|   |-- role                             role 模塊
|   |-- |-- role-list.vue                    role 列表頁面
|   |-- |-- role-add.vue                     role 新建頁面
|   |-- |-- role-update.vue                  role 更新頁面
|   |-- |-- index.less                      role 模塊樣式
|   |-- |-- components                      role 模塊通用組件文件夾
|   |-- employee                         employee 模塊

1) api 目錄

文件和變量命名要與后端保持一致。
此目錄對應后端的 API 接口，按照每個 controller 一個 API JS 文件的方式組織。如果項目較大，可以根據業務進行子目錄劃分，但與后端保持一致。
API 文件中的方法名應與后端 API URL 盡量保持語義一致。
每個 API 方法都應添加注釋，注釋與后端的 Swagger 文檔保持一致。

正例：

后端 URL：EmployeeController.java

/employee/add
/employee/delete/{id}
/employee/update

前端：employee.js

addEmployee: (data)=> {
  return postAxios('/employee/add', data)
},

updateEmployee: (data)=> {
  return postAxios('/employee/update', data)
},

deleteEmployee: (employeeId)=> {
  return postAxios('/employee/delete/' + employeeId)
},

2) assets 目錄

assets 目錄存放靜態資源，包括 images、styles、icons 等靜態資源，靜態資源命名格式為 kebab-case。

|assets
|-- icons
|-- images
|   |-- background-color.png
|   |-- upload-header.png
|-- styles

3) components 目錄

此目錄按組件進行目錄劃分，目錄命名為 KebabCase，組件命名規則也為 KebabCase。

|components
|-- error-log
|   |-- index.vue
|   |-- index.less
|-- markdown-editor
|   |-- index.vue
|   |-- index.js
|-- kebab-case

4) constants 目錄

此目錄存放項目中的所有常量。如果常量在 Vue 中使用，請使用 Vue-enum 插件（https://www.npmjs.com/package/vue-enum）。

目錄結構：

|constants
|-- index.js
|-- role.js
|-- employee.js

示例：employee.js

export const EMPLOYEE_STATUS={
  NORMAL: {
    value: 1,
    desc: '正常'
  },
  DISABLED: {
    value: 1,
    desc: '禁用'
  },
  DELETED: {
    value: 2,
    desc: '已刪除'
  }
};

export const EMPLOYEE_ACCOUNT_TYPE={
  QQ: {
    value: 1,
    desc: 'QQ登錄'
  },
  WECHAT: {
    value: 2,
    desc: '微信登錄'
  },
  DINGDING: {
    value: 3,
    desc: '釘釘登錄'
  },
  USERNAME: {
    value: 4,
    desc: '用戶名密碼登錄'
  }
};

export default {
  EMPLOYEE_STATUS,
  EMPLOYEE_ACCOUNT_TYPE
};

5) router 與 store 目錄

這兩個目錄必須根據業務進行拆分，不能放在一個 JS 文件中。
router 應與 views 目錄的結構保持一致。
store 按業務進行拆分為不同的 JS 文件。

6) views 目錄

命名要與后端、router、api 等保持一致。
components 中的組件應使用 PascalCase 規則。

|-- views                            視圖目錄
|   |-- role                             role 模塊
|   |   |-- role-list.vue                    role 列表頁面
|   |   |-- role-add.vue                     role 新建頁面
|   |   |-- role-update.vue                  role 更新頁面
|   |   |-- index.less                      role 模塊樣式
|   |   |-- components                      role 模塊通用組件文件夾
|   |   |   |-- role-header.vue                        role 頭部組件
|   |   |   |-- role-modal.vue                         role 彈出框組件
|   |-- employee                         employee 模塊
|   |-- behavior-log                      行為日志 log 模塊
|   |-- code-generator                    代碼生成器模塊

2.2.4 注釋說明

需要添加注釋的地方包括：
公共組件的使用說明
api 目錄中的接口 JS 文件必須添加注釋
store 中的 state、mutation、action 等必須添加注釋
Vue 文件中的 template 必須添加注釋，如果文件較大，可以添加 start 和 end 注釋
Vue 文件的 methods，每個 method 必須添加注釋
Vue 文件的 data，非常見單詞必須添加注釋

2.2.5 其他

1) 盡量避免手動操作 DOM

由于使用了 Vue 框架，所以在項目開發中盡量使用 Vue 的數據驅動更新 DOM，避免（除非萬不得已）手動操作 DOM，包括增刪改 DOM 元素、更改樣式、添加事件等。

2) 刪除無用代碼

由于使用了 Git/SVN 等版本控制工具，必須及時刪除無用代碼，例如調試時的 console 語句、廢棄的功能代碼等。

規范的目的是為了編寫高質量的代碼，讓團隊成員每天都有愉悅的心情，讓大家在一起感到快樂。

!! 參考：https://xie.infoq.cn/article/2048f2116f8df30115fca44c1。

ss是前端領域的一個難纏戶，一提到css，沒有人會說難，也沒有人愿意承認自己不會寫，甚至在面試的過程中css相關的內容都很少提及，足以說明大家對css的不重視。你真的會寫css嗎？

關于css有兩類問題值得我們重視：樣式和工程。樣式問題指的是具體的效果實現，能否實現某個效果，同一個效果有多種實現方式，如何抉擇；工程問題是如何在大型項目中寫出可維護性、可讀的css。

在各種論壇中經常看到關于css是否是一門編程語言的爭論。在我看來，最好用對待編程語言的態度來看待css，不要忽視css，否則，在項目后期，你會發現，你的css越來越混亂，important會越來越多，不同位置的類名互相沖突覆蓋，改一個類的樣式，要檢查整個項目的頁面是否受到影響，項目內部的css共享完全依賴拷貝……從這個角度來說，你敢說css不是編程語言？它完全有了像編程語言一樣能把你搞得焦頭爛額的能力。而這一切都來源于你在一開始對她的忽視與不屑。出來混，總要還的啊！

css的問題

盲目的定義基礎樣式

在項目開始之初，拿到UI設計稿，信心滿滿地開始定義css的全局基礎樣式，謝天謝地，css對這一點支持得很徹底，一處定義，所有頁面都可以引用。

先來一個color-red。

.color-red {
	color: red
}

這樣，在整個項目中，都可以給任意元素添加一個color-red類，美滋滋，我真是個小機靈鬼！

幾個迭代過去，你已經把color-red這面紅旗插滿了整個項目。UED說，咱們改個版，所有紅色的文本改為藍色，紅色的link不變！

嗶！——（你發出的聲音）

你又得屁顛屁顛地把一個一個的紅旗拔出來，再插上藍色的旗子（因為你不敢不干呀）。

命名沖突

在一個頁面，你定義了一個.header，寫了個完美的特效，發布到dev一看，就是不管用，橫看豎看，本地是好的啊，神奇（生氣）！過了若干時間的排查，另一個同事在另一個地方也寫了一個.header，完美的覆蓋了你的。把你頭打歪！

編輯器可不會提醒你哦！

慢慢你會發現，這種命名沖突可太頻繁了呀！頭大，要不要用上css modular啊？

子類覆蓋

有的小伙伴聰明地將類名嵌套定義，這就不會沖突了吧？嘿嘿，你想多了！

/* in article.css */
.article .title {
  border-bottom: 1px solid;
  font-size: 1.5em;
}

/* in widget.css */
.widget .title {
  color: gray;
  text-transform: uppercase;
}

如果在dom樹里面，article和widget在一棵樹的路徑上，你說title是沖突呢還是不沖突呢？

以上的這些問題，在項目中相信大家都遇見過，并且項目越大，出現的概率就越高，最后就會演變成一座[屎]山。

“大家都別動，牽一發而動全身哦！”

“這就是蝴蝶效應吧？？？”

認識BEM

難道css這些問題就沒法解決了嗎？當然不是，我們來看看大神們是如何解決這些問題的。

BEM是Block、Element、Modifier的縮寫，是一個類命名的規范。

首先我們來看一個例子：

/* Block */
.btn {}

/* Element that depends upon the block */ 
.btn__price {}

/* Modifier that changes the style of the block */
.btn--orange {} 
.btn--big {}

相信小伙伴們已經有了一個初步的認知：

Block是一個獨立的組件（元素），定義的了“組件是什么，按鈕？還是菜單？”。

Element是屬于Block，是依賴于Block的元素，描述的是“Block里面的什么？比如，文本？圖標？”

Modifier用于描述Block或者Element的外在表現，比如大小、顏色、狀態等。

看一個例子：

<form class="search-form search-form_theme_islands">
    <input class="search-form__input">
    <button class="search-form__button search-form__button_size_m">Search</button>
</form>

search-form是Block；

search-form_theme_islands是Modifier，描述了theme為islands的search-form；

search-form__input是Element，描述的是search-form內部的input元素；

search-form__button是Element，描述的是search-form內部的button元素；

search-form__button_size_m是Modifier，描述的是size為m的search-form__button；

這樣寫css是不是非常的清晰？瞬間就提高了可讀性和可維護性？

概念如此簡單，還不趕緊多了解一下？

另外，可能有些小伙伴也注意到了，Block和Element使用雙下劃線分隔，和Modifier是用中劃線分隔，這也不是一成不變的，可以按照自己的喜好來決定如何分割。

Saas、Css Module

有些小伙伴可能會有疑問，BEM和Saas、Css Module有什么區別？解決的問題是一樣的嗎？

Sass是css的預處理器，在寫css的時候定義了一套規范，經過編譯處理后輸出為css，和BEM是兩個不同的概念。使用saas或less也能實現BEM。BEM其實是不推崇類名的嵌套定義的，如果想像sass那樣嵌套的寫出標準的BEM，可以使用@at-root。

Css Module解決的問題是多個模塊的css的命名沖突問題，個人覺得是傻瓜式解決方案，在應用層的css-in-js應用比較多，適合css入門選手。要想寫好css，還是得從根本上入手呀！

在線咨詢

上一篇：碼農救贖#昂科旗#原廠360記錄儀，分享視頻轉換腳本
下一篇：前端基礎知識-HTML和css1

您的項目需求

*請認真填寫需求信息，我們會在24小時內與您取得聯系。

整合營銷服務商

如何看待本輪吧以沖突

(一)命名規范

1.1.1 項目命名

1.1.2 目錄命名

1.1.3 JS、CSS、SCSS、HTML、PNG 文件命名

1.1.4 命名嚴謹性

(二)HTML 規范 （Vue Template 同樣適用）

1.2.1 HTML 類型

1.2.2 縮進

1.2.3 分塊注釋

1.2.4 語義化標簽

1.2.5 引號

(三) CSS 規范

1.3.1 命名

1.3.2 選擇器

1.3.3 盡量使用縮寫屬性

1.3.4 每個選擇器及屬性獨占一行

1.3.5 省略 0 后面的單位

1.3.6 避免使用 ID 選擇器及全局標簽選擇器防止污染全局樣式

(四) LESS 規范

1.4.1 代碼組織

1.4.2 避免嵌套層級過多

(五) JavaScript 規范

1.5.1 命名

1.5.2 代碼格式

1.5.3 字符串

1.5.4 對象聲明

1.5.5 使用 ES6,7

1.5.6 括號

1.5.7 undefined 判斷

1.5.8 條件判斷和循環最多三層

1.5.9 this 的轉換命名

1.5.10 慎用 console.log

(一) Vue 編碼基礎

2.1.1 組件規范

1) 組件名為多個單詞。

2) 組件文件名為 PascalCase 格式

3) 基礎組件文件名以 base 開頭，使用完整單詞而不是縮寫。

4) 和父組件緊密耦合的子組件應該以父組件名作為前綴命名

5) 在 Template 模板中使用組件，應使用 PascalCase 格式，并使用自閉合組件。

6) 組件的 data 必須是一個函數

7) Prop 定義應該盡量詳細

8) 為組件樣式設置作用域

9) 如果特性元素較多，應主動換行。

2.1.2 模板中使用簡單的表達式

2.1.3 指令都使用縮寫形式

2.1.4 標簽順序保持一致

2.1.5 必須為 v-for 設置鍵值 key

2.1.6 v-show 與 v-if 選擇

2.1.7 script 標簽內部結構順序

2.1.8 Vue Router 規范

1) 頁面跳轉數據傳遞使用路由參數

2) 使用路由懶加載（延遲加載）機制

3) router 中的命名規范

4) router 中的 path 命名規范

(二) Vue 項目目錄規范

2.2.1 基礎

2.2.2 使用 Vue CLI 腳手架

2.2.3 目錄說明

1) api 目錄

2) assets 目錄

3) components 目錄

4) constants 目錄

5) router 與 store 目錄

6) views 目錄

2.2.4 注釋說明

2.2.5 其他

1) 盡量避免手動操作 DOM

2) 刪除無用代碼

css的問題

認識BEM

Saas、Css Module

您的項目需求

(二)HTML 規范（Vue Template 同樣適用）