როგორ განვახორციელოთ სტატიკური კოდის ანალიზატორი ძველ პროექტში გუნდის დემოტივაციის გარეშე

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

შესავალი

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

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

საკითხები

როგორც წესი, არ არის რთული გაშვება და დანახვა, თუ როგორ მუშაობს სტატიკური ანალიზატორი [1]. კოდში შეიძლება ნახოთ საინტერესო შეცდომები ან თუნდაც საშინელი პოტენციური დაუცველობა. რაღაცის გამოსწორებაც კი შეგიძლია, მაგრამ შემდეგ ბევრი პროგრამისტი უარს ამბობს.

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

ცრუ დადებითი არ არის პრობლემა, თუ სტატიკური ანალიზატორი უკვე კონფიგურირებულია:

• გამორთულია შეუსაბამო წესების ნაკრები;
• ზოგიერთი შეუსაბამო დიაგნოსტიკა გამორთულია;
• თუ ვსაუბრობთ C ან C++-ზე, მაშინ მონიშნულია მაკროები, რომლებიც შეიცავს სპეციფიკურ კონსტრუქტებს, რომლებიც იწვევს უსარგებლო გაფრთხილებების გამოჩენას ყველა ადგილას, სადაც ასეთი მაკრო გამოიყენება;
• მონიშნულია საკუთარი ფუნქციები, რომლებიც ასრულებენ სისტემის ფუნქციების მსგავს მოქმედებებს (საკუთარი ანალოგი მემკვიდრე ან printf) [4];
• ცრუ დადებითი კონკრეტულად გამორთულია კომენტარების გამოყენებით;
• და ასე შემდეგ.

ამ შემთხვევაში შეიძლება ველოდოთ დაბალი ცრუ დადებითი მაჩვენებელი დაახლოებით 10-15% [5]. სხვა სიტყვებით რომ ვთქვათ, ანალიზატორის 9-დან 10 გაფრთხილება მიუთითებს რეალურ პრობლემაზე კოდში, ან მინიმუმ „ძლიერი სუნის კოდს“. ვეთანხმები, ეს სცენარი ძალიან სასიამოვნოა და ანალიზატორი პროგრამისტის ნამდვილი მეგობარია.

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

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

რა თქმა უნდა, უმნიშვნელო შეცდომებიც კი მაინც შეცდომაა. და ზოგჯერ შეცდომამ შეიძლება დამალოს რეალური დაუცველობა. თუმცა ყველაფრის დათმობა და დღეების/კვირების გატარება დეფექტებთან, რომლებიც ძლივს იჩენს თავს, საეჭვო იდეას ჰგავს.

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

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

ეს იგივე ანალოგია, როგორც შემდგენლის გაფრთხილებებთან. უსაფუძვლოდ არ გირჩევენ კომპილერის გაფრთხილებების რაოდენობას 0-ზე.

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

ტექნიკური დავალიანების განხორციელება და აღმოფხვრა

სინამდვილეში, არაფერია რთული ან საშინელი სტატიკური ანალიზის დანერგვაში, თუნდაც დიდ ძველ პროექტში.

CI / CD

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

• PVS-Studio მიდის ღრუბლებში: Azure Devops
• PVS-Studio მიდის ღრუბლებში: Travis CI
• PVS-Studio მიდის ღრუბლებში: GitLab CI/CD
• PVS-Studio მიდის ღრუბლებში: CircleCI

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

არსებული ტექნიკური დავალიანების დაფიქსირება და ახალ გაფრთხილებებთან გამკლავება

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

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

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

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

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

შეცდომების გამოსწორება და რეფაქტორირება

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

if (a = b)

C++ შემდგენელებისა და ანალიზატორების უმეტესობა უჩივის ასეთ კოდს, რადგან დიდია ალბათობა იმისა, რომ მათ ნამდვილად სურდათ დაწერა. (a == ბ). მაგრამ არის გამოუთქმელი შეთანხმება და ეს ჩვეულებრივ აღინიშნება დოკუმენტაციაში, რომ თუ არის დამატებითი ფრჩხილები, მაშინ ითვლება, რომ პროგრამისტმა შეგნებულად დაწერა ასეთი კოდი და არ არის საჭირო გინება. მაგალითად, PVS-Studio-ს დიაგნოსტიკის დოკუმენტაციაში V559 (CWE-481) ნათლად წერია, რომ შემდეგი სტრიქონი ჩაითვლება სწორად და უსაფრთხოდ:

if ((a = b))

Სხვა მაგალითი. ეს დავიწყებულია ამ C++ კოდში? შესვენება თუ არა?

case A:
  foo();
case B:
  bar();
  break;

PVS-Studio ანალიზატორი აქ გამოსცემს გაფრთხილებას V796 (CWE-484). ეს შეიძლება არ იყოს შეცდომა, ამ შემთხვევაში თქვენ უნდა მისცეთ პარსერს მინიშნება ატრიბუტის დამატებით [[ჩავარდნა]] ან მაგალითად __ატრიბუტი__((ჩავარდნა)):

case A:
  foo();
  [[fallthrough]];
case B:
  bar();
  break;

შეიძლება ითქვას, რომ კოდის ასეთი ცვლილებები არ ასწორებს შეცდომას. დიახ, ეს მართალია, მაგრამ ის ორ სასარგებლო რამეს აკეთებს. პირველ რიგში, ანალიზატორის ანგარიში ათავისუფლებს ცრუ პოზიტიურ შედეგებს. მეორეც, კოდი უფრო გასაგები ხდება მის შენარჩუნებაში ჩართული ადამიანებისთვის. და ეს ძალიან მნიშვნელოვანია! მხოლოდ ამისთვის, ღირს მცირე რეფაქტორაციების ჩატარება, რათა კოდი უფრო ნათელი და ადვილად შენარჩუნდეს. ვინაიდან ანალიზატორს არ ესმის, საჭიროა თუ არა „შესვენება“, ეს ასევე გაუგებარი იქნება პროგრამისტებისთვის.

შეცდომების გამოსწორებისა და რეფაქტორირების გარდა, თქვენ შეგიძლიათ კონკრეტულად აღკვეთოთ აშკარად ყალბი ანალიზატორის გაფრთხილებები. ზოგიერთი შეუსაბამო დიაგნოსტიკა შეიძლება გამორთული იყოს. მაგალითად, ვინმე ფიქრობს, რომ გაფრთხილება უაზროა V550 float/ორმაგი მნიშვნელობების შედარების შესახებ. ზოგი კი მათ ახარისხებს, როგორც მნიშვნელოვან და შესასწავლად [7]. რომელი გაფრთხილება ითვლება რელევანტურად და რომელი არა, დეველოპერების გუნდის გადასაწყვეტია.

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

ასევე, ჩვენ ყოველთვის ვეხმარებით ჩვენს კლიენტებს PVS-Studio-ს შექმნაში, თუ რაიმე სირთულე წარმოიქმნება. უფრო მეტიც, იყო შემთხვევები, როდესაც ჩვენ თვითონ აღმოვფხვით ცრუ გაფრთხილებები და გამოვასწორეთ შეცდომები [8]. ყოველი შემთხვევისთვის გადავწყვიტე აღვნიშნო, რომ გაფართოებული თანამშრომლობის ეს ვარიანტიც შესაძლებელია :).

Ratchet მეთოდი

არსებობს კიდევ ერთი საინტერესო მიდგომა კოდის ხარისხის თანდათანობით გასაუმჯობესებლად სტატიკური ანალიზატორის გაფრთხილების აღმოფხვრის გზით. დასკვნა ის არის, რომ გაფრთხილებების რაოდენობა შეიძლება მხოლოდ შემცირდეს.

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

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

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

სტატიის ავტორს ასევე აქვს მოხსენება ამ თემაზე: ”უწყვეტი სტატიკური ანალიზი".

დასკვნა

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

არსებობს სხვა ტიპიური ეჭვები იმის შესახებ, შეიძლება თუ არა სტატიკური ანალიზი მართლაც მოსახერხებელი და სასარგებლო. მე შევეცადე ამ ეჭვების უმეტესი ნაწილი გამეფანტა პუბლიკაციაში "PVS-Studio სტატიკური კოდის ანალიზატორის განვითარების პროცესში დანერგვის მიზეზები" [9].

გმადლობთ ყურადღებისთვის და მობრძანდით ჩამოტვირთვა და სცადეთ PVS-Studio ანალიზატორი.

დამატებითი ბმულები

1. ანდრეი კარპოვი. როგორ შემიძლია სწრაფად ვნახო საინტერესო გაფრთხილებები, რომლებსაც PVS-Studio ანალიზატორი აწარმოებს C და C++ კოდებისთვის?
2. ვიკიპედია რაისის თეორემა.
3. ანდრეი კარპოვი, ვიქტორია ხანიევა. მანქანური სწავლის გამოყენება პროგრამის საწყისი კოდის სტატიკურ ანალიზში.
4. PVS-სტუდია. დოკუმენტაცია. დამატებითი დიაგნოსტიკური პარამეტრები.
5. ანდრეი კარპოვი. PVS-Studio ანალიზატორის მახასიათებლები EFL Core ბიბლიოთეკების მაგალითის გამოყენებით, 10-15% ცრუ დადებითი.
6. PVS-სტუდია. დოკუმენტაცია. ანალიზატორის შეტყობინებების მასობრივი ჩახშობა.
7. ივან ანდრიაშინი. იმის შესახებ, თუ როგორ გამოვცადეთ სტატიკური ანალიზი ჩვენს პროექტზე რენტგენის ენდოვასკულარული ქირურგიის საგანმანათლებლო სიმულატორის შესახებ.
8. პაველ ერემეევი, სვიატოსლავ რაზმისლოვი. როგორ გააუმჯობესა PVS-Studio-ს გუნდმა Unreal Engine კოდი.
9. ანდრეი კარპოვი. განვითარების პროცესში სტატიკური კოდის ანალიზატორი PVS-Studio-ს დანერგვის მიზეზები.

თუ გსურთ გაუზიაროთ ეს სტატია ინგლისურენოვან აუდიტორიას, გთხოვთ, გამოიყენოთ თარგმანის ბმული: ანდრეი კარპოვი. როგორ შემოვიტანოთ სტატიკური კოდის ანალიზატორი მემკვიდრეობით პროექტში და არ დავაცადოთ გუნდი.

წყარო: www.habr.com