# კოდის რევიუები {#code-reviews}

პულ-რეკვესტების რევიუ წვლილის შეტანის გავრცელებული ფორმაა. მიუხედავად იმისა, რომ უწყვეტი ინტეგრაცია (CI) უზრუნველყოფს კოდის მოსალოდნელ ქცევას, ეს საკმარისი არ არის. არსებობს წვლილის ისეთი ასპექტები, რომელთა ავტომატიზება შეუძლებელია: დიზაინი, კოდის სტრუქტურა და არქიტექტურა, ტესტების ხარისხი ან ბეჭდვითი შეცდომები. შემდეგი განყოფილებები აღწერენ კოდის რევიუს პროცესის სხვადასხვა ასპექტს.

## წაკითხვადობა {#readability}

გამოსახავს თუ არა კოდი თავის განზრახვას ცალსახად? **თუ კოდის დანიშნულების გაგებაზე ბევრი დროის ხარჯვა გიწევთ, კოდის იმპლემენტაცია უნდა გაუმჯობესდეს.** შესთავაზეთ კოდის დაყოფა უფრო მცირე აბსტრაქციებად, რომლებიც უფრო ადვილად გასაგებია. ალტერნატივის სახით, როგორც უკიდურესი ზომა, შესაძლებელია კომენტარის დამატება, რომელიც ხსნის გადაწყვეტილების ლოგიკას. დაუსვით საკუთარ თავს კითხვა: შეძლებდით თუ არა ამ კოდის გაგებას მომავალში, პულ-რეკვესტის აღწერილობის ან სხვა კონტექსტის გარეშე.

## მცირე პულ-რეკვესტები {#small-pull-requests}

დიდი პულ-რეკვესტების რევიუ რთულია და დეტალების გამოტოვების ალბათობა მაღალია. თუ პულ-რეკვესტი ზედმეტად დიდი და სამართავად რთული ხდება, შესთავაზეთ ავტორს მისი ნაწილებად დაყოფა.

> [!NOTE]
> **გამონაკლისები**
>
> არსებობს მცირე რაოდენობის სცენარი, სადაც პულ-რეკვესტის დაყოფა შეუძლებელია, მაგალითად, როცა ცვლილებები მჭიდროდ არის დაკავშირებული და მათი განცალკევება ვერ ხერხდება. ასეთ შემთხვევებში ავტორმა უნდა წარმოადგინოს ცვლილებების ნათელი ახსნა და მათი ლოგიკა.


## თანმიმდევრულობა {#consistency}

მნიშვნელოვანია, რომ ცვლილებები თანმიმდევრული იყოს პროექტის დანარჩენ ნაწილთან. შეუსაბამობა ართულებს მხარდაჭერას, ამიტომ მათი თავიდან აცილება უნდა მოვახდინოთ. თუ არსებობს მომხმარებლისთვის შეტყობინებების გამოტანის ან შეცდომების რეპორტირების მიდგომა, მას უნდა მივყვეთ. თუ ავტორი არ ეთანხმება პროექტის სტანდარტებს, შესთავაზეთ მას საკითხის (issue) გახსნა, სადაც შევძლებთ მათ დეტალურ განხილვას.

## ტესტები {#tests}

ტესტები საშუალებას გვაძლევს კოდის ცვლილება ნდობით მოვახდინოთ. პულ-რეკვესტებში წარმოდგენილი კოდი უნდა იყოს დატესტილი და ყველა ტესტი უნდა გადიოდეს. კარგი ტესტი არის ის, რომელიც თანმიმდევრულად ერთსა და იმავე შედეგს იძლევა და რომლის გაგება და მხარდაჭერაც ადვილია. რევიუერები რევიუს დროის უმეტეს ნაწილს იმპლემენტაციის კოდზე ხარჯავენ, მაგრამ ტესტებიც ისეთივე მნიშვნელოვანია, რადგან ისინიც კოდია.

## დამრღვევი ცვლილებები {#breaking-changes}

დამრღვევი ცვლილებები Tuist-ის მომხმარებლებისთვის ცუდ გამოცდილებას ქმნის. წვლილმა უნდა აიცილოს დამრღვევი ცვლილებების შემოტანა, თუ ეს აუცილებელი არ არის. არსებობს ენის მრავალი ფუნქცია, რომლის გამოყენებითაც შეგვიძლია Tuist-ის ინტერფეისის განვითარება დამრღვევი ცვლილებების გარეშე. ყოველთვის ცალსახა არ არის, არის თუ არა ცვლილება დამრღვევი. ცვლილების დამრღვევობის შესამოწმებელი მეთოდია Tuist-ის გაშვება fixtures დირექტორიაში არსებული სატესტო პროექტებზე. ეს მოითხოვს საკუთარი თავის მომხმარებლის ადგილას ჩაყენებას და იმის წარმოდგენას, თუ როგორ იმოქმედებენ ცვლილებები მათზე.