Frontend Development Process · Gitlab 中文文檔

# Frontend Development Process > 原文：[https://docs.gitlab.com/ee/development/fe_guide/development_process.html](https://docs.gitlab.com/ee/development/fe_guide/development_process.html) * [Development Checklist](#development-checklist) * [Merge Request Review](#merge-request-review) * [Share your work early](#share-your-work-early) * [Vue features](#vue-features) # Frontend Development Process[](#frontend-development-process "Permalink") 您可以在[手冊中](https://about.gitlab.com/handbook/engineering/frontend/)找到有關前端團隊組織的更多信息. ## Development Checklist[](#development-checklist "Permalink") 這個想法是在構建新功能或啟動某些東西時提醒我們有關特定主題的信息. 這是其他行業（如飛行員）的常見做法，這些行業也使用標準化清單來盡早減少問題. 將內容復制到您的問題或合并請求中，如果不適用，則將其從當前列表中刪除. 此清單旨在在開發更大的功能/重構時為我們提供幫助，而不是"始終使用它，并且每個點始終匹配"列表. 請在使用時做出最好的判斷，如果有想法請通過合并請求貢獻新的積分. ``` ### Frontend development #### Planning development - [ ] Check the current set weight of the issue, does it fit your estimate? - [ ] Are all [departments](https://about.gitlab.com/handbook/engineering/#engineering-teams) that are needed from your perspective already involved in the issue? (For example is UX missing?) - [ ] Is the specification complete? Are you missing decisions? How about error handling/defaults/edge cases? Take your time to understand the needed implementation and go through its flow. - [ ] Are all necessary UX specifications available that you will need in order to implement? Are there new UX components/patterns in the designs? Then contact the UI component team early on. How should error messages or validation be handled? - [ ] **Library usage** Use Vuex as soon as you have even a medium state to manage, use Vue router if you need to have different views internally and want to link from the outside. Check what libraries we already have for which occasions. - [ ] **Plan your implementation:** - [ ] **Architecture plan:** Create a plan aligned with GitLab's architecture, how you are going to do the implementation, for example Vue application setup and its components (through [onion skinning](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/35873#note_39994091)), Store structure and data flow, which existing Vue components can you reuse. It's a good idea to go through your plan with another engineer to refine it. - [ ] **Backend:** The best way is to kickoff the implementation in a call and discuss with the assigned Backend engineer what you will need from the backend and also when. Can you reuse existing API's? How is the performance with the planned architecture? Maybe create together a JSON mock object to already start with development. - [ ] **Communication:** It also makes sense to have for bigger features an own slack channel (normally called #f_{feature_name}) and even weekly demo calls with all people involved. - [ ] **Dependency Plan:** Are there big dependencies in the plan between you and others, then maybe create an execution diagram to show what is blocking which part and the order of the different parts. - [ ] **Task list:** Create a simple checklist of the subtasks that are needed for the implementation, also consider creating even sub issues. (for example show a comment, delete a comment, update a comment, etc.). This helps you and also everyone else following the implementation - [ ] **Keep it small** To make it easier for you and also all reviewers try to keep merge requests small and merge into a feature branch if needed. To accomplish that you need to plan that from the start. Different methods are: - [ ] **Skeleton based plan** Start with an MR that has the skeleton of the components with placeholder content. In following MRs you can fill the components with interactivity. This also makes it easier to spread out development on multiple people. - [ ] **Cookie Mode** Think about hiding the feature behind a cookie flag if the implementation is on top of existing features - [ ] **New route** Are you refactoring something big then you might consider adding a new route where you implement the new feature and when finished delete the current route and rename the new one. (for example 'merge_request' and 'new_merge_request') - [ ] **Setup** Is there any specific setup needed for your implementation (for example a kubernetes cluster)? Then let everyone know if it is not already mentioned where they can find documentation (if it doesn't exist - create it) - [ ] **Security** Are there any new security relevant implementations? Then please contact the security team for an app security review. If you are not sure ask our [domain expert](https://about.gitlab.com/handbook/engineering/frontend/#frontend-domain-experts) #### During development - [ ] Check off tasks on your created task list to keep everyone updated on the progress - [ ] [Share your work early with reviewers/maintainers](#share-your-work-early) - [ ] Share your work with UXer and Product Manager with Screenshots and/or [GIF's](https://about.gitlab.com/handbook/product/making-gifs/). They are easy to create for you and keep them up to date. - [ ] If you are blocked on something let everyone on the issue know through a comment. - [ ] Are you unable to work on this issue for a longer period of time, also let everyone know. - [ ] **Documentation** Update/add docs for the new feature, see `docs/`. Ping one of the documentation experts/reviewers #### Finishing development + Review - [ ] **Keep it in the scope** Try to focus on the actual scope and avoid a scope creep during review and keep new things to new issues. - [ ] **Performance** Have you checked performance? For example do the same thing with 500 comments instead of 1\. Document the tests and possible findings in the MR so a reviewer can directly see it. - [ ] Have you tested with a variety of our [supported browsers](../../install/requirements.md#supported-web-browsers)? You can use [browserstack](https://www.browserstack.com/) to be able to access a wide variety of browsers and operating systems. - [ ] Did you check the mobile view? - [ ] Check the built webpack bundle (For the report run `WEBPACK_REPORT=true gdk run`, then open `webpack-report/index.html`) if we have unnecessary bloat due to wrong references, including libraries multiple times, etc.. If you need help contact the webpack [domain expert](https://about.gitlab.com/handbook/engineering/frontend/#frontend-domain-experts) - [ ] **Tests** Not only greenfield tests - Test also all bad cases that come to your mind. - [ ] If you have multiple MR's then also smoke test against the final merge. - [ ] Are there any big changes on how and especially how frequently we use the API then let production know about it - [ ] Smoke test of the RC on dev., staging., canary deployments and .com - [ ] Follow up on issues that came out of the review. Create issues for discovered edge cases that should be covered in future iterations. ``` ### Merge Request Review[](#merge-request-review "Permalink") 為了[尊重他人的時間，](https://about.gitlab.com/handbook/values/#be-respectful-of-others-time)在進行審核[時，](https://about.gitlab.com/handbook/values/#be-respectful-of-others-time)請遵循以下準則： * 確保您的合并請求： * 里程碑已設定 * 至少設置了危險機器人建議的標簽 * 有清晰的描述 * 如果 UI 發生更改，則包括屏幕截圖之前/之后 * 管道是綠色的 * 包括測試 * 包括變更日志條目（必要時） * 在分配給維護者之前，請分配給審閱者. * 如果您分配了合并請求或直接對某人執行 ping 操作，請耐心等待，因為我們在不同時區且異步工作. 除非緊急合并請求（例如修復損壞的主服務器），否則請不要 DM 或重新分配合并請求，然后再等待 24 小時窗口. * 如果您對合并請求/問題有疑問，請在合并請求/問題中提出. 當我們彼此進行 DM 交流時，我們將不再擁有 SSOT，并且[其他人也無法做出貢獻](https://about.gitlab.com/handbook/values/#public-by-default) . * 如果您有一個包含許多更改的大型**Draft**合并請求，建議您在添加/刪除重要代碼之前開始審閱. 確保在發布截止日期之前就已對其進行了分配，因為審閱者/維護者將始終優先于**草稿中**優先審閱已完成的 MR. * 確保在上一輪審核之前刪除" `Draft:`標題. ### Share your work early[](#share-your-work-early "Permalink") 1. 在編寫代碼之前，請確保您對體系結構的了解與 GitLab 的體系結構保持一致. 2. Add a diagram to the issue and ask a frontend maintainer in the Slack channel `#frontend_maintainers` about it. [![Diagram of Issue Boards Architecture](https://img.kancloud.cn/50/fd/50fd74a12ea84beafcec88a103b3daf0_583x456.png)](img/boards_diagram.png) 3. 從開始一項功能到與審閱者或維護者共享"合并請求"之間的時間不要超過一周. ### Vue features[](#vue-features "Permalink") 1. 請遵循[Vue.js 最佳做法中](vue.html)的步驟 2. 遵循樣式指南. 3. 僅有少數幾個人可以合并 Vue 相關功能. 在此過程的早期，請一位 Vue 專家聯系.