გოდეს ინტერნეტ დავთარი

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

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

მოკლედ ისმის კითხვა: “რა ვქნათ?”. ცხადია რომ რაღაც უნდა ვქნათ და ამ რაღაცას, ჩემი დაკვირვებებითა და მწარე გამოცდილებით ჯადოსნური სიტყვა “სტანდარტები” ეწოდება. ვიცი რომ პროგრამისტისთვის ეს სიტყვა საშინლად და საშიშად ჟღერს, მაგრამ მიჩვევის ამბავია ადრე თუ გვიან სტანდარტის აუცილებლობა დგება და რაც ადრე მივალთ აქამდე, მით უკეთესია.

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

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

რისი სტანდარტიზაცია მოვახდინოთ? ალბათ ყველაფრის, რაშიც განსხვავებებია მოსალოდნელი ორი ადამიანის ნამუშევარში და რაც მომავალში პრობლემად გვექცეს. სია შეიძლება საკმაოდ გრძელი იყოს, მაგრამ პირველი, რაც თავში მოსდის ადამიანს არის სხვადასხვა პროგრამული ობიექტების დასახელებების სტანდარტიზაცია. აქ საერთაშორისო სტანდარტებში საკმაო აჯეფსანდალია და შეიძლება გაგიჩნდეთ კითხვა: “და რა გამოვიყენო? Pascal Case? Camel Case? private ტიპის ობიექტებს როგორ დავარქვა სახელი? პრეფიქსი გავუკეთო? თუ პატარა სიმბოლოთი დავიწყო?”. საბოლოო ჯამში ეს მთავარი არ არის. მთავარია აირჩიოთ რომელიმე ვარიანტი და შემდეგ მას მიყვეთ, მთავარია ყველა, ვინც კოდზე მუშაობს ამ სტანდარტებს მიყვეს და არ გადაუხვიოს. მთავარია კოდი აჯეფსანდალს აღარ გავდეს ხოლო private ტიპის ობიექტებს წინ “_” პრეფიქსს დაურთავთ თუ პატარა სიმბოლოთი დაიწყებთ, დიდი მნიშვნელობა არ აქვს. მთავარია არსებობდეს საერთო წესები, რომელიც ყველასთვის იქნება სავალდებულო და რომელსავ ყველა დაიცავს.

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

ლოგიკურია რომ გაჩნდება კითხვა: “ღირს კი ჩიტი ბრდღვნად? არ ჯობია ეს დრო რამე სუპერ ახალი ტექნოლოგიის გარჩევაზე დაიხარჯოს?” ჩიტი ბრდღვნად ღირს. მითუმეტეს, რომ ეს საქმე ერთჯერადია, ერთხელ დაიხარჯება დრო და ადამიანური რესურსი, ხოლო შემდეგ, 3-6 თვეში ერთხელ მცირედი ცვლილებების შეტანა იქნება საჭირო. სამაგიეროდ თქვენ ერთი ხელის მოსმით სპობთ დიდ პრობლემას: არავითარი განსხვავებული სტილი და მანერა კოდში, არსებობს სტანდარტი - ყველა წერს მისი დაცვით.

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

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

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

დასასრულს მინდა მაგალითისთვის დავდო SQL Coding Standards-ი, რომელის მიხედვითაც ვხელმძღვანელობ ამჟამად და რომელიც შეიძლება ჩემს გარდა კიდევ ვინმეს გამოადგეს.

როგორც ყოველთვის სიამოვნებით მოვისმენ თქვენს შენიშვნებსა და იდეებს

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