小公司的前端建設的一些思考 小公司的前端建設的一些思考
小公司的前端建設的一些思考
在之前的企業專案開發中，做過一些前端基礎建設和專案推進的工作。
完成專案之後，一直沒時間整理和反思在推進過程中，遇到的問題以及解決方案，由於前端團隊人員較少，更多的是多人協作以及大家共同攻克一些問題。
工具
前端的編輯器，包括sublime，還有vscode，以及webstorm、atom這類編輯器，發展到現在，vscode成為了目前前端開發的主流編輯器
在團隊開發過程中，針對一些固定的外掛，需要實現規範和統一。
包括：
tab縮排的大小，以及格式化的外掛，例如在vue開發過程中，推薦使用Vetur進行格式化和程式碼約束，包括程式碼檢查eslint這些工具。
除了統一使用的外掛作為規範以外，其他的外掛作為個人愛好和習慣使用即可。
專案結構目錄
資料夾劃分
以vue開發為例：介面api，路由router，狀態管理store，元件compoment、工具類utils，建議統一劃分到各自的資料夾，明確資料夾的功能，檔案命名規範可以參照：vue官方文件-風格指南
資料夾命名可以根據習慣，最重要的是要明確劃分功能，確保在開發過程中造成目錄混亂
程式碼編寫
javascript
- 常量大寫，規範使用let和const等命令, 變數和方法使用 駝峰or下劃線進行命名，
- 工具類utils和依賴包方法，例如：時間格式化YYYY-MM-DD，統一使用utils中的格式化方法
- 深拷貝或者節流防抖等方法，根據專案場景封裝或者使用lodash，進行統一，混合使用容易增加開發成本。
html&&css
類名使用駝峰或者以 - 作為連線，書寫順序建議以參考騰訊css書寫規範
git
- 預設一條主分支，這個應該是大家在程式碼維護過程中的共識了
- 在專案完成第一次上線之後，建議增加一條fix分支作為生產環境bug維護的分支
- 開發過程中，dev分支的提交，提交資訊應該詳細且最好是按照提交的型別，是否是fix還是update程式碼
協作開發
在開發過程中，專案的進度和週期情況都不太一樣，同時有些前端開發人員可能是剛進入專案，也有些在專案中呆了比較久，能力也會有所差別，在開發和分配任務時，就需要根據不同的情況進行分配任務。
需要考慮的問題
- 是否根據個人能力的強弱，分配任務的時候，注重培養還是按照個人擅長的領域去處理擅長的問題。
- 業務元件和公共元件的編寫，是根據分配任務的模組劃分還是由某個同學單獨去完成
- 更多問題。。。
文件以及註釋
- 專案的readme.md建議儘可能地完善，不僅僅侷限於 安裝npm依賴和啟動，更應該包含上面所提到：外掛規範、一些重要的依賴項、node版本等
- 程式碼註釋建議保持良好的習慣，包括程式碼塊註釋，業務邏輯註釋，實現痛點等
前端負責人
- 作為前端的負責人，需要結合業務需求，做更好的技術選型，對於現有的工具有一定的瞭解和知識廣度
- 良好的編碼基礎支援作為支撐，熟悉前端專案架構，具備前端開發的技能，面對業務開發能夠熟練於心，對演算法有一定的能力和理解，對前端領域的技術更新和資訊有良好的敏感度
- 具有一定的管理能力，保持團隊的活力，提升整個團隊的戰鬥能力，建議可以開展一些技術分享或者討論，引導前端團隊的成員去攻克一些難題，善於發現他們的閃光點。
- 不管是針對前端成員還是其他同事或者上級，擁有良好的溝通和理解能力，快速定位問題，進行有效溝通。
寫在最後
以上就是關於小公司前端團隊建設的一些思考，2022年的前端，希望各位前端開發的同學，都能找到屬於自己的一片天地。
文章個人部落格地址：小公司的前端建設的一些思考
創作不易，轉載請註明出處和作者。
在之前的企業專案開發中，做過一些前端基礎建設和專案推進的工作。
完成專案之後，一直沒時間整理和反思在推進過程中，遇到的問題以及解決方案，由於前端團隊人員較少，更多的是多人協作以及大家共同攻克一些問題。
工具
前端的編輯器，包括sublime，還有vscode，以及webstorm、atom這類編輯器，發展到現在，vscode成為了目前前端開發的主流編輯器
在團隊開發過程中，針對一些固定的外掛，需要實現規範和統一。
包括：
tab縮排的大小，以及格式化的外掛，例如在vue開發過程中，推薦使用Vetur進行格式化和程式碼約束，包括程式碼檢查eslint這些工具。
除了統一使用的外掛作為規範以外，其他的外掛作為個人愛好和習慣使用即可。
專案結構目錄
資料夾劃分
以vue開發為例：介面api，路由router，狀態管理store，元件compoment、工具類utils，建議統一劃分到各自的資料夾，明確資料夾的功能，檔案命名規範可以參照：vue官方文件-風格指南
資料夾命名可以根據習慣，最重要的是要明確劃分功能，確保在開發過程中造成目錄混亂
程式碼編寫
javascript
- 常量大寫，規範使用let和const等命令, 變數和方法使用 駝峰or下劃線進行命名，
- 工具類utils和依賴包方法，例如：時間格式化YYYY-MM-DD，統一使用utils中的格式化方法
- 深拷貝或者節流防抖等方法，根據專案場景封裝或者使用lodash，進行統一，混合使用容易增加開發成本。
html&&css
類名使用駝峰或者以 - 作為連線，書寫順序建議以參考騰訊css書寫規範
git
- 預設一條主分支，這個應該是大家在程式碼維護過程中的共識了
- 在專案完成第一次上線之後，建議增加一條fix分支作為生產環境bug維護的分支
- 開發過程中，dev分支的提交，提交資訊應該詳細且最好是按照提交的型別，是否是fix還是update程式碼
協作開發
在開發過程中，專案的進度和週期情況都不太一樣，同時有些前端開發人員可能是剛進入專案，也有些在專案中呆了比較久，能力也會有所差別，在開發和分配任務時，就需要根據不同的情況進行分配任務。
需要考慮的問題
- 是否根據個人能力的強弱，分配任務的時候，注重培養還是按照個人擅長的領域去處理擅長的問題。
- 業務元件和公共元件的編寫，是根據分配任務的模組劃分還是由某個同學單獨去完成
- 更多問題。。。
文件以及註釋
- 專案的readme.md建議儘可能地完善，不僅僅侷限於 安裝npm依賴和啟動，更應該包含上面所提到：外掛規範、一些重要的依賴項、node版本等
- 程式碼註釋建議保持良好的習慣，包括程式碼塊註釋，業務邏輯註釋，實現痛點等
前端負責人
- 作為前端的負責人，需要結合業務需求，做更好的技術選型，對於現有的工具有一定的瞭解和知識廣度
- 良好的編碼基礎支援作為支撐，熟悉前端專案架構，具備前端開發的技能，面對業務開發能夠熟練於心，對演算法有一定的能力和理解，對前端領域的技術更新和資訊有良好的敏感度
- 具有一定的管理能力，保持團隊的活力，提升整個團隊的戰鬥能力，建議可以開展一些技術分享或者討論，引導前端團隊的成員去攻克一些難題，善於發現他們的閃光點。
- 不管是針對前端成員還是其他同事或者上級，擁有良好的溝通和理解能力，快速定位問題，進行有效溝通。
寫在最後
以上就是關於小公司前端團隊建設的一些思考，2022年的前端，希望各位前端開發的同學，都能找到屬於自己的一片天地。
文章個人部落格地址：小公司的前端建設的一些思考
創作不易，轉載請註明出處和作者。