პროგრამირება არ არის უბრალოდ კოდის წერა (ნაწილი 1)

cover image

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

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

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

ხშირად დაშვებული შეცდომები

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

  1. გამოუცდელობა – სრულიად გამოსწორებადია.
  2. არაპროფესიონალიზმი – მიუღებელია, თუმცა აგრეთვე გამოსწორებადი სურვილის ქონის შემთხვევაში.
  3. სწრაფად საქმის თავიდან მოშორება – რაც მიუღებელია.
  4. უინტერესობა საქმის მიმართ – რაც მიუღებელია.

ნებისმიერ საქმეში, ყოველი პროცესის შესრულებას, წინ მიუძღვის მისი გეგმარება. კერძოდ პროგრამირებაში პროცესების დასაგეგმად გამოიყენება ე.წ. UML (Unified Modeling Language) https://en.wikipedia.org/wiki/Unified_Modeling_Language

ნებისმიერი პატარა პროგრამის, ფუნქციისა თუ პროცედური კოდის დაწერის წინ, მთელი პროცესი, დაგეგმილი უნდა იყოს UML – ით. გამოცდილების მოსვლასთან ერთად, გარკვეული ამოცანებისათვის, ასეთი გეგმარების პროცესი ნელ-ნელა გონებაში გადადის, მაგრამ არასოდეს ექვემდებარება ამოვარდნას სამუშაო ციკლიდან.

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




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

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

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

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

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

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

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

იმედია ნამეტანი თავი არ მოგაბეზრეთ საკუთარი “ფილოსოფიით” და მეორე ნაწილითაც დაინტერესდებით