როგორ იყო ორგანიზებული თქვენი გუნდის კოდის მიმოხილვის პროცესი?

ჩვენ ერთობლივი განვითარების პროცესში ვიყენებდით ვერსიების კონტროლის სისტემას Git და რეპოზიტორების მართვის პლატფორმას (მაგალითად, Bitbucket ან GitLab). კოდის მიმოხილვის პროცესი ორგანიზებული იყო შემდეგნაირად:

1. შაქის შექმნა: დეველოპერი ქმნის ცალკე შაქს ახალი ფუნქციის ან შეცდომის გამოსწორებისთვის (git checkout -b feature/my-new-feature).
2. განვითარება და კომიტები: შაქში ხორციელდება ცვლილებები, რომლებიც აღინიშნება კომიტებით (git add ., git commit -m "Initial feature implementation").
3. პუში დისტანციურ რეპოზიტორიაში: შაქი იგზავნება დისტანციურ რეპოზიტორიაში (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) და პროექტის შეკრება, რაც დაეხმარა შეცდომების ადრეულ გამოვლენაში.

საფერხებელი კრიტერიუმები მოიცავდა:

• დავალების მოთხოვნებთან შესაბამისობა.
• გუნდის კოდს სტილის დაცვა.
• კრიტიკულ ლოგიკაში ერთეულ ტესტების არსებობა.
• აშკარა შეცდომებისა და "კოსტილების" არარსებობა.
• კოდი უნდა იყოს სხვა გუნდის წევრებისთვის გასაგები.