Ինչպես էր կազմակերպված ձեր թիմում կոդի վերանայման գործընթացը։

Մենք օգտագործել ենք համատեղ զարգացման գործընթաց՝ օգտագործելով Git տարբերակների կառավարման համակարգը և ռեպոզիտորների կառավարման հարթակը (օրինակ՝ Bitbucket կամ GitLab): Կոդի վերանայման գործընթացը կազմակերպվել է հետևյալ կերպ՝

1. Արխիվի ստեղծում: Զարգացնողը ստեղծում է առանձին ճյուղ՝ նոր ֆունկցիայի կամ սխալի շտկման համար (git checkout -b feature/my-new-feature).
2. Զարգացում և հանձնարարականներ: Ճյուղում կատարվում են փոփոխություններ, որոնք նշվում են հանձնարարականներով (git add ., git commit -m "Initial feature implementation").
3. Push դեպի հեռավոր ռեպոզիտորիա: Ճյուղը ուղարկվում է հեռավոր ռեպոզիտորիա (git push origin feature/my-new-feature).
4. Pull/Merge խնդրանքի ստեղծում: Զարգացնողը ստեղծում է Pull Request (Bitbucket-ում) կամ Merge Request (GitLab-ում), նշելով նպատակային ճյուղը (օրինակ՝ develop կամ main). Բացատրությունում նշվում է փոփոխությունների կարճ նկարագրությունը, խնդիրների հղումները տրեքերիում (Jira, Trello և այլն) և կցված ֆայլերը (սքրինշոթեր, տեսանյութեր, դիագրամներ):
5. Վերանայողների նշանակում: Մի կամ երկու զարգացնողներ նշանակվում են վերանայելու համար:
6. Վերանայման գործընթաց: Վերանայողները դիտում են փոփոխությունները Pull/Merge խնդրանքում: Նրանք կարող են թողնել մեկնաբանություններ, առաջարկել բարելավումներ, տալ հարցեր:

   // Օրինակ մեկնաբանություն վերանայման ժամանակ
   function fetchData() {
     // Հնարավոր է՝ անհրաժեշտ է ավելացնել սխալների մշակումը տվյալների հարցում
     return fetch('/api/data');
   }
   

7. Փոփոխությունների կատարում վերանայման արդյունքներով: Զարգացնողը կատարում է անհրաժեշտ փոփոխությունները իր ճյուղում և նոր հանձնարարականներ ստեղծում:
8. Pull/Merge խնդրանքի թարմացում: Փոփոխությունները ավտոմատ կերպով ցուցադրվում են Pull/Merge խնդրում՝ հեռավոր ռեպոզիտորիա ուղարկելուց հետո:
9. Կրկնակի վերանայում: Վերանայողները կրկին դիտում են փոփոխությունները և տալիս հաստատում:
10. Ցանցի միացում: Հետո, երբ հաստատում է ստանում, ճյուղը միացվում է նպատակային ճյուղին (հաճախ ավտոմատ՝ հարթակի միջոցով՝ CI/CD պլանանց անցնելուց հետո):

Մենք նաև օգտագործել ենք CI/CD պլան՝ ավտոմատ կերպով գործարկելու միավորական թեստեր, կոդի վիճակագրական վերլուծություն (ESLint, Prettier) և նախագծի հավաքում՝ միացման նախորդ, ինչը օգնում էր վաղ փուլում հայտնաբերել սխալները:

Հաջողության համար վերանայման անցնելու համար պահանջվում էր՝

• Պահպանել խնդիրների պահանջներին համապատասխանությունը
• Պահպանել թիմի կոդային ոճը
• Կոնկրետ կարևոր լոգիկայի համար ունենալ միավորական թեստեր
• Չլինել ակնհայտ սխալներ և "կոճակներ"
• Կոդը պետք է լինի հասկանալի մյուս թիմակիցների համար։