კოდირება Java-ში ვისწავლე, კარიერის დასაწყისშიც სწორედ ამ პროგრამირების ენით მიწევდა მუშაობა, ამიტომ უკვე შეჩვეული ვიყავი კომპლექსურ მემკვიდრულ იერარქიებსა და აბსტრაქციის უამრავ ლეიერს. იმის გაგებამ, რომ Go-ს მემკვიდრეობა (inheritance) არ ჰქონდა, ჩემში მაშინვე მისი უარყოფის გრძნობა აღძრა.
დიახ, მქონდა ინფორმაცია მინიმუმ 2 დეველოპერის შესახებ მაინც, რომლებიც ჩემზე უკეთესები იყვნენ და რომლებსაც Go მოსწონდათ. მათ მირჩიეს, რომ წამეკითხა Go-ს თეთრი წიგნი და ამ წიგნმა თვალები ამიხილა. მიუხედავად იმისა, რომ შეჩვეული ვიყავი კომპლექსურ მემკვიდრულ იერარქიებს, ეს იერარქიები წლების განმავლობაში მტანჯავდნენ. ყოველთვის საუკეთესო იერარქიის აგების გზების ძიებაში ვიყავი. Go-ს თეთრი წიგნის წაკითხვა დამეხმარა იმის გაგებაში, რომ ასეთი გზა არ არსებობს. კომპოზიციის პატერნს აქვს თავისი შეცდომები, მაგრამ იგი შემთხვევების 95%-ში უფრო სუფთად გამოიყურება.
Go-ში წერა კომპოზიციის გამოსაყენებლად არ მჭირდებოდა. უფრო მეტად მაინტერესებდა გამომეცადა ეს პროგრამირების ენა და მენახა, რა შესაძლებლობები ჰქონდა მას.
სამწუხაროდ, ჩემი სამსახურის გამო, არ მომეცა Go-ში რაიმეს გაკეთების საშუალება. შესასრულებელი მქონდა PHP-სა და Java-ს პროექტები, რომელთა შორისაც სხვა სამუშაოს დამატება აღარ შემეძლო.
გადავწყვიტე, რომ ამეღო პირველი დამატებითი სამუშაო. აუნაზღაურებადი მუშაობა ჩემთვის ანათემა იყო იმ მომენტისთვის (მიუხედავად იმ ოვერთაიმ სამუშაოებისა, რაც ჩემი კარიერის განმავლობაში მქონია), მაგრამ ეს პროექტი სახალისოდ გამოიყურებოდა. ყოველთვის მსიამოვნებდა აქციებში ინვესტირება და ჩემი დიდი სურვილი იყო მქონოდა უკეთესი ხელსაწყოები იმ მონაცემების სამართავად, რომელსაც ვიყენებდი. ეს იყო საუკეთესო შესაძლებლობა Go-ს სასწავლად.
თავად პროექტი დიდად შორს არ წასულა (მუშაობა 2015 წელს შევწყვიტე), მაგრამ ვისწავლე ისეთი რაღაცები, რასაც დღემდე ვიყენებ. ვისწავლე როგორი ეფექტურია კომპოზიციური პატერნი. ასევე გავერკვიე უამრავ ქეისში, სადაც კომპოზიცია რეალურად ძალიან რთულია და, პირიქით, უმჯობესია მემკვიდრეობის არსებობა.
რაც ყველაზე მნიშვნელოვანია, ვისწავლე, რომ შესაძლებელია კომპლექსური აპლიკაციის აგება გატენილი ფრეიმვორქის გარეშე. ამის შემდეგ აღარასდროს დავტანჯულვარ Spring-ის განახლებებით.
ახალგაზრდები დაინტერესებული არიან ტექნოლოგიებით, მაგრამ არ იციან როგორ ან სად დაიწყონ სწავლა, ჩვენსკვალიფიციურ სპეციალისტებთან, საერთაშორისო აკადემიაში, მოზარდებს შეუძლიათ პროგრამირების შესწავლა!
მიუხედავად იმისა, რომ 2021 წლიდან უფრო მეტად Python-ში ვმუშაობ, ვიდრე Go-ში, უპირატესობა Flask-ს მივანიჭე, რომელიც უფრო მეტად ბიბლიოთეკაა, ვიდრე ფრეიმვორქი. ჩემმა გამოცდილებამ Go-ში მასწავლა, რომ ცხოვრება ფრეიმვორქის გარეშე ბევრად მარტივია. მართალია, უფრო მეტ დროს ხარჯავ პროექტის წინასწარ თვითუზრუნველყოფაზე (ბუთსტრაპინგი), მაგრამ გრძელვადიანი დეველოპმენტი ბევრად უფრო სწრაფად და უპრობლემოდ მიმდინარეობს. ყოველთვის, როდესაც „ხარჯავთ“ უამრავ დროს სტანდარტული კოდის წერაში, ზოგავთ დროს ფრეიმვორქის აბსტრაქტული ლეიერის უცნაური პრობლემების გამოსწორებაზე, ან განახლების შეუთავსებლობების ხარვეზებზე.
მას შემდეგ ყოველთვის ვმუშაობ დამატებით პროექტებზე. ყველა პროექტმა მასწავლა რაღაც ახალი, რასაც მუშაობის დროს ვიყენებ. მოდი, განვიხილოთ ზოგიერთი მათგანი.
თუ კოდს მხოლოდ სამსახურში წერდი, ალბათ ყოველთვის მოცემული გქონდა საბაზისო კოდი. მიუხედავად ყველა იმ წვლილისა და გაუმჯობესებისა, რაც პროექტებში შეიტანე, აუცილებლად იქნებოდა სისტემის რაღაც ნაწილები, რომლებიც უკვე დაწერილი იყო და შენ არასდროს შეხებიხარ. ეს არის შენი შესაძლებლობა დაიწყო პროექტზე მუშაობა ნულიდან. ჩემთვის ასეთ რამეს წარმოადგენდა სისტემაში შესვლა, ანუ - „ლოგინი“. უამრავ ვებ აპლიკაციაზე მიმუშავია. უამრავი მათგანისთვის გამუმჯობესებია ლოგინის ნაკადები (login flow). მაგრამ არასდროს ამიგია ჩემი სისტემა (ან ამირჩევია სიცოცხლისუნარიანი მესამე მხარე). უამრავი რამ იყო სასწავლი.
ასევე 2015 წლამდე ჩემი კარიერის უმეტესი ნაწილი ბექ-ენდ დეველოპერად გავატარე, რომელიც devops-ში მუშაობდა. სწორედ ამიტომ იყო, რომ ჩემს პირველ დამატებით პროექტს GUI-ს ნაცვლად მხოლოდ CLI ჰქონდა. ფრონტ-ენდ დეველოპმენტი ჩემთვის ყოველთვის ქაოსურად ჟღერდა. მას შესახებ ასევე უამრავი სხვადასხვა აზრი არსებობდა. დამატებით პროექტებზე მუშაობამ მომცა ის თავისუფლება, რომ მესწავლა ფრონტ-ენდ დეველოპმენტი დამოუკიდებლად, ამ ქაოსის მოსმენის გარეშე. შემეძლო მეცადა ნებისმიერი ფრეიმვორქი (Vanilla JS, სამწუხაროდ, ჯერ კიდევ არ არის იმ ეტაპზე, როდესაც მის გარეშე გადარჩენას შეძლებთ). შემეძლო მეცადა სხვადასხვა პატერნები, სანამ ისეთს არ ვიპოვიდი, რომელიც მომეწონებოდა. შემეძლო ხელახლა ამეგო მთლიანი პროექტი მხოლოდ იმიტომ, რომ მეცადა მისი შექმნის ახალი გზები.
ძალიან რთულია უპოვო გამართლება მთლიანი პროექტის ხელახლა აგებას შენს სამსახურში, მხოლოდ იმ მიზეზით, რომ ახალი რამის სწავლა გსურს.
მაგრამ მაინც, იტერაცია არის სასწავლო პროცესის ნაწილი (გამეორება ცოდნის დედაა). აპლიკაციის ბირთვული სტრუქტურა არის სასწავლად ყველაზე მნიშვნელოვანი და გასამეორებლად ყველაზე რთული ნაწილი. დამატებითი პროექტები გაძლევს გამეორების საშუალებას. დარეგისტრირდი Dynomantle-ზე და ნახე, როგორ შორს წავედი ფრონტ-ენდში.
ეს ასევე შეესაბამება ავტომატურ ტესტირებასაც. უამრავ ადგილას მიმუშავია, სადაც ავტომატური ტესტირება ჰქონდათ, მაგრამ მას ყოველთვის ჰქონდა ნაკლოვანებები სხვადასხვა ასპექტებში. მაგ., Selenium-ის ტესტები ძალიან ნელია.
პროექტი, რომელზეც Dynomantle-მდე ვმუშაობდი იყო იმეილ კლიენტი, სახელწოდებით Maleega. მთლიანი სატესტო კომპლექტი 3-ჯერ თავიდან ავაწყე. Dynomantle-ისთვის ორჯერ. თითოეულ ხელახალ აწყობას ძალიან ბევრი კვირა დასჭირდა. კიდევ ერთხელ გავიმეორებ, რომ ამის გაკეთებას არცერთ სამსახურში არ აქვს გამართლება.
მიუხედავად ამისა, საბოლოოდ მივაღწიე ავტომატიზირებული ტესტირების სტრატეგიას, რომელიც ნამდვილად ზალიან კარგად მუშაობს (თუმცაღა მას აქვს მცირე ხარვეზები CSS სტილების ტესტირებაში. ვინმემ იცის საერთოდ როგორ დატესტოს სტილები ეფექტურად?) ეს სტრატეგია ჩემი მთავარი სამუშაოსთვის ბევრჯერ გამომიყენებია და იგი ფენომენალურად მუშაობს.
რაც ყველაზე მნიშვნელოვანია, თუ მენეჯმენტში ხარ, დამატებითი პროექტები შენი პროგრამირების უნარებს უფრო მეტად წვრთნის. ერთ-ერთი დიდი პრობლემა, რასაც ინჟინერიის მენეჯერებში ვხედავ არის, ნაკლები თავდაჯერებულობა ან რწმენა პროექტების პროგრესში. ზოგიერთი მათგანის უნარი კოდირებაში არის შესუსტებული და ამიტომ წაკითხვისას მათი გაგება უჭირთ. შედეგად ვიღებთ სტატუსის განახლებების მუდმივ მოთხოვნას, რასაც დეველოპერების ყურადღება სხვა რამეზე გადააქვს და ასევე საჭიროებას რთული პროცესის დასამატებლად ზუსტი შეფასებების მისაღებად. ჩნდება უნდობლობა დეველოპერებსა და მენეჯერებს შორის.
არსებობს უამრავი გზა ამის შესასუსტებლად. თუმცა მე მსიამოვნებს დამატებით პროექტებზე მუშაობა და ჩემთვის ერთ-ერთი უპირატესობაა პროგრამირების უნარების მუდმივი ვარჯიში. სამსახურში საბაზისო კოდის გაუმჯობესებაზე არ ვმუშაობ, რადგან ჩემი ვალდებულებები საჭირო დროის გამონახვას ართულებს. საბაზისო კოდზე მუშაობა ჩემთვის იქცეოდა ტვირთად და არასდროს გვეცოდინებოდა, როდის შევძლებდი რამის შესრულებას. დამატებითი პროექტები ჩემს განრიგს შესანიშნავად ერგება, ისე რომ, არ მიწევს ნერვიულობა დედლაინებსა და კომპანიის მიზნებზე.
ერთი რამ, რაც მინდა, რომ დავაზუსტო არის - არ არის აუცილებელი გქონდეთ დამატებითი სამუშაო. დამატებით პროექტებზე მუშაობა განტვირთვის ერთ-ერთი მეთოდია.
მე ვგულისხმობ, რომ თუ აქამდე გქონდათ სურვილი გემუშავათ სხვა პროექტებზე, მაგრამ გჭირდებოდათ მოტივაცია, იმედია, ეს პოსტი ამაში დაგეხმარათ. და თუ თქვენი კომპანია ეწინააღმდეგება თანამშრომლებს, რომლებიც დამატებით პროექტებზე მუშაობენ, იმედია ეს პოსტი რამდენიმე საფუძვლიან არგუმენტს მოგცემთ.
დაეუფლე აქტუალურ პროფესიებს - შემოგვიერთდით სტეპერების დიდ ოჯახში!
IT Academy Stepლიდერი IT სფეროში, ახლა უკვე 100+ფილიალით!
+995 577 538 549ქ.თელავი,ნადიკვრის#23
+995 (32) 215-55-51ქ.თბილისი,ა.ყაზბეგის34/34ბ
გამოიწერეთ ჩვენი გვერდი სოციალურ ქსელებში
