我對開發流程及規範的一些見解

• 2020 年 3 月 9 日
• 筆記

前後台搭配的問題

作為前端，你應該經常會像後台要介面，沒有後台提供的介面就沒有數據，後面的一切都免談，那麼，介面從何而來：

1. 是人肉問
2. 是靠文檔

我個人偏向於是靠文檔，因為文檔是會沉澱一些東西下來的，一個需求下來，肯定會沉澱不少的介面，作用是幹嘛的，需要哪些參數，返回內容是什麼，錯誤碼有哪些，對應的錯誤消息時什麼。後續有其他需求要用到上個需求的某個介面時，一目了然，省去了不少溝通成本。

反觀，人肉問這種方式，時間久了，大家也不記得了，影響開發效率，而且後台同學每次解釋一次，也很煩吧。而且，如果沒有文檔這種規範的化，A需求傳的是參數x，B需求傳的是參數y，新同學接手，或者你自己讀程式碼，都不知道x，y的意義。

所以，對比一下兩種方式的差距：

那麼，有沒有很好的文檔管理平台呢？答案是有的 GitHub – YMFE/yapi: YApi 是一個可本地部署的、打通前後端及QA的、可視化的介面管理平台

看來這些前輩們應該是很早就經歷過這樣的痛苦，才有了這麼一個工具，這個工具非常強大，不僅僅只有介面文檔管理的功能，還有：

1. mock數據
2. 可視化

這是個工具，也可以說是一個服務，團隊可以自己搭建一個這樣的服務，那麼，具體怎麼玩，就請大家自己了解一下了，一旦文檔規範了，想想效率是有多大的提升。

同樣的道理，我覺得視覺管理也應該有一個規範；

這裡我就直接案例這個工具了：藍湖　- 高效的產品設計協作平台

討論程式碼規範的問題

通常，我們不是一個人在完成一個項目，有合作嘛，有合作的地方就有江湖，有人喜歡縮進使用2個空格，而有人喜歡4個，有人if後面跟一個語句的時候不喜歡{}，有人…

是的，這時候，應該考慮使用工具了規範化這個問題。

拿一個vue項目為例，通常，創建一個項目的化，加入eslint。

如果你做過web開發，還不了解eslint，建議你趕緊去學一下，先學先致富，早日擺脫痛苦。

因為引入eslint之後，程式碼不規範，編譯就過不了了，這樣就強制要求了大家寫程式碼都按照規範來。

但是這樣做，是不是會引起部分人極度不適呢？嗯，所以有些小夥伴在IDE中會關閉檢查，我還是按照我的方式寫，只是提交的時候，我們可以做一個commit hook，在提交之前給他lint一下，在才提交。

這個hook我就直接安利一個了：GitHub – okonet/lint-staged: ?? — Run linters on git staged files

簡介非常有意思，別人shit污染了你的程式碼，當你git staged的時候觸發自動修復，修復後才可以提交你的修復，如果沒修復，不好意思，提交不了，你自己修復之後提交，你可以從這個描述中體會一些這個工具的作者曾經應該是經歷過什麼了。

最佳的 lint 規範流程就是推薦團隊成員先在自己的編輯器中配置 eslint，在 webpack 中配置並開啟 eslint-loader 錯誤提示，這樣平時寫的時候編輯器就能幫你修正一些簡單的格式錯誤，同時提醒你有哪些不符合 lint 規範的的地方，並在命令行中提示你錯誤。這方面詳細的內容見 ESLint。 > > 但這並不是強制的，有些團隊成員或者說剛來的實習生沒有在編輯器中配置或者無視命令行中提示的錯誤，這時候就需要配置pre-commit 這種強制性校驗的東西，保證所有提交到遠程倉庫的內容都是符合團隊規範的