სულ მაინტერესებდა, როგორ წერენ უზარმაზარ წარმატებულ პროგრამებს შეცდომების გარეშე, მაგალითად მარს როვერი “Curiosity”, რომელიც მარსზე გაფრინდა, 8 თვეში გაიარა 350 მილიონი მილი, დაეშვა 6 მილის რადიუსში, უცხო გარემოში დადის და დედამიწაზე გზავნის მონაცემებს.
როგორ გაუშვეს როვერი მარსზე
ინტერნეტში არის ერთ-ერთი უიშვიათესი ტექნიკური ხასიათის გამოსვლა მარს როვერის შესახებ. ნასას JPL – Jet Propulsion Laboratory ლაბორატორიის ერთ-ერთი მთავარი მეცნიერი, Gerard Holzmann აღწერს, თუ როგორ ცდილობდნენ პროგრამირების პროცესის წარმართვას, რომ მაქსიმალურად აეცილებინათ პრობლემები.
მოკლედ ვიტყვი რამდენიმე ფაქტს ვიდეოდან:
- დაახლოებით 4 მილიონი ხაზი კოდი, 100-ზე მეტი მოდული, 120 ნაკადი ერთ პროცესორზე (+1 ბეკაპი). ხუთი წელი და 40 პროგრამისტი. ყველაფერს კი ერთი მომხარებლისთვის და პირველივე გამოყენებაზე უნდა ემუშავა.
- უფრო მეტი კოდი იყო, ვიდრე მთელი წინა მარსის მისიების ერთად აღებული. ასეთი ზომის გამო ადამიანური კოდის რევიუები აღარ მუშაობდა ეფექტურად.
- შემოიღეს რისკების შესამცირებელი სტანდარტი და მუდმივად ამოწმებდნენ ავტომატური ხელსაწყოებით. იმის გამო, რომ ადამიანები არ კითხულობდნენ და იცავდნენ დოკუმენტებს ასობით წესებით, ჩაატარეს გამოკითხვა და გამოარჩიეს ათი ყველაზე მნიშვნელოვანი წესი: Power of ten
მაგალითად: ნუ გამოიყენებთ რეკურსიას, goto-ს და მსვლელობის სხვა რთულ კონსტრუქციებს; მონაცემების ხედვის არე (scope) იყოს მინიმალური; ყველა ციკლს ჰქონდეს ფიქსირებული საზღვრები; პოინტერის მხოლოდ ერთი განმისამართება გააკეთეთ, ფუნქციის პოინტერებს ნუ გამოიყენებთ; ა.შ. - ყოველ ღამე ხდებოდა კოდის დაბილდვა, სტატიკური ანალიზი და სხვადასხვა ავტომატური ტესტირება. ღამე იმიტომ, რომ 15 საათი სჭირდებოდა ანალიზს.
- ვინც ბილდს გააფუჭებდა, დაჯარიმდებოდა და ბრიტნი სპირსის პლაკატს გამოაკრავდა თავის კუბში. ხოლო ვინც ბევრ warning-ებს დატოვებდა კოდში, “სირცხვილის კედელზე” მოხვდებოდა. როგორც ჩანს ნასაშიც კი სჭირდებათ ადამიანებს მოტივაცია წესების დასაცავად 😀
- სპეციალური ტრენინგის და სერტიფიცირების გარეშე არ უშვებდნენ კოდთან ადამიანს.
- ითხოვდნენ 100% code coverage-ს. ვისაც გაუკეთებია ეს, მიხვდება თუ რა შრომატევადი ამოცანაა 100%, რადგან არარსებული სცენარების გატესტვაც მოუწევთ – მაგალითად if-ების ისეთი განშტოებები, რომელიც შეუძლებელია ოდესმე შესრულდეს.
- კოდის რევიუ არ იყო ხანგრძლივი ჯგუფური შეკრება. იკრიბებოდნენ მხოლოდ უთანხმოების განსახილველად. შენიშვნები და მითითები ერთმანეთში სპეციალური პროგრამის გამოყენებით იცვლებოდა, რომელიც კოდის სხვადასხვა სტატუსებსაც აჩვენებდა წინა ღამის შემოწმებიდან.
- კომპილატორიდან და სტატიკური ანალიზიდან 0 warning უნდა ყოფილიყო, რაც საკმაოდ რთული შესასრულებელი აღმოჩნდა და დიდი დრო დასჭირდა. უცნობია კორელაცია ამ პუნქტის შესრულებასა და პროექტის წარმატებულობას შორის, თუმცა ეს ყველაზე სუფთა კოდი იყო, წინა მისიებთან შედარებით.
- კრიტიკულ ნაწილებში იცავდნენ MISRA პროგრამირების სტანდარტს – რომელიც ძრავების და სასიცოცხლო მნიშვნელობის აპარატურაში გამოიყენება.
- კრიტიკული ქვესისტემებისთვის ლოგიკურ ვერიფიკაციას აკეთებდნენ – მათემატიკურად ამტკიცებდნენ ალგორითმის სისწორეს.
ამ მისიაში დაინტერესებულებისთვის კიდევ ერთი გამოსვლა არსებობს (თუმცა მე პირველი უფრო მომეწონა): CppCon 2014: Mark Maimone “C++ on Mars: Incorporating C++ into Mars Rover Flight Software”
სტანდარტის დარღვევაზედ
ინტერნეტში ცნობილი შემთხვევებიდან ყველაზე ძვირიანი კოდი Space Shuttle-ისთვის დაიწერა – 1000$/ხაზი. მაგრამ 2013 წელს ტოიოტამ სასამართლო წააგო და კომპენსაციის თანხით თუ დავთვლით დაახლოებით 1200$ დაუჯდა თითო ხაზი. ტოიოტას უნებური აჩქარების პრობლემა არაერთხელ მოხვდა სიახლეებში ავტო ავარიების და საჩივრების გამო. ხან ხალიჩები გაიწვიეს უკან, ხან გაზის პედლები, მაგრამ საკმარისი არ აღმოჩნდა. მერე NASA-ს გუნდმა შეამოწმა გაზის კონტროლის პროგრამა ტოიოტას მანქანაზე და, მართალია, თავიანთ სტანდარტთან შედარებით 243 დარღვევა ნახეს, მაგრამ საბოლოოდ ვერ დაადასტურეს, რომ პროგრამის შეცდომის ბრალი იყო. სასამართლოს გარე ექსპერტად ერთი ტიპი ჰყავდა, რომელმაც მიწასთან გაასწორა ტოიოტას კოდი, უწესო რეკურსიაო, სტეკ ოვერფლოუვო და კიდევ ათასი რაღაც.
თუმცა ბოლო ბოლო მგონი მაინც არ იყო ზუსტი განაჩენი გამოტანილი პროგრამისთვის. მთლიანი ქეისი აქ არის: A Case Study of Toyota Unintended Acceleration and Software Safety
ჩვენ, უბრალო მოკვდავი პროგრამისტები
თურმე პროგრამისტები ძალიან ბევრს ვრისკავთ 🙂 ვენდობით ოპერაციულ სისტემას, გარე ბიბლიოთეკებს, არ ვამოწმებთ ფუნქციიდან დაბრუნებულ მნიშვნელობას ვალიდურობაზე. მართალია, მომხმარებლის მიერ შეყვანილ მონაცემებს ვფილტრავთ, მაგრამ ვაკეთებთ კი იგივეს, როცა სხვადასხვა სერვისს ვესაუბრებით? ეს ბუნებრივია ჩემი აზრით, ყველა შემთხვევის შემოწმება ძალიან შრომატევადი და შესაბამისად ძვირი პროცესია. შეგიძლიათ გადახედოთ Defensive programming სტრატეგიებს.
არსებობს პროგრამები, რომელსაც შეცდომა თითქმის არ მოსდის, მაგრამ თუ მოუვა უზარმაზარს ზარალს მოიტანს. ანალოგიურად არსებობს ისეთებიც, რომელშიც ხშირად ხდება შეცდომა, მაგრამ მარტივი და იაფი ჯდება მისი გასწორება. დაახლოებით ისე, როგორც მანქანებში – იშვიათად გაფუჭებული BMW-ს შეკეთება ძვირია, ამერიკას კი ომის დროს ჰყავდა Willys MB ჯიპები, რომელსაც დაზიანებისას ძალიან სწრაფად აღადგენდნენ. საერთოდ შლიდნენ და ისე გადაჰქონდათ აქეთ-იქით. ვიდეოც არის ინტერნეტში, სადაც კანადელი ჯარისკაცები 4 წუთში შლიან და აწყობენ მთელ მანქანას.
ჩვენი პროგრამების უმრავლესობაც წესით ამ მეორე კატეგორიას მიეკუთვნება. მთავარია ცვლილების შეტანა სწრაფად და იაფად შევძლოთ, თორემ ეგეთი კოდიც თუ ძვირი დაუჯდათ, აღარ დაგვიკვეთავენ 😀