接手前端新項目？這裏有些注意點你可能須要留意一下

時間 2019-11-29

標籤接手前端項目這裏有些注意可能須要留意一下简体版

原文原文鏈接

前段時間加入公司內一個新開業務線的前端組，因爲是新開的業務線，作的也是小程序這一塊，因此幾乎沒有任何歷史包袱，組內成員都是項目代碼第一手產出者css

我加入的時機較晚，沒有經歷過最開始的初創階段，不太清楚一開始的情況，不過據說是蠻折磨人的，須要踩坑無數，常常須要加班(雖然互聯網行業加班原本就是常態，不過如今熬過初始階段就好多了)，這讓我即慶幸又遺憾，慶幸的是我不用加班那麼晚了，遺憾的是，沒有參與到一條嶄新開業務線最開始的創建階段，不知道之後還有沒有這個機會了html

不過，我加入的時機也不是太晚，項目依舊存在不少須要填補的地方，通過這段時間對代碼的閱讀，以及平時在作需求過程當中所遇到的問題，從前端方面，暫時總結出了一些關於項目架構或構建可維護代碼方面的小小經驗。前端

組件化開發最佳實踐

如今前端的組件化開發基本上已經成爲主流了，既然已是組件化開發了，那麼天然就要遵照一些組件化開發的最佳實踐vue

每一個組件文件代碼總行數不要超過 `400`行

至於爲何是 400行，這個數字是我當初在某篇技術文章上看到的，至因而哪一個我忘記，可是不知爲什麼印象很深入，一直記着，而且根據我多年具有的經驗來看，這個數字仍是蠻準確的，通常要麼不會超過這個數，或者在這個數字左右徘徊，要麼就是比這個數字大不少的webpack

這些都很好理解，既然是組件化開發，那麼若是一個組件文件體積太大，存在幾十個方法、幾十個 data數據(若是用的是 vue框架)，那就說明這個組件大機率包含的功能點太多，是能夠被繼續細化出多個單一功能的子組件的git

太多的方法與 data數據，對於開發者來講根本就是一種折磨，別的不說，單是給這些方法起名字以及查找都是一件麻煩事，至於往後的維護，那更是噩夢通常的存在，哪怕是當初親手寫下這些代碼的程序猿，過一段時間再讓他來維護這些代碼，他十有八九都要如履薄冰，儘管確認了好多遍，但仍是會擔憂本身修改某個數據或者某個方法，會不會對之前某個較爲隱蔽的邏輯形成什麼不可預知的破壞，因而一遍又一遍地在幾十個方法與數據間測試、檢查程序員

我曾經看到過包含七十多個 data的組件github

這種狀況還算是好的，碰到不負責任的程序猿，可能直接就嫌麻煩，隨便在一大堆代碼中找個地方寫下本身的新代碼，檢查都不檢查就立馬提測上線了，由於反正之前上了那麼多需求，不當心搞亂了其中某個需求的邏輯，誰特麼知道？web

這還僅僅是往舊代碼中加新代碼罷了，若是是下線以前過時的活動代碼，或者刪除無用的邏輯，那就更讓人掉頭髮了，幾十個方法、幾十個數據纏在一塊兒，誰知道哪些方法與方法、方法與數據、數據與數據間有着怎樣的聯繫？刪掉了這段看起來應該是無用的代碼，會不會致使其餘有用代碼出什麼故障？算了算了，不刪了，反正後端接口已經關掉，這段代碼也顯示不出來，就暫時放在上面吧。卻不知，這所謂的暫時，就是海枯石爛的永遠小程序

爺爺爺爺，這段代碼真的是你寫的嗎？

因而，頁面上無用代碼愈來愈多，舊代碼與新代碼交相輝映，文件體積迅速增大，隨着時間的推移，原本輕裝上陣的新鮮代碼庫，逐漸背上了一個又一個歷史包袱，而後被後面接手的人大罵，這寫的究竟是個什麼東西？

世上本沒有歷史包袱，丟包袱的人多了，也就有了歷史包袱。

每一個函數不要超過 100行

這是接上面的，想一想也能明白，一個組件最好不超過 400行，只是一個方法就超過了 100行，那還怎麼寫？固然，這裏的數字 100根據個人經驗，也是蠻準確的，超過這個行數，好好想下，這個方法是否是包含了太多邏輯，遵循函數功能單一原則，不要讓一個方法函數包含過多的邏輯功能，是用於拉取數據，那就讓它只拉取數據，是用來整合字段的那就讓它只整合字段，別幹其餘的事情

多麼性感的臀部啊，答應我，別用它來拉shi好嗎？

這樣一來，方法函數不只功能明確，維護起來沒必要畏手畏腳，同時也可以增長方法的複用性，例如，A方法中包含了拉取頁面基本數據的功能，後來需求迭代，另一個後來添加的 B方法也須要拉取頁面基礎的功能，剛想複用以前 A方法，發現 A方法中除了拉取數據的代碼，還有判斷是否顯示彈窗、修改數據字段、埋點等多個用 if...else...連起來的代碼，因而寫 B方法的人爲了不麻煩，或者發現根本沒法複用，只好又把拉取數據的功能重寫了一遍

固然，這只是一個原則，實際需求中，若是某兩個功能邏輯就是緊密聯繫不可分割的，你也能夠寫在一個方法中，總之，在參考這個原則的前提下，靈活變通

定義方法與數據要物以類聚

指具有類似能力或者共同做用於某個功能的方法和數據，最好定義在靠近的位置，方便查找，某個功能受到那些方法和數據所控制，某個數據體包含哪些字段全都一目瞭然，不管是之後要修改仍是刪除，都能作到成竹在胸，不會遺漏

像我這麼 diao的還有 107個

例如，生命週期方法寫在一塊兒，而且按照執行的順序，不與自定義方法混插；自定義方法也要按照各自的功能進行歸類書寫，例如請求接口的方法寫到一塊兒，切換頁面彈窗的方法寫到一塊兒，頁面上與業務無關的工具方法要放到一塊兒，用戶信息的數據都定義在靠近的位置，若是你用的是 vue，那麼與模板渲染無關的變量，不要放到 data中，既提高了渲染性能，也易於區分變量的功能

// 工具方法都放到一塊兒
// 金額 分 轉 元
fen2yuan(fenNum) {
  return fenNum / 100
}
// 修改連接協議
changeUrl(url) {
  return url.replace('http', 'https')
}

// 用戶信息的數據都定義在靠近的位置
// 固然，你甚至能夠把下面這些數據，都定義在一個大的對象中
let avatar = 'https://avarat.com/a.png'
let userName = '小明'
let age = 19
複製代碼

順帶一提，CSS的書寫最好也按照這種規則，CSS書寫順序的判斷依據是 css代碼影響的方面，例如，影響元素位置的屬性 left top，影響元素長相的 color background，字體 font-size font-weight，這些有同類功能的最好都寫在一塊兒

另外，我習慣於把能引發頁面迴流的放在能引發頁面的重繪屬性的前面，對元素 影響程度 越高的屬性越放在最前面，至於什麼叫 影響程度 我也說不清楚，下面是我通常寫 css的屬性的順序，你們能夠自行領悟一下

<!-- position 放在最前面 -->
position: relative;
<!-- 而後是參照 position 進行定位的屬性 -->
top: 100px;
left: 10px;
<!-- 而後是寬高 -->
width: 100px;
height: 100px;
line-height: 20px;
<!-- 而後是 margin padding -->
margin: 10px;
padding: 20px 30px;
<!-- font -->
font-size: 20px;
font-weight: 700;
<!-- border -->
border: 1px solid red;
border-radius: 4px;
<!-- background -->
background-color: pink;
<!-- z-index -->
z-index: 10;
複製代碼

一開始我也不習慣這種略帶有束縛的寫法，可是時間長了就習慣了，這些屬性的書寫順序，徹底不用思考就迅速依次寫下，甚至有時候看到別人寫的亂七八糟不符合本身習慣的寫法，還會順手改一改。

這樣作的好處是易於查找和維護，想改 width，那就確定是在這個元素 css屬性序列的最前面，想改 background，那確定就從後面掃，也避免了在元素屬性過多的狀況下，可能致使的某個屬性出現屢次的狀況，我曾經不止一次在代碼庫中看到某個屬性，例如 background寫了兩次的事情，一個 background寫在屬性序列的上半部分，而後可能因爲這個元素的屬性太多,後來維護的人沒有看到那個 backgound，或者太亂了也不想看，因而就直接在屬性序列的最後面又寫了一個

拋開上述的好處不說，最起碼這種有條理、有順序的書寫次序，對於某些星座的人來講，看着也賞心悅目，無形之中也能讓本身與外面那些妖豔賤貨區別開來

努力學習卻不裝逼，那將毫無心義

必要而準確的註釋

須要長期維護的項目，必要而準確的註釋必不可少，甚至寧濫勿缺

一行代碼寫下去，或許你三天以內還能知道本身當初爲何這麼寫，裏面的變量表明什麼意思，有什麼做用，可是一個月後呢，半年後呢，一年後呢？就算你記得，其餘人呢？

我不知道這段代碼的做用是什麼，可是把它刪掉程序就不正常了

若是讓你維護一段你早就不記得是誰寫的，也不知道到底表明什麼意思代碼，你要作的第一件事確定就是先看代碼，弄明白到底什麼意思，而後才能進行後續維護，而對於某些較爲複雜的邏輯代碼，例如網站首頁，裏面嵌入了數十個彈窗，這數十個彈窗分別對應數十個功能點，讓你修改其中某個 A彈窗的彈出邏輯，而且還要與另外某個 B彈窗進行優先級配合，光是弄明白A、B彈窗的邏輯你都要花費很多時間吧？

而若是在這段代碼上面就有一行對這行代碼的準確註釋，就算你稍後仍是須要讀一遍代碼，也確定比沒有代碼時，你理解的更快更準確

一段代碼節約一點時間，那麼十段呢？一個文件的代碼呢？整個代碼庫的代碼量呢？

因此千萬不要以爲註釋無關緊要，仍是那句話，寧濫勿缺，寧願多寫點也不要少寫點，你寫的代碼都是給人讀的，反正如今基本上都接自動化打包編譯工具（例如 webpack），註釋這些東西最後在項目發佈階段都會自動刪掉，也不會佔用代碼體積

變量和方法的命名最好有必定的規律

一樣是爲了更好的閱讀體驗，也是爲了不過渡註釋（寧濫勿缺固然可行，可是少寫點無用的註釋總不會是壞事），最好的註釋就是讓代碼本身「說出」本身的做用，即命名要有規律性

例如，用於存儲數組的變量以 List做爲名字後綴，用於某種信息的對象變量以 Info做爲名字後綴，用於判斷某種邏輯的變量以 is最爲前綴，這樣一眼看上去就知道變量的大體功能，避免出現讓 object類型的對象調用 map的蠢事

const namesList = ['xiaoming', 'xiaohong']
const userInfo = {
  name: 'John',
  age: 20,
  gender: 'male'
}
const isEven = 10 % 2 === 0
複製代碼

方法的命名同上，另外，爲了更容易體現出方法的功能點，方法的名稱最好不要太「寬泛」，例如拉取數據的方法，最好不要命名爲相似 getData這種，由於若是這個組件中還存在其餘的拉取數據方法，就容易讓人迷惑，不會那麼一會兒就知道這個 getData究竟是針對哪一個數據接口的，應該進一步精確到相應的接口，例如命名爲 getUserData

關於如何給變量以及方法命名這件事，存在不少細緻的解決方案，能寫兩篇文章出來，就不一一展開了

通用的功能要封裝成組件

通用的組件，最好肯定好功能點後，封裝成統一的通用組件，通用組件必定要覆蓋大部分的通用功能點，不然還不如不要

大一點的，例如彈窗，可能包括標題、關閉按鈕、內容、遮罩層這些結構，小一點的，例如頁面的遮罩層，主體包括一層遮罩樣式,那在封裝這個組件的時候，就要把這些結構考慮進去

我曾經看到過某個組件中，包含了多個彈窗，可是沒有封裝通用的彈窗組件，因而相同的元素以及樣式被寫了好幾遍，印象最深入的是遮罩層元素也出現了好幾遍，每一個彈窗都專門寫一個遮罩層樣式，寫過的人都知道，單是這一個遮罩層的樣式都有好幾行了，何苦來哉

DRY原則

Don't repeat yourself

這一條能夠與上條結合使用，不管你是寫什麼代碼，需求是長期仍是短時間的，做爲一個有素質的程序猿，你最好都要遵照這條規則

這裏的 DRY，不只是指徹底如出一轍的代碼字母，還在於一樣的邏輯，這裏舉個例子，表單驗證是很常見的場景，通常的驗證方法都是不假思索的數個乃至是數十個 if語句依次排列，整整齊齊氣勢驚人，但問題是幾個 if語句連在一塊兒或許不太明顯，難以觸碰到你的 G點，可是十幾個乃至是幾十個 if語句堆在一塊兒，你難道還能不以爲彆扭嗎？

if (age > 19) {
  // ...
}
if (name.indexOf('zhao')) {
  // ...
}
if (gender === 1) {
  // ...
}
if (weight > 75) {
  // ...
}
// 無窮無盡
// ...
複製代碼

只要我複製粘貼得足夠快，bug就追不上我

關於表單驗證這個東西，有篇文章寫得很好，你們能夠參考一下

單獨的業務代碼之間、業務代碼與非業務代碼之間進行必要的隔離

業務代碼，以 if...else琳琅滿目爲主要標誌之一，多個需求的業務代碼混合在一塊兒那就意味着數倍琳琅滿目的 if...else，若是再在這些 if...else中躲貓貓般穿插進非業務代碼，那麼恭喜你，現在你獲得的這份代碼，其實有個流傳於江湖已久的響噹噹名號：意大利麪條式代碼

隔離單獨的業務代碼，可以直接減小頭髮掉落數，能間接下降 bug出現率，這很好理解

通常的項目都是長期迭代而來，一個頁面上可能堆積了數十個需求的功能點，每一個功能點都對應幾大段的方法和數據，而且這些需求還可能從誕生到如今被修改了數次，搞很差有的業務間還存在相互依賴與重疊

若是把這些業務包含的方法和數據全都放在一塊兒，那酸爽……誒，這個方法是屬於A需求的嗎？若是是那爲何這裏面還包含了B需求的數據？怎麼這裏還調用了C需求的方法？C需求的這個方法修改的這個數據是C需求的嗎？看起來不太像啊？算了算了，應該是，先這樣寫吧，等測試提 bug了再說……

下班晚不是由於你需求多，而是你本身寫得代碼給你找的事多

與位置無關的元素彙集書寫

若是頁面上元素少的話，或許沒有區別，可是當頁面上存在大量元素，例如網站首頁、商品詳情頁這些比較重要的頁面，就很容易感受出來了

像 modal彈窗、toast等輔助性元素，頁面上可能存在好多個，這種元素通常與位置無關，樣式設置的都是 position: asbolute或者 position: fixed;，不管放在哪一個位置基本上都 ok，那麼建議找好一個固定的位置彙集存放這些元素，例如頁面的頂部或者底部，並寫好註釋，方便尋找與修改，也方便統計，任意穿插在各類 DOM間，維護起來都是一件麻煩事

<!-- 新手好禮的引導彈窗 -->
<ModalA />
<!-- 領獎彈窗 -->
<ModalB />
<!-- 新人提示 -->
<ToastA />
<!-- 資質不夠提示 -->
<ToastB />
<!-- 風險用戶提示 -->
<ToastC />
複製代碼

刪掉沒必要要的代碼

包括無效代碼、註釋的代碼、沒必要要的調試代碼

作過活動頁的應該都知道，這種活動運營頁壽命通常都很短，可是所要付出的精力卻很多，活動下線後代碼可能就直接無效了，大部分狀況下這些失效的活動代碼不會對頁面有效邏輯產生什麼影響，因此趕着進入下一個需求的程序猿們，本着多一事不如少一事的原則，極可能就職由無效代碼一直存在於頁面，直到地老天荒，這種事情最起碼從個人經從來看，很常見

有的需求在開發階段頻繁變更，辛辛苦苦寫的邏輯還沒來得及被上傳到線上服務器就夭折了，惱羞成怒的程序猿不甘心掉落的頭髮連一點成果都沒有留下，因而機智地按下了 Ctrl + /快捷鍵，幻想着這段被封印的代碼總有重見天日的那天，卻不知，又是直到地老天荒，這種事情最起碼從個人經從來看，很常見

雖然某些自動化打包編譯工具支持刪除相似於 console.log、debugger之類的調試代碼，但問題是在 dev階段這些代碼都是存在的，每一個人在每一個需求中都加入 5個 console.log，那麼只須要十我的次，控制檯上就能夠出現 50行 console.log，特別是這些 console.log 基本上都是秉持着哪裏有位置就寫在哪裏的原則，就算是想刪也須要耗費大量時間，苦逼的程序猿什麼都沒幹，先在控制檯看到幾十行別人寫的 console.log，而後在一堆 console.log中找到本身須要的那個，並在需求完成時，順便又在原先幾十個 console.log的基礎上，又貢獻了本身的一份力量，這種事情最起碼從個人經從來看，很常見

編輯器每多顯示一行無效代碼、控制檯每多輸出一行 console.log，都將耗費必定的電量，全球幾千萬的程序員，聚沙成塔，足以加劇全球溫室效應，加速兩級冰川融化，可憐的北極熊寶寶和企鵝寶寶找不到爸爸媽媽，人間有真情人間有真愛，請堅決地按下 backspace 或 delete吧

良好的溝通，避免無效的產出

永遠不要相信 PM說的這個需求確定不會再變了的話

PM改變需求咱們沒法勸阻，可是咱們能夠明確現有的需求，不寫無效的代碼，從而進一步避免了大段註釋，保住了更多的頭髮，不要等到快上線的時候，才發現本身好像弄錯了某段邏輯，或者少寫了某段邏輯，最可恨的是白寫了某段邏輯

代碼容錯

這個世界上不存在沒有 Bug的代碼，只要你寫的不是 demo，那麼必定要作好代碼容錯處理，由於你永遠不知道接口給你返回的是 | 仍是 丨(親身經歷，此梗參見有哪些讓你目瞪口呆的 bug？)

還有一些可能不叫錯誤，例如頁面數據的初始化，在獲取到數據以前，頁面上可能會渲染出 undefined這種鬼東西，爲了更好的用戶體驗，最好仍是給個體驗更好的初始值吧

遵照制定好的規範

多人協做規範很重要，不管是 jshint 仍是eslint大行其道就是明證

，對於一個項目來講，規範可能包括從 es版本、縮進類型到頁面結構、組件拆分等，你既能夠直接照抄成熟的規範，也能夠自定義規範，但不管是什麼樣的規範，只要制定下來，那就要遵照，不要因我的緣由，與團隊貌合神離

有種效應叫破窗效應，這個項目中出現了不同的風格，後來進入的人第一印象就是規範也不是那麼嚴謹，偶爾打破一下也是能夠的，而後又有後來的人看到，第一印象就是……因而不一樣的風格越積越多，規範也就無從談起了，從一開始就穩不住，難道還想着半路忽然硬一下？

你能夠不喜歡項目如今的頁面結構劃分方式，也能夠認爲路由的劃分方式很SB，但既然你在當初制定這個規範時沒有反對沒有提出異議(不管是忘記了仍是被無視仍是沒有機會提，總之當初你沒反對)，那麼如今就要遵照，或者你也能夠嘗試着改變這個規範，但請作好善後事宜，例如確保在新規範制定後，項目中以前存在的老規範要被所有修改過來，堅定保證代碼風格統一化，至因而誰來作這種吃力不討好的事情，你懂得。