დეველოპერების ერთ-ერთი ყველაზე ფუნდამენტური ამოცანა კოდის კითხვა და გაგებაა. იქნება ეს ახალი ფუნქციის დაგეგმვა და განხორციელება, შეცდომის გამოკვლევა თუ მოთხოვნის განხილვა, დეველოპერები უფრო მეტ დროს კოდის კითხვას და გაგებას უთმობენ, ვიდრე მის დაწერას.
დეველოპერების ერთ-ერთი ყველაზე ფუნდამენტური ამოცანა კოდის კითხვა და გაგებაა. იქნება ეს ახალი ფუნქციის დაგეგმვა და განხორციელება, შეცდომის გამოკვლევა თუ მოთხოვნის განხილვა, დეველოპერები უფრო მეტ დროს კოდის კითხვას და გაგებას უთმობენ, ვიდრე მის დაწერას.
სწორედ ამიტომ, ბოლო ორი წლის განმავლობაში, GitHub-მა კოდების ძიების გასაუმჯობესებლად ახალი ტექნოლოგია შეიმუშავა. დღეს GitHub.com-ზე კოდის ძებნა და ნახვა ყველა მომხმარებლისთვის ხელმისაწვდომია.
«ამ წამოწყების მთავარი მიზანი დეველოპერების პროდუქტიულობის გაზრდაა — სწრაფი ძებნისა და ნავიგაციის შესაძლებლობა კი ამის საშუალებას იძლევა. ამის მისაღწევად, ჩვენ სამი ახალი სერვისი დავამატეთ» — ვკითხულობთ GitHub-ის ბლოგ-პოსტში.
პირველი, მთლიანად გადამუშავებული საძიებო ინტერფეისი, წინადადებებით, დასრულებებით და შედეგების დაჭრის შესაძლებლობით.
მეორე, სრულიად ნულიდან ახალი კოდის საძიებო სისტემა შეიქმნა, რომელიც წარმოუდგენლად სწრაფი (დაახლოებით ორჯერ უფრო სწრაფი, ვიდრე ძველი კოდის ძიება), და უნარიანია.
და მესამე, GitHub-ის კოდის ხედი მთლიანად განახლდა — ძიება, დათვალიერება და კოდის ნავიგაცია გაერთიანდა.
საინტერესოა, როგორ შეიძლება დეველოპერმა კოდის ძებნა პროდუქტიულად გამოიყენოს:
წარმოიდგინეთ, მომხმარებელი ჩივის, რომ მათ თქვენი სერვისიდან შეცდომის შეტყობინება მიიღეს, რომელშიც ნათქვამია: «მოთხოვნა არ არის დაკმაყოფილებული». ამ დროს თქვენ დარწმუნებული არ ხართ, შეტყობინება რომელმა სისტემამ შექმნა, ან კოდი რომელ საცავშია.
კოდის ძიების გარეშე, შესაძლოა საცავების კლონირება და მათში ძრომიალი, ან მცოდნე კოლეგის დახმარება მოგიწიოთ. მაგრამ კოდის ძიებით, ყველა კოდის ერთდროულად, მყისიერად მოძებნაა შესაძლებელი.
ეს მხოლოდ ერთ შედეგს იძლევა. მასში არის მუდმივა, სახელწოდებით queryErrorIsNothing, რომელიც შეცდომის სტრიქონს გულისხმობს.
სიმბოლოების პანელში შეგიძლიათ მუდმივას განმარტება იხილოთ — რომ ის ორ ადგილას გამოიყენება. ერთი ფაილში და მეორე ტესტში. შემოწმებით მიხვდებით, რატომ არის კონკრეტული შეცდომა დაშვებული, ხოლო ტესტზე ნავიგაციით, შეგიძლიათ შეკითხვის მაგალითი იხილოთ, რომელიც პრობლემას იწვევს.
წარმოიდგინეთ, რომ თქვენი კომპანია Kubernetes-ს იყენებს და ინფრასტრუქტურის გუნდი ამბობს, რომ მათ კლასტერში მეხსიერება იწურება. რამდენ მეხსიერებას ითხოვს თქვენი სერვისები? შეგიძლიათ შეამციროთ?
სცადეთ YAML კონფიგურაციის ფაილებისთვის თქვენი გუნდის კოდი მოძებნოთ, რომლებიც სიტყვა «მეხსიერებას» შეიცავს.
დაუყოვნებლივ, შეგიძლიათ Kubernetes-ის კონფიგურაციის ფაილები ნახოთ და გაიგოთ, რამდენი მეხსიერება აქვთ მათ. შეგიძლიათ ამ ძიების ბმული უშუალოდ ინფრასტრუქტურის გუნდს გაუგზავნოთ და საუბარი იმაზე დაიწყოთ, თუ რამდენი მეხსიერებაა გამოყოფილი ამ სერვისებისთვის.
თუ თქვენი გუნდი React-ს იყენებს, შესაძლოა risklySetInnerHTML თქვენთვის ნაცნობი იყოს. ეს საყრდენი (prop) საშუალებას გაძლევთ, ელემენტში HTML სტრიქონის გამოყენებით შეიყვანოთ. თუმცა ეს შეიძლება საშიში იყოს, რაზეც საყრდენის სახელიც მეტყველებს. თუ DOM-ში შეყვანილი სტრიქონი არასანდოა, ამან შეიძლება უსაფრთხოების პრობლემები გამოიწვიოს.
თქვენ შეგიძლიათ, რამდენიმე შედეგი დაუყოვნებლივ ნახოთ. ზოგიერთი მათგანი ლინტერის წესს ექვემდებარება, რომელიც სახიფათო SetInnerHTML-ის გამოყენებას კრძალავს — ეს შესანიშნავია! მაგრამ აქ არის კომპონენტი, სახელწოდებით IssuesShow, რომელიც შეიძლება დაუცველი იყოს.
GitHub-ის მიზანი დეველოპერებისთვის შესაძლებლობის მიცემაა, კრიტიკული ინფორმაცია გაცილებით სწრაფად იპოვონ, კონტექსტში ჩასვან და უფრო პროდუქტიულები გახადო. როგორც თავად ამბობენ, ეს მხოლოდ დასაწყისია.
