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

მესამე ადგილი - Microsoft C კომპილერი

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

როდესაც MIT-ში მეორე კურსი დავამთავრე, ახალგაზრდა და გამოუცდელი ვიყავი, როგორც ცხოვრებაში, ასევე პროგრამირებაში. ზაფხულში გავიარე სტაჟირება მაიკროსოფტში, C-ის შემდგენლების გუნდში. თავიდან ვაკეთებდი რუტინულ რაღაცეებს, როგორიცაა პროფილის მხარდაჭერა, შემდეგ კი დამევალა მუშაობა კომპილერის ყველაზე სახალისო ნაწილზე (როგორც მე მეგონა) - backend ოპტიმიზაცია. კერძოდ, მომიწია x86 კოდის გაუმჯობესება ფილიალის განცხადებებისთვის.

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

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

Გაკვეთილი ნასწავლია

როგორც დევიდ პატერსონი და ჯონ ჰენესი წერენ Computer Architecture and Computer Systems Design-ში, არქიტექტურისა და დიზაინის ერთ-ერთი მთავარი პრინციპი არის, ზოგადად, ყველაფერი რაც შეიძლება სწრაფად იმუშაოს.

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

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

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

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

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

მეორე ადგილი: რეკლამა სოციალურ ქსელებში

როდესაც ვმუშაობდი Google-ში სოციალური მედიის რეკლამაზე (გახსოვთ Myspace?), მე დავწერე მსგავსი რამ C++-ში:

for (int i = 0; i < user->interests->length(); i++) {
  for (int j = 0; j < user->interests(i)->keywords.length(); j++) {
      keywords->add(user->interests(i)->keywords(i)) {
  }
}

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

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

Გაკვეთილი ნასწავლია

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

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

აი რა უთხარი IBM-ის ლეგენდარული ხელმძღვანელის, თომას უოტსონის შესახებ:

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

უოტსონმა ჰკითხა, რა მოხდა.

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

უოტსონი მას კარებთან მიუახლოვდა, თვალებში ჩახედა და კონვერტი დააბრუნა შემდეგი სიტყვებით: „როგორ გაგიშვებ? მე მხოლოდ მილიონი დოლარი ჩავდე შენს განათლებაში.

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

პირველი ადგილი: App Inventor API

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

რაც უარესი მით უკეთესი

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

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

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

ეს ერთი წუთით დავივიწყოთ. სამწუხაროდ, მრავალი წელი დამავიწყდა.

აპლიკაციის გამომგონებელი

Google-ში მუშაობისას გუნდის წევრი ვიყავი აპლიკაციის გამომგონებელი, გადაათრიეთ და ჩამოაგდეთ ონლაინ განვითარების გარემო ანდროიდის დეველოპერებისთვის. 2009 წელი იყო და დროულად გვეჩქარებოდა ალფა ვერსიის გამოშვება, რათა ზაფხულში ჩაგვეწყო მასტერკლასები მასწავლებლებისთვის, რომლებსაც შეეძლოთ გარემოს გამოყენება შემოდგომაზე სწავლებისას. მე მოხალისედ გავხდი სპრაიტების დანერგვა, ნოსტალგიური იმის მიმართ, თუ როგორ ვწერდი თამაშებს TI-99/4-ზე. მათთვის, ვინც არ იცის, სპრაიტი არის ორგანზომილებიანი გრაფიკული ობიექტი, რომელსაც შეუძლია გადაადგილება და ურთიერთქმედება სხვა პროგრამულ ელემენტებთან. სპრაიტების მაგალითებია კოსმოსური ხომალდები, ასტეროიდები, მარმარილოები და რაკეტები.

ჩვენ განვახორციელეთ ობიექტზე ორიენტირებული App Inventor Java-ში, ასე რომ, იქ მხოლოდ რამდენიმე ობიექტია. ვინაიდან ბურთები და სპრაიტები ძალიან იქცევიან, მე შევქმენი აბსტრაქტული სპრაიტის კლასი თვისებებით (ველები) X, Y, სიჩქარე (სიჩქარე) და Heading (მიმართულება). მათ ჰქონდათ იგივე მეთოდები შეჯახების აღმოსაჩენად, ეკრანის კიდეზე გადახტომისთვის და ა.შ.

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

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

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

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

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

ნასწავლი გაკვეთილები

API-ებზე მუშაობისას (რაც ზოგჯერ თითქმის ყველა პროგრამისტს უწევს), უნდა მიჰყვეთ საუკეთესო რჩევებს, რომლებიც მოცემულია ჯოშუა ბლოხის ვიდეოში.როგორ შევქმნათ კარგი API და რატომ არის ეს ასე მნიშვნელოვანი"ან ამ მოკლე სიაში:

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

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

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

დასკვნა

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

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

წყარო: www.habr.com