技術(shù)棧
- 平臺(tái)： Node.js（v8.9.3）
- 框架：Express（v4.16.0）
- 數(shù)據(jù)庫(kù)：MongoDB（v3.4.14）
開發(fā)環(huán)境
Node與MongoDB的下載與安裝，請(qǐng)自行百度或谷歌，遍地都是只锭，不再贅述九巡。
相關(guān)規(guī)范
相關(guān)規(guī)范主要包括代碼規(guī)范、Git commit規(guī)范和API接口文檔規(guī)范邑狸。
代碼規(guī)范
代碼規(guī)范采用JavaScript Standard Style,以下簡(jiǎn)稱standard規(guī)范巧骚。至于為什么使用這個(gè)代碼規(guī)范，沒有什么特殊原因侣监，這是我使用過的第一個(gè)代碼規(guī)范，是我規(guī)范自己代碼的開始臣淤，習(xí)慣而已橄霉，并且github上的start數(shù)也不算少。standard規(guī)范相比較ESLint而言邑蒋，最舒服的一點(diǎn)就是不用配置姓蜂，對(duì)我影響最大的一點(diǎn)是代碼中再也沒有出現(xiàn)分號(hào)，并且強(qiáng)迫癥再也受不了代碼中有分號(hào)【捂臉】医吊，以至于后來使用ESLint時(shí)钱慢，也要配置為可以不寫分號(hào)【再次捂臉】。
通過代碼規(guī)范卿堂，可以在編程過程中避免一些低級(jí)錯(cuò)誤束莫，比如使用未定義的變量等，同時(shí)可以規(guī)范自己的代碼書寫風(fēng)格草描，有了規(guī)范代碼的習(xí)慣览绿，寫出來的代碼賞心悅目，看著也舒服很多穗慕，一定程度上增加了代碼的可讀性饿敲，工作效率的提升也是必然的事情。
我聽說過逛绵，有的團(tuán)隊(duì)的代碼規(guī)范及其嚴(yán)格怀各，比如一行代碼最大字符長(zhǎng)度不能超過120甚至80，每個(gè)函數(shù)的代碼行數(shù)不能超過50行等术浪，存在必有意義吧瓢对，起初沒必要對(duì)自己這么嚴(yán)格，但是代碼規(guī)范還是要重視起來的添吗。
工具配合
我使用的編輯器是VS Code,可以安裝StandardJS插件沥曹，非常方便。
同時(shí)可以配合一個(gè)npm的庫(kù)包pre-commit進(jìn)行代碼規(guī)范，因?yàn)椴灰?guī)范的代碼是不會(huì)影響程序的正常運(yùn)行的妓美，但我們使用代碼規(guī)范的目的就是希望提交到代碼倉(cāng)庫(kù)的代碼都是規(guī)范的僵腺，pre-commit的作用就是在進(jìn)行commit操作時(shí)檢測(cè)所有代碼是否符合standard規(guī)范，如果不符合則不允許提交代碼壶栋。
相關(guān)參考
在standard規(guī)范的文檔中辰如，有關(guān)于規(guī)范的細(xì)則和使用過程中可能出現(xiàn)的問題。
Git commit規(guī)范
我們進(jìn)行commit操作時(shí)贵试，填寫的相關(guān)說明一定是要有意義的琉兜，我記得在學(xué)習(xí)編程的最開始，我們的對(duì)git的命令以及操作規(guī)范不清楚毙玻，所以commit的信息亂七八糟豌蟋，經(jīng)常是“解決沖突”、“修改bug”這樣的說明桑滩，在被批評(píng)之后梧疲，也僅僅是commit信息不再胡寫。
項(xiàng)目的commit message規(guī)范使用的是主流的Angular規(guī)范运准，在實(shí)際的團(tuán)隊(duì)開發(fā)中幌氮，通過對(duì)commit日志的規(guī)范，有助于代碼的review
胁澳、日志的自動(dòng)化生成以及項(xiàng)目發(fā)版该互，同時(shí)能夠很好地熟悉git工作流。在該項(xiàng)目中不涉及發(fā)版韭畸，只是簡(jiǎn)單的開發(fā)宇智，所以只是遵循了部分規(guī)范，在實(shí)際工作中陆盘，如果團(tuán)隊(duì)剛好涉及到git工作流的規(guī)范普筹，那肯定是要遵循的败明。
Git commit日志基本規(guī)范
基礎(chǔ)語(yǔ)法模板
<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
規(guī)范的基本說明：
type代表本次提交的類型隘马，是新增feature還是修復(fù)bug或是修改文檔等，主要類型及其說明如下：
- feat：新增feature
- fix: 修復(fù)bug
- docs: 僅僅修改了文檔妻顶，比如README, CHANGELOG, CONTRIBUTE等等
- style: 僅僅修改了空格酸员、格式縮進(jìn)、都好等等讳嘱，不改變代碼邏輯
- refactor: 代碼重構(gòu)幔嗦，沒有加新功能或者修復(fù)bug
- perf: 優(yōu)化相關(guān)，比如提升性能沥潭、體驗(yàn)
- test: 測(cè)試用例邀泉，包括單元測(cè)試、集成測(cè)試等
- chore: 改變構(gòu)建流程、或者增加依賴庫(kù)汇恤、工具等
- revert: 回滾到上一個(gè)版本
scope表明本次修改的范圍或者模塊庞钢，例如users。
subject是對(duì)變更內(nèi)容的簡(jiǎn)要描述因谎。
BLANK LINE不用說，就是字面意思的空白行。
body是對(duì)本次變更更加詳細(xì)的說明斑匪，可以是發(fā)起本次變更的原因以及本次變更的解決思路和方法等龟虎。
footer處填寫相關(guān)連接。
格式要求：
# 標(biāo)題行：50個(gè)字符以內(nèi)匠璧，描述主要變更內(nèi)容
# （我是空行）
# 主體內(nèi)容：更詳細(xì)的說明文本桐款，建議72個(gè)字符以內(nèi)。 需要描述的信息包括:
# （我是空行）
# * 為什么這個(gè)變更是必須的? 它可能是用來修復(fù)一個(gè)bug夷恍，增加一個(gè)feature鲁僚，提升性能、可靠性裁厅、穩(wěn)定性等等
# * 他如何解決這個(gè)問題? 具體描述解決問題的步驟
# * 是否存在副作用冰沙、風(fēng)險(xiǎn)?
#
# 尾部：如果需要的話可以添加一個(gè)鏈接到issue地址或者其它文檔，或者關(guān)閉某個(gè)issue执虹。
相關(guān)參考
API接口文檔規(guī)范
我寫過的第一個(gè)接口文檔拓挥，是word形式的，寫了大概三個(gè)接口就受不了了袋励，word寫接口侥啤，太不舒服了，后來用showdoc工具寫接口文檔茬故，好用了很多盖灸，但是沒有很好地體現(xiàn)文檔的維護(hù)記錄，再后來磺芭，參加工作之后接觸了解了apidoc赁炎，相對(duì)而言，它也算主流之一钾腺，使用簡(jiǎn)單并且支持多語(yǔ)言徙垫，所以就開始使用apidoc作為生成接口文檔的工具，接口文檔在代碼中以注解的形式書寫放棒，然后通過apidoc的相關(guān)命令生成接口文檔姻报，配合git剛好可以很好地體現(xiàn)接口文檔的維護(hù)記錄。當(dāng)然间螟，還有其他選擇吴旋，個(gè)人喜好而已损肛。
apidoc編寫接口示例
代碼實(shí)例：
/**
* @api {POST} /user create a user
* @apiDescription 用戶新增的接口
* @apiName 用戶注冊(cè)
* @apiGroup User
* @apiUse userParams
* @apiSuccessExample Success-Response:
* {
* errorCode: 0,
* status: 200,
* data: {
* _id: '123',
* name: 'morehao',
* createdAt: '20180913',
* updatedAt: '20180913',
* lastLogin: '暫未登錄'
* }
* }
* @apiErrorExample {json} Error-Response:
* {
* status: 200,
* errorCode: 20100,
* errorMsg: '該用戶已經(jīng)存在'
* }
*/
截圖實(shí)例：
相關(guān)參考
這里只確定API接口文檔的生成方式，詳細(xì)的使用后面也不會(huì)過多涉及荣瑟，下面附上相關(guān)鏈接荧关。
下面附上項(xiàng)目的github地址：
我的個(gè)人博客：
