კოდექსზე დამოკიდებულებები ეშმაკია.

თქვენი დამოკიდებულებები ყოველ ჯერზე დაწვება.
”ცვლილება ერთადერთი მუდმივია…” - ჰერაკლიტუსი (ფილოსოფოსი)

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

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

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

20+ წლის შემუშავების, დიზაინის შექმნისა და დაპროექტების დაპროექტების შემდეგ, მე ვაფასებ ორი მნიშვნელოვან ჭეშმარიტებას:

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

ეს სტატია ეხება ამ ორი ჭეშმარიტების შერიგებას, რათა ჩვენს აპებს ჰქონდეთ გრძელვადიანი გადარჩენის უდიდესი შანსი.

კურდღლის ხვრელი მართლაც ძალიან ღრმაა.

თუ ჩვენ დავიწყებთ ყველაფერ რამეზე, რაც ჩვენს ვებ – პროგრამებზეა დამოკიდებული, ადვილია ვიფიქროთ ათეულობით და მეტზე, სანამ ვერ მივიღებთ კოდს:

  • Ძალა
  • დაკავშირება
  • ფეიერლი
  • DNS
  • სერვერის აპარატურა (CPU, Disk, Ram,…)
  • გაცივება
  • ვირტუალიზაციის პლატფორმა
  • კონტეინერების პლატფორმა
  • Ოპერაციული სისტემა
  • ვებ სერვერის პლატფორმა
  • პროგრამის სერვერის პლატფორმა
  • ვებ – ბრაუზერი

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

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

1. დამოკიდებულებები, რომელსაც ვაკონტროლებთ

ეს არის ჩვენს მიერ ან ჩვენი ორგანიზაციის მიერ დაწერილი და საკუთრებული კოდი.

2. დამოკიდებულებები, რომელსაც ჩვენ ვერ ვაკონტროლებთ

ეს არის მესამე პირის გამყიდველი ან ღია პროგრამული უზრუნველყოფის საზოგადოების მიერ დაწერილი კოდი.

3. დამოკიდებულებები ერთხელ მოიხსნა

ეს არის იმ კოდის დამოკიდებულებები, რომელზეც დამოკიდებულია მესამე მხარის კოდების დამოკიდებულება. (თქვი, რომ სამჯერ ჩქარა!)

ჩვენ ძირითადად ვისაუბრებთ იმაზე, თუ რა დამოკიდებულება არ გვაქვს.

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

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

რატომ არის კარგი მესამე მხარის კოდექსის დამოკიდებულებები

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

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

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

Google– ის საძიებო და გვერდების რანგის ალგორითმი, Facebook– ის ვადების გაფილტვრა, Netflix– ის „თქვენთვის რეკომენდებული“ განყოფილება და მონაცემთა შეკუმშვის ალგორითმები - ყველა ამ მახასიათებლის უკან არსებული კოდი არის „საიდუმლო სოუსი“.

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

რატომ არის ცუდი მესამე მხარის კოდექსის დამოკიდებულებები

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

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

არ ინერვიულოთ, ამ სტატიის ბოლოს, თქვენ იპოვით ახალ იმედს.

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

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

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

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

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

ცუდი და ცუდი ცუდი დაბალანსება

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

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

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

ადაპტერის ნიმუშის დიაგრამა Dofective.com– დან

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

წარმოგიდგენიათ, რომ ნებისმიერი React ბიბლიოთეკა უნდა შეფუთოთ (მათ შორის JSX)? რაც შეეხება jQuery- ს, ან Angular- ს ან Java- ს საგაზაფხულო ჩარჩოს შესახებ? ეს სწრაფად ხდება კოშმარი.

ამ დღეებში გირჩევთ უფრო ნიუანსირებულ მიდგომას…

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

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

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

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

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

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

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

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

ზოგჯერ ეს ნიშნავს, რომ მესამე მხარის ბიბლიოთეკას „არა“ უთქვამთ, ნამდვილად მაგარია, ან ნამდვილად გსურთ გამოიყენოთ ერთი მიზეზის გამო. Იყავი ძლიერი. მერწმუნე, ის გადაგიხდის. უბრალოდ ჰკითხეთ ყველა იმ ადამიანს, ვინც ინვესტიცია მოახდინა Angular– ის პირველივე გამოშვებაში, ან ჩემს ყოფილ კლიენტზე, რომელიც იყენებდა პარსეს ყველგან. ეს არ არის სახალისო. Დამიჯერე.

ლაპარაკი მხიარული, გადახედეთ ამ…

დამოკიდებულების გრაფიკი TinyTag explorer- ისთვის

ზემოთ მოყვანილი სურათი არის დამოკიდებულების გრაფიკი პროგრამაზე, სახელწოდებით TinyTag Explorer.

თქვენი არსებითი აპებისთვის დამოკიდებულების გრაფიკის შექმნა არის შესანიშნავი გზა იმისთვის, რომ გაითვალისწინოთ თქვენი დამოკიდებულების მიერ რისკის დონე. მე ჩამოვაყალიბე უფასო ხელსაწყოების ჩამონათვალი, რომლებიც ზემოთ მოცემულ გრაფიკებს ქმნის სხვადასხვა ენაზე, JavaScript, C #, Java, PHP და Python, მათ შორის. აქ შეგიძლიათ მიიღოთ.

დამეხმარე სხვების დახმარება

მსურს დავეხმაროთ იმდენი დეველოპერს, რაც მათ ცოდნასა და გამოცდილებასთან ერთად გავზიარებ. გთხოვთ დამეხმაროთ ქვემოთ მოცემულ ღილაკზე ❤ რეკომენდაციის (მწვანე გულის) დაჭერით.

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