C++ მძლავრი, მოთხოვნადი და ამავე დროს უაღრესად რთული ენაა, ეს უკიდეგანო სირთულე კი უკიდურესად დაუცველს ხდის არასწორი ინტერპრეტაციისა და ზედმეტი გართულების მიმართ. დაუსრულებელი მუშაობის შემდეგ ადვილია გამოგრჩეთ შეცდომები C++-ში, რომლებიც მარტივად პოვნადი იქნებოდა უფრო მარტივ ენებში.
მოკლედ, C++-ს სიფრთხილე და არწივის თვალით დაკვირვება სჭირდება.
ერთ-ერთი უმნიშვნელოვანესი ეტაპია თქვენი დაწერილი კოდის ორჯერ შემოწმება ან სხვა კოდერის დახმარება გადამოწმებაში, რომელიც არ უნდა გამოგრჩეთ კოდის წერის დროს.
რატომ არის C++ კოდის გადახედვა ასეთი მნიშვნელოვანი?
არ აქვს მნიშვნელობა რომელ ენას იყენებთ კოდის საწერად, ყოველთვის ძნელია საკუთარ კოდში შეცდომის დანახვა, ან იმიტომ, რომ თავიდანვე დაწერეთ ეს კოდი, ან იმიტომ, რომ უბრალოდ არ იცით, რომ რასაც აკეთებთ, შესაძლოა არასწორი იყოს. ამ საკითხის გადასაჭრელად კარგი გზაა ვინმეს გადაახედოთ ხოლმე თქვენს კოდი.
გარდა ამისა, კოდის უბრალოდ განხილვა ორ ან მეტ ადამიანს შორის ბადებს ახალ კითხვებს და გვეხმარება მნიშვნელოვანი საკითხების განსაზღვრაში.
ზემოაღნიშნული აუცილებელია ნებისმიერი პროგრამირების ენისთვის, რომელსაც იყენებთ, მაგრამ C++-ის სირთულე კიდევ უფრო კრიტიკულს ხდის მას, რაც მოითხოვს მინიმუმ ერთი სხვა ადამიანის თვალებს.
რა უძღვის წინ კოდის გადახედვას?
არსებობს ორი რამ, რაც გჭირდებათ თქვენი კოდის გადახედვაზე გაგზავნამდე.
პირველი არის სტატიკური კოდის ანალიზის გავლა და შესაძლებლობა, ახსნათ ნებისმიერი გაფრთხილება, რომელიც შეიძლება იყოს ცრუ დადებითი. არსებობს შესანიშნავი ინსტრუმენტები სტატიკური კოდის ანალიზისთვის – როგორც ღია წყაროს, ასევე კომერციული – და არ არსებობს მიზეზი, რომ არ უნდა გამოიყენოთ ისინი. რა თქმა უნდა, ჩვენ ვვარაუდობთ, რომ თქვენ უყურადღებოდ არ დატოვებთ კომპილატორის შესახებ გაფრთხილებებს, მაგრამ იშვიათ შემთხვევებში, როდესაც ნამდვილად გაქვთ კარგი მიზეზი, რომ უგულებელყოთ კომპილატორის გაფრთხილება, ამისთვის, რა თქმა უნდა, წინასწარ უნდა მომზადდეს კარგი ახსნა (მაგ., როგორც კომენტარი პრაგმა დეკლარაციის ზემოთ, რომელიც ავალებს კომპილატორს უგულებელყოს გაფრთხილება).
მეორე რაც გჭირდებათ არის თქვენი კოდის რეალურად დატესტვა. თქვენ უნდა გაუშვათ ერთეულის ტესტები, რომლებიც წარმოქმნის თქვენი კოდის საკმარის დაფარვას, სასურველია შეცდომებისა და ზღვრული შემთხვევების ჩათვლით. ტესტირების გარეშე აზრი არ აქვს კოდის გადახედვის ჩატარებას, რადგან ვერ შეგეძლებათ თქვათ, რეალურად მუშაობს თუ არა თქვენი კოდი. უფრო მეტიც, კოდის განხილვისას განსახილველი ერთ-ერთი ელემენტია ტესტები. თუ თქვენ დაამატებთ ტესტებს კოდის გადახედვის შემდეგ, დარწმუნდით, რომ კოდში განხორციელებული ცვლილებები, ტესტის წარუმატებლობის შემდეგ, ვერ დაემალება კოდის გადახედვას.
როგორც სტატიკური კოდის ანალიზმა, ასევე კარგი ერთეულის ტესტებმა შეიძლება შეამცირონ პრობლემები კოდის გადახედვაში და მოგცეთ საშუალება წინასწარ მოაგვაროთ საკითხები, მაგრამ მათ არ შეუძლიათ თითოეული პრობლემის დაჭერა.
მაგალითად, თუ თქვენ თავიდანვე არასწორად გაიგეთ მოთხოვნები, არც ძალიან კარგი ტესტები და არც სტატიკური ანალიზი არ გამოავლენს ხარვეზებს. მეორე მხრივ, კოდის გადახედვა ითვალისწინებს მოთხოვნებს და გეხმარებათ მათ კოდთან და დატესტილ შემთხვევებთან შესაბამისობაში. ეს საშუალებას გაძლევთ იპოვოთ შეუსაბამობები მოთხოვნებსა და რეალურ კოდს შორის.
SmartBear-ის მიერ ჩატარებულ ბოლო გამოკითხვაში, რესპონდენტთა 24%-მა მიუთითა კოდების გადახედვაზე, როგორც ნომერ პირველ გზაზე, რომელსაც კომპანია უნდა აკეთებდეს თავისი კოდის ხარისხის გასაუმჯობესებლად. ერთეულის ტესტირება არის მეორე ადგილზე და უკან მოსდევს სტატიკური კოდის ანალიზი. ეს არ ნიშნავს იმას, რომ ერთეულის ტესტირება და კოდის სტატიკური ანალიზი არ არის მნიშვნელოვანი, უბრალოდ შესაძლოა რესპოდენტები ხედავდნენ კოდის გადახედვას, როგორც რაღაცას, რომელიც ზოგჯერ უგულებელყოფილია ან კარგად არ არის შესრულებული. მაგრამ ცხადია, რომ ერთეულის ტესტები და კოდის სტატიკური ანალიზი არ ცვლის კოდის გადახედვის საჭიროებას.
მნიშვნელოვანი ნაბიჯები კოდის გადახედვისას
კოდის გადახედვის საბოლოო მიზანია იპოვოთ წერტილები, სადაც კოდი არასწორია ან შეიძლება გაუმჯობესდეს. ეს მოიცავს შემდეგის ძიებას:
- აკმაყოფილებს თუ არა კოდი მოთხოვნებს
- შეესაბამება თუ არა კოდი კოდირების კონვენციებსა და მითითებებს
- ლოგიკური შეცდომები, შეცდომებისადმი მიდრეკილი კოდი, პოტენციური ხარვეზები და ფაქტობრივი შეცდომები, პარალელური ხარვეზების ჩათვლით
- დიზაინის ხარვეზები, არაეფექტურობა და სამომავლო მზადყოფნა
- ადგილები, სადაც კოდი შეიძლება გამარტივდეს
- გვაქვს თუ არა კარგი ერთეულის ტესტები, რომლებიც ასევე გამოავლენენ მომავალ შეცდომებს
სანამ ზემოთ ჩამოთვლილ სიას უფრო დეტალურად განვიხილავთ, მოდით გადავხედოთ კოდების გადახედვის ტექნიკურ მახასიათებლებს და კოდის გადახედვის განხორციელების გზებს.
კოდის გადახედვის ტიპები
კოდის გადახედვის კლასიკური შეხვედრა
ძირითადი დაინტერესებული მხარეები ხვდებიან დეველოპერ(ებ)ს, ვინც დაწერა მოცემული კოდი. ჯგუფის ზომა დამოკიდებულია განხილული კოდის მნიშვნელობასა და სირთულეზე. გადახედვა შეიძლება შეიცავდეს დეველოპერებს სხვა გუნდებიდან, სისტემის ინჟინრებს, პროდუქტის მენეჯმენტსა და ტესტირების ინჟინრებს. ზოგიერთი მიიჩნევს, რომ დროის კარგვაა არადეველოპერების ჩართვა კოდის გადახედვაში, მაგრამ თუ შეხვედრა ორიენტირებულია რთული მოთხოვნების დანერგვის გზაზე, მათ შეიძლება ჰქონდეთ ღირებული შეხედულებები. შეხვედრა ასევე შეიძლება შეიცავდეს უბრალოდ ერთ დეველოპერს და ერთ მიმომხილველს.
კოდის გადახედვისას წამოჭრილი პრობლემები შეიძლება დაუყოვნებლივ გამოსწორდეს, თუ ისინი სწრაფად მოგვარებადია (მაგ., ცვლადების და ფუნქციების გადარქმევა ან მოკლე კომენტარების დამატება). სხვა საკითხები უნდა დოკუმენტირდეს, რათა მოგვიანებით იქნას განხილული. კოდის გადახედვის დასასრულს უნდა იქნას მიღებული გადაწყვეტილება იმის შესახებ, შეიძლება თუ არა კოდის ინტეგრირება (მცირე კომენტარების დაფიქსირების შემდეგ, ასეთის არსებობის შემთხვევაში) თუ ხელახლა უნდა იყოს წარმოდგენილი კიდევ ერთი გადახედვისთვის.
ჩვეულებრივი პრაქტიკაა, რომ გუნდში ვინმემ, ვისაც არ დაუწერია კოდი, წარადგინოს ის, ხოლო კოდერს მხოლოდ იმ შემთხვევაში ჩაეკითხებიან, თუ რამე გაურკვეველია. ეს ყველას ეხმარება დარწმუნდეს, რომ კოდი ზოგადად წაკითხვადია. მეორე მხრივ, შეიძლება უფრო ეფექტური იყოს კოდერების მიერ საკუთარი კოდის წარდგენა. ღირს ორივე გზა სცადოთ, რათა ნახოთ რომელი უფრო წაადგება თქვენს გუნდს.
დადებითი მხარეები:
- დისკუსია შესანიშნავი საშუალებაა იმ კითხვების წამოსაწევად, რომლებიც სხვაგვარად არ დაისმებოდა..
- კოდის განმახორციელებელს შეუძლია უპასუხოს კომენტარებს, გადაჭრას ზოგიერთი მათგანი ადგილზე და შექმნას სხვებისთვის ნაყოფიერი დისკუსია.
უარყოფითი მხარეები:
- ძნელია პასუხი გაეცეს კითხვებს, რომლებიც საჭიროებენ სიღრმისეულ გამოძიებას (რომელიც, ალბათ, არ გადაიჭრება იმავე შეხვედრაზე).
- შრომატევადი და ნაკლებად ეფექტურია, განსაკუთრებით თუ დიდ ჯგუფში ტარდება - ყველა დისკუსია არ არის აქტუალური ყველა მონაწილისთვის.
- საჭიროა მოიძებნოს შესაფერისი დრო, რომელიც ხელსაყრელია ყველა დაინტერესებული მხარისთვის.
‘მხარდამხარ’ გადახედვა
მას შემდეგ, რაც დეველოპერი დაწერს კოდს, გუნდის სხვა წევრი გადახედავს მას თავდაპირველ დეველოპერთან ერთად, რომელიც უყურებს; დამხმარე გუნდის წევრი განიხილავს ხარვეზებს და აკეთებს შეთავაზებებს. ამ მიდგომით, კოდის გადახედვა გაცილებით ნაკლებად ფორმალურია.
დადებითი მხარეები:
- შესანიშნავია პატარა გუნდებისთვის, სადაც ასეთი რამ შეიძლება გაკეთდეს არაფორმალურად და პირადად.
- შესრულებულია რაც შეიძლება ახლოს კოდის დასრულებასთან, როდესაც კოდი ჯერ კიდევ ახალია მწერლის გონებაში და ადვილია შესწორება და კორექტირება.
უარყოფითი მხარეები:
- შეიძლება იყოს კოდის ელემენტები ან ნაწილები, რომლებიც უგულებელყოფილი იქნება და არ მოხდება მათი გადახედვა.
- ხშირ შემთხვევაში, ასეთი გადახედვა ჩატარდება ერთეულის ტესტების ჩატარებამდე, რითაც არ განიხილება კოდის საბოლოო ვერსია.
განთავისუფლდი ბანალური საგანმანათლებლო სისტემისგან, დაიწყე პროგრამირების შესწავლა სრულიად ახალი მეთოდებით, მოერგე ბაზრის თანამედროვემოთხოვნებსდა გახდი წარმატებული!
პირინგული პროგრამირება გამორიცხავს კოდის განხილვის საჭიროებას?
პირინგულ პროგრამირებაში ორი დეველოპერი მუშაობს ერთ მანქანაზე. ერთი ადამიანი წერს კოდს, მეორე კი აძლევს რჩევებსა და უკუკავშირს მუშაობისას, და პერიოდულად როლებს ცვლიან. ეს მიდგომა ექსტრემალური პროგრამირების (XP) მეთოდოლოგიის ნაწილია. ეს შესანიშნავია დეველოპერებისთვის რომლებიც კარიერის ადრეულ ეტაპებზე იმყოფებიან, მაგრამ არ არის ძალიან ეფექტური განვითარების ყველა ამოცანისთვის. უფრო მეტიც, ის სასარგებლოა კომპლექსურ პრობლემაზე მუშაობისას, რომელსაც შეაძლოა სჭირდებოდეს ორი გონება, მაგრამ ხშირად ეს შეიძლება მოხდეს დიზაინის ეტაპზე. ფაქტობრივი კოდის წერა შემდეგ შეიძლება იმართოს ერთი დეველოპერის მიერ.
საკითხავია, გამორიცხავს თუ არა პირინგული პროგრამირება კოდის გადახედვის საჭიროებას? არა!
ორი დეველოპერი, რომლებიც ასრულებენ პირინგულ პროგრამირებას, ჩართულია კოდის დაწერაში ერთი და იგივე პერსპექტივიდან. ისინი სავარაუდოდ განმარტავენ მოთხოვნებს, იფიქრებენ დიზაინზე და გააანალიზებენ პრობლემას მსგავსი გზით. ყოველთვის არის საჭირო გარე თვალსაზრისი, ვინმე ვინც დასვამს კითხვებს, წამოჭრის ხარვეზებს, და გაითვალისწინებს მოთხოვნებს. სწორედ ამიტომ არის ფორმალური კოდის გადახედვა კრიტიკულად მნიშვნელოვანი.
კოდის გადახედვის ინსტრუმენტები
კოდების გადახედვის ინსტრუმენტები შეიძლება სასარგებლო იყოს გადახედვის სასიცოცხლო ციკლის, ასევე კომენტარებისა და პრობლემების სამართავად, რომლებიც შეიძლება წარმოიშვას. ზოგიერთი გუნდი მათ გამოსადეგად მიიჩნევს; სხვებს ურჩევნიათ მარტივი დოკუმენტის გამოყენება ან კითხვების გახსნა უშუალოდ წყაროს კონტროლში. თუ ინტრუმენტის დახმარებით კოდის გადახედვა არის ის, რაც კარგად იმუშავებს თქვენს გუნდში, მოძებნეთ ინსტრუმენტი, რომელიც გაადვილებს თანამშრომლობას, ცვლილებებისთვის თვალყურის დევნებას და კომენტარების გაზიარებას – როგორც კოდის გადახედვის შეხვედრებისთვის, ასევე კოდების ოფლაინ მიმოხილვისთვის.
აქ მოცემულია რამდენიმე პოპულარული ინსტრუმენტი:
- SmartBear Collaborator (კომერციული)
- Gerrit (ღია წყარო)
- Codestriker (ღია წყარო)
- Atlassian Crucible (კომერციული)
დადებითი ტონი და მეგობრული კითხვები მკაფიო, მოკლე და გადამწყვეტი დავალებებით
დარწმუნდით, რომ შეინარჩუნებთ დადებით ტონს და დასვამთ მეგობრულ კითხვებს (განსხვავებით თავდასხმისა და შეურაცხმყოფელი კითხვებისა და ტონისგან). იკითხეთ ისე, თითქოს დარწმუნებული არ ხართ, მაშინაც კი, თუ ფიქრობთ, რომ იცით პასუხი („არსებობს მაბლოკირებელი მექანიზმი ამ ოპერაციისთვის? გვჭირდება მაბლოკირებელი მექანიზმი?“ და არა: „მე აქ მაბლოკირებელ მექანიზმს ვერ ვხედავ, შეცდომა დაუშვით!”). ასევე კარგია (და წახალისებულია!) კარგი უკუკავშირის მიცემა („კარგი მიდგომაა, ყოჩაღ!“).
მაგრამ როდესაც საქმე ეხება კოდის გადახედვის შედეგად მიღებულ დავალებებს, ისინი უნდა იყოს მკაფიო, ლაკონური და გადამწყვეტი („საჭიროა მაბლოკირებელი მექანიზმის დამატება განახლების ქეშის ოპერაციისთვის“).
კომენტარების ტიპი კოდის გადახედვისას
კოდის გადახედვისას რამდენიმე ტიპის კომენტარი არსებობს და თითოეული განსხვავებულად უნდა განიხილებოდეს:
- სახელის გადარქმევა –სახელების განხილვა კოდის გადახედვისას ნორმალურია. საიდუმლო არ არის, რომ სახელების დარქმევა რაღაცებისთვის კოდირებაში ერთ-ერთი ყველაზე რთული ასპექტია (და ამის კარგი მიზეზი არსებობს; ან არა). და მაინც, დასახელება გადამწყვეტია კოდის წაკითხვისა და მართვისთვის. ნუ მოგერიდებათ კოდის გადახედვისას სახელის გადარქმევის მოთხოვნა, მაშინაც კი, თუ ეს კოდის გადახედვის დიდ ნაწილს მოითხოვს და დასჭირდება დამატებითი გადახედვის ჩანიშვნა (მეორე ნაწილში განვიხილავთ დასახელების კომენტარებსა და საუკეთესო პრაქტიკას). ხშირ შემთხვევაში, სახელის გადარქმევა შეიძლება მოხდეს მყისიერად, IDE-ის დახმარებით. თუ ეს ასეა, ნება მიეცით დეველოპერს გაუმკლავდეს მას. თუ ამას მეტი დრო სჭირდება (შესაბამისი სახელის მოსაფიქრებლად ან კოდის სხვა ნაწილების გადაკეთება IDE-ს მიღმაა), დააფიქსირეთ ის, როგორც კომენტარი და მიეცით პროგრამისტს ნება მოგვიანებით დაამუშაოს იგი.
- დოკუმენტაცია – დასახელების მსგავსად, კომენტარების დამატება იქ, სადაც განზრახვა არ არის ნათელი, ან არსებული კომენტარების გაუმჯობესების მცდელობა გადამწყვეტია კოდის წაკითხვადობის და შენარჩუნებისთვის. ეს უნდა იყოს თქვენი კოდის გადახედვის ნაწილი. და კიდევ ერთხელ, მოკლე კომენტარებისთვის ნება მიეცით დეველოპერს დაამატოს ისინი ადგილზევე კოდის განხილვის დროს, წინააღმდეგ შემთხვევაში დააფიქსირეთ ეს კომენტარი, როგორც შესასრულებელი დავალება. გაითვალისწინეთ, რომ სათანადო კომენტარების დამატება უნდა იყოს საჩვენებელი საშუალება, რომელიც ხელს უშლის კოდის ინტეგრირებას, რადგან მათმა გადადებამ ან უყურადღებოდ დატოვებამ შეიძლება გამოიწვიოს კომენტარების უბრალოდ დავიწყება.
- კოდის გაიდლაინების და კონვენციების არ დაკმაყოფილება – კოდის გაიდლაინები და კონვენციები საშუალებას გვაძლევს შევინარჩუნოთ დიდი კოდის ბაზა და გავიგოთ სხვების მიერ დაწერილი კოდი. კოდის გადახედვა არის დაცვა არასტანდარტული ან შეუსაბამო კოდის თქვენს რეპოზიტორში მოხვედრისგან.
- ხარვეზები, შეცდომები და პოტენციური შეცდომები – მოთხოვნების შეუსრულებლობა, შეცდომის დამუშავების გამოტოვება ან კონკრეტული შემთხვევის გაუმართაობა, ლოგიკური შეცდომები, ცუდი დიზაინი, არაეფექტურობა და არასწორი ვარაუდები – ეს არის კოდის გადახედვის პური და კარაქი (ამ ბლოგის მეორე ნაწილში ჩვენ უფრო ღრმად განვიხილავთ ამას, სპეციფიკური C++ ელემენტების ჩათვლით).
- საჭიროებს გამოძეიებას – კოდის გადახედვისას ზოგიერთ კითხვა ვერ მიიღებს მკაფიო პასუხს („დაზუსტება იძლევა თუ არა ოპერაციის გაუქმების საშუალებას, თუ ამ სტადიას მივაღწევთ?“). შედეგად მიღებული დავალება იქნება თავად გამოძიება და ხშირ შემთხვევაში, ქმედება, რომელიც უნდა განხორციელდეს, ასევე იქნება დოკუმენტირებული თითოეული შესაძლო პასუხი.
- კარგია, რომ გვქონდეს – ზოგიერთ შემთხვევაში, ჩვენ გვაქვს შემოთავაზება, რომელსაც არ ველით რომ პროგრამის განხორციელებას ამ იტერაციისთვის, მაგრამ გვსურს მისი დოკუმენტირება, როგორც იდეის, რომელიც კარგი იქნებოდა, გვქონოდა. ეს შეიძლება მოიცავდეს შეთავაზებებს ეფექტურობის გაუმჯობესებისა და კოდების გამარტივებისთვის, რომლებიც არ არის სავალდებულო ან ძალიან შრომატევადი იქნებოდა. ჩვენ მაინც გვსურს გვახსოვდეს, რომ ისინი წინ წამოიწია ორი მიზეზის გამო: (ა) შეიძლება მოგვინდეს მათი განხორციელება, თუ ამის დრო და საჭიროება გვექნება მოგვიანებით, და (ბ) გვსურს თავიდან ავიცილოთ ამ იდეების ხელახლა განხილვა მომავალ გადახედვაში (ასე რომ, ჩვენ ახლა ვადოკუმენტირებთ მათ). ასეთი კომენტარები შეიძლება შევიდეს კოდში, როგორც TODO კომენტარი, თავისი ვადით (რის შემდეგაც TODO შეიძლება წაიშალოს თუ არ შესრულდა).
- შემდეგ ჯერზე იქნებ სხვანაირად გაკეთდეს – ამ ტიპის კომენტარები ეკუთვნის გადახედვის საგანმანათლებლო მხარეს. ზოგიერთ შემთხვევაში, არის კოდი, რომელიც შეიძლება სხვაგვარად დაიწეროს, მაგრამ ამჟამად არ ღირს მისი შეცვლა (მუშაობს, არა უშავს, არ შეეხოთ მას). მიუხედავად ამისა, შეიძლება მაინც გინდოდეთ პროგრამისტი გააფრთხილოთ, რომ ის შეიძლება დაიწეროს უფრო ელეგანტურად ან მარტივად. თუ დრო გაქვთ, წამოჭერით ეს აზრი გადახედვისას, თუნდაც ეს არ იყოს TODO კომენტარისთვის ამ შემთხვევაში.
- არ ღირს კიმენტარის გაკეთებად – მოერიდეთ კომენტარებს, როგორიცაა: „ეს კარგი მიდგომაა, მაგრამ შეიძლებოდა სხვაგვარად გაკეთებულიყო“ - როცა ალტერნატივას არანაირი უპირატესობა არ აქვს. დარწმუნდით, რომ არ გააკეთებთ ზედმეტ კომენტარებს, რომლებიც გაკარგვინებთ დროს გადახედვისას და გადააქვთ ყურადღება რეალური საკითხებიდან. ზოგიერთ გადამხედველს მოსწონს კოდის გადახედვის გამოყენება გმირული ისტორიებისთვის იმის შესახებ, თუ როგორ გაუკეთებიათ მსგავსი საქმე წარსულში. ნუ გააკეთებ ამას. ისაუბრეთ პირდაპირ განხილულ კოდზე და თუ თქვენ არ გაქვთ რაიმე მნიშვნელოვანი სათქმელი, ნუ იგრძნობთ ვალდებულებას სხვებს გაუზიაროთ თქვენი აზრი.
საიდან უნდა დაიწყოს გადახედვა?
კოდის ცვლილებების გადახედვა
მცირე ახალი ფუნქციის ან ხარვეზის გამოსწორების განხილვისას, ჩვეულებრივ, განხილვა ორიენტირებულია კოდის შეცვლაზე. ამ შემთხვევაში, უმჯობესია კოდი გადაიხედოს გვერდიგვერდ, ძველი კოდი შედარდეს ახალს. დაიწყეთ გადახედვა შესამოწმებელი ფაილების სიით და ნათლად ახსენით ცვლილების საჭიროება თითოეულში. შემდეგ გადახედეთ თითოეულ ფაილში ცვლილებების დეტალებს, შესაბამისი ლოგიკური თანმიმდევრობით. თუ დაიწყებთ მაღალი დონის განმარტებით, შეგიძლიათ გადახედვა ნებისმიერი მიმართულებით წაიყვანოთ.
ახალი კოდის გადახედვა
დაიწყეთ განსახილველი მოთხოვნების და მაღალი დონის დიზაინის ახსნით, შემდეგ ჩამოთვალეთ ახალი კლასები და ფაილები, რომლებიც დაემატება. დარწმუნდით, რომ ჩაუღრმავდებით უფრო რთულ ნაწილებს (ახალი ალგორითმები, რესურსების ერთდროული გამოყენების საკითხები და ა.შ.). გადახედეთ კოდს სათანადო ლოგიკური თანმიმდევრობით (ნუ გადახტებით პირდაპირ ახალ ალგორითმზე, თუ აუდიტორიას არ აქვს შესაბამისი კონტექსტი მის გასაგებად). დაიტოვეთ საკმარისი დრო თქვენი კოდის უფრო რთული ნაწილების განსახილველად (თუ რთული ალგორითმის განხილვისთვის დარჩა მხოლოდ ხუთი წუთი, უბრალოდ დაგეგმეთ კიდევ ერთი გადახედვის შეხვედრა, ნუ ეცდებით რთული საკითხების გადახედვას არასაკმარისი დროის პერიოდში). კიდევ ერთხელ, მაღალი დონის ახსნა-განმარტებით დაწყებული გადახედვა შესაძლოა ნებისმიერი მიმართულებით წარიმართოს. ასეც რომ იყოს, ახალი კოდისთვის, უმეტეს შემთხვევაში, მაღალი დონის ახსნა-განმარტების მიღების შემდეგ, უფრო ადვილი და ეფექტური იქნება საკითხი ზემოდან ქვემოთ განხილვის მიდგომის დაცვა.
რა თქმა უნდა, გადახედვა შეიძლება მოიცავდეს ახალი კოდისა და კოდის ცვლილებების ნაზავს, ამ შემთხვევაში კარგი იქნება თითოეულისთვის შესაბამისი მიდგომის გამოყენება. ლოგიკა, თუ საიდან უნდა დაიწყოს გადახედვა ასეთ შემთხვევებში, ახალი კოდიდან თუ კოდის ცვლილებებიდან, დამოკიდებულია იმაზე, თუ რომელი თანმიმდევრობა გაადვილებს მის გაგებას.
ტესტების გადახედვა
ერთეულის ტესტების გავლა, იქნება ეს ახალი ერთეულის ტესტები თუ არსებულის განახლებები, უნდა იყოს თქვენი კოდის გადახედვის ნაწილი. ეს არის თქვენი შანსი, დარწმუნდეთ, რომ ახალი კოდი კარგად არის დატესტილი და რომ ტესტები მოიცავს რეალურ სიტუაციებს და არა გამოგონილ სიტუაციებს, რომლებსაც საერთო არაფერი აქვთ მოთხოვნებთან. თქვენ შეგიძლიათ გადახედვის დაწყება ტესტებიდან, რადგან ზოგიერთ შემთხვევაში ეს არის საუკეთესო საწყისი წერტილი განხორციელებული ფუნქციის გასაგებად ან შესწორებისთვის.
დაეუფლე აქტუალურ პროფესიებს - შემოგვიერთდითსტეპერებისდიდოჯახში!
IT Academy Step ლიდერი IT სფეროში - უკვე 100+ ფილიალით!
+995 577 538 549 ქ.თელავი, ნადიკვრის#23
+995 (32) 215-55-51 ქ.თბილისი, ა.ყაზბეგის34/34ბ
