前端專案
目前愛康雲的前端移動端的h5專案有7個，分別為
公共包引入方式
之前使用的是npm link，但npm link後本地package.json裡沒有記錄，無法直觀的檢視本地包的引用。
這裡採用npm install本地包的引用方式。指令如下：
npm install .
./ak-commonjs/
"dependencies"
:,
包依賴結構
除開第三方ui元件vant，計畫重構時建立五個公共包，其中公共元件包含了工具js，和業務無關的公共元件，登入模組，聊天包，患者公共包和醫生公共包。目的是乾掉重複**，不同產品線的相同功能不再複製貼上。
**規範
所有專案使用統一的eslint的標準配置作為基礎。
個性化配置寫在package.json中，暫定以下幾條。
"rules"
:
其他編碼規範：
不要編寫大段**，乙個函式內容太大，拆分成多個函式
重複**封裝成函式，函式留下可擴充套件的空間
重複元件提取到公共包中，元件的個性化配置暴露出來，元件留下可擴充套件空間
複雜程式邏輯，複雜業務邏輯，高階寫法，多級函式引用，請寫好注釋
另外，為避免大家**一鍵格式化後不一樣，在idea的setting裡下圖的do not indent children of處增加 script 和 style
css規範
定義與業務無關的公共css檔案
vue頁面和元件的樣式寫在當前頁面內
相同業務邏輯的頁面的樣式可以提取到css檔案內，放在當前目錄下
不同業務邏輯的頁面禁止相互引用css樣式檔案
css因不同頁面邏輯不同、改動頻繁，難復用，應遵循單獨使用，少繼承的原則
專案包結構規範
使用vue cli3建立專案，包目錄如下
公共包結構規範
公共包刪除一切無用的檔案和配置，精簡專案結構，其中components裡寫公共元件。tests存放單元測試檔案，必須完成公共元件需要單元測試。
package.json裡指定入口檔案為index.js
"main"
:"index.js"
,
import wevue from
'we-vue'
import vue from
'vue'
import playerpicker from
'./src/components/player/playerpicker'
vue.
use(wevue)
export
commit需寫好注釋，並標註是功能開發還是bug修復
開發階段（本周四到下周五）的commit需提交到dev和test兩個分支，先提交到dev，再切換到test，cherrypick當次提交
測試階段（下下周一到下下週三），可直接在test分支上修改bug，提交到test分支上，週三上線後，將test分支合併到dev分支
當前版本不上線的功能只能提交到dev分支，不需cherrypick到test分支上。
單元測試測什麼
首先乙個問題，單元測試需要測什麼？
以下引用自vue-test-utils官網
對於 ui 元件來說，我們不推薦一味追求行級覆蓋率，因為它會導致我們過分關注元件的內部實現細節，從而導致瑣碎的測試。也就是說我們需要測試的是輸入和輸出。根據不同的輸入得到不同的輸出，看是否滿足預期結果。盡可能覆蓋所有不同的輸入情況，但不需要去關注元件的內部實現細節。那麼該測試什麼的輸入和輸出呢？取而代之的是，我們推薦把測試撰寫為斷言你的元件的公共介面，並在乙個黑盒內部處理它。乙個簡單的測試用例將會斷言一些輸入 (使用者的互動或
prop 的改變) 提供給某元件之後是否導致預期結果 (渲染結果或觸發自定義事件)。
公共元件，在component資料夾中的所有
有複雜邏輯js函式，工具類等
單元測試規範
待補充新專案cli
搭建好建立新專案的模板，一鍵建立立即可用的新專案。
待補充
專案中最實用的前端開發規範
前端的開發規範其實不需要定的太細，掌握好原則即可，依據這些原則，再去根據專案制定具體的要求，就可形成相關文件。比如，定好主題顏色後即可根據主題確定具體的顏色 字型 邊框 邊距 圖示等。根據之前做過的專案，我總結了20條原則，作為後期前端開發規範，無法面面俱到，僅供參考。1 必須使用構建工具，堅持前後...
微信小程式開發規範文件 專案結構
專案結構 project 根目錄 images 小圖示 pages pages目錄 utils 工具，包檔案目錄 project.config.json 專案的編輯器配置頁面目錄 1.由歷史原因和個人習慣導致目錄命名不統一，語義不清晰，不同成員在維護時難以快速識別。示例 錯誤的寫法 pages ab...
IOS專案目錄結構和開發流程
的部落格網上相關的資源不多，開源的且質量還不錯的ios專案也是少之又少，最近正好跟同事合作了乙個ios專案，來說說自己的一些想法。目錄結構 models macro general helpers vendors sections resources 乙個合理的目錄結構首先應該是清晰的，讓人一眼看上...