რა არ უნდა გააკეთოს IT სპეციალისტმა 2020 წელს?

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

მაგრამ მათ არ ჰკითხეს გრავიტაციის შესახებ

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

არ არის საჭირო IT-ზე წასვლა, თუ ყველაფერი კარგადაა

ნუ ისწავლით ახალ ტექნოლოგიას კარიერის შესაცვლელად ან თავიდან დასაწყებად. ჩვენი დრო მშვენიერია, რადგან შეგიძლიათ ისწავლოთ, შეცვალოთ სამუშაო, რადიკალურად შეცვალოთ თქვენი სფერო - და ასე შემდეგ, თუნდაც პენსიაზე გასვლამდე. მაგარი, მაცდუნებელი რამეა. მაგრამ თუ თქვენ ხართ 28-30 წელზე მეტი, არ უნდა დათმოთ ყველაფერი იმისათვის, რომ შეხვიდეთ IT-ში ან გადახვიდეთ ახალ სტეკზე (მაგალითად, თქვენ წერთ ჯავაში მაღალ დატვირთულ სისტემებს და უცებ გადაწყვეტთ პითონის ნერვულ ქსელებში შესვლას). მიზეზი მარტივია: ადვილი არ იქნება თქვენთვის. ჯერ ერთი, მაღალი კონკურენციაა სპეციალისტების მხრიდან, რომლებიც კარიერის დაწყებიდან ამ დასტაზე „სხედან“, მეორეც, მოგიწევთ ისევ უმცროსი გახდეთ დაბალი ხელფასით და მესამე, მორალურად გაგიჭირდებათ. გახდეს იერარქიის ყველაზე დაბალი დონის ქვეშევრდომი. ამიტომ, თუ გსურთ სხვა მიმართულებით გადაადგილება, შეეცადეთ ეს გააკეთოთ ან თქვენი მიმდინარე სამუშაოსა და მიმდინარე ამოცანების შესაბამისად, ან განავითაროთ ახალი ცოდნა, როგორც ჰობი, დაიწყეთ შინაური ცხოველების პროექტი ისე, რომ როცა ახალ სამსახურში მიხვალთ აღარ იყოს უმცროსი. 

დასტას დასტას შეცვლა უბრალოდ დროის კარგვაა

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

არ არის საჭირო ფეხზე დგომა და ბრინჯაოსფერი

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

შენი თავი კარგია, ყოველთვის კარგი

არ იფიქრო სხვის თავში, შენი უკეთესია. სამწუხაროდ, ზოგიერთი დეველოპერი ზის და ელოდება, სანამ არ მიიღებენ დავალებას წინა შეცდომიდან ბოლომდე კოდირებისთვის, პროექტში საკუთარი წვლილის შეტანის მცდელობის გარეშე, განავითარონ ახალი ფუნქცია, შეამოწმონ და შესთავაზონ წარმოებისთვის. რატომ ინერვიულოთ, როდესაც არის გუნდის ლიდერი ან კომპანიის მენეჯერი, რომელიც თავად გადაწყვეტს ყველაფერს? თუ საკუთარ თავს აღიარებთ, მაშინ ცუდი ამბავი გვაქვს: პასიური პოზიცია არ დაგვეხმარება არც კარიერაში და არც განვითარებაში. თქვენ გაქვთ შანსი სცადოთ თქვენი ძალა, როგორც განვითარების ინჟინერი, და არა კოდირებელი, რეალურ საბრძოლო პროექტში და გაიგოთ, სად უნდა წახვიდეთ, რა აკლია, მაგრამ გირჩევნიათ დახარჯოთ თქვენი დრო სხვა რამეზე და გააკეთოთ ზუსტად „აქედან ახლა." ასეთი ადამიანები უარესად და უარესად გადარჩებიან თანამედროვე IT-ში, გამოდიან შეჩერებული ანიმაციიდან. 

მომხმარებლები საშინელი ხალხია

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

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

შეწყვიტე გუგლინგი!

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

ენდობა, მაგრამ გადაამოწმეთ

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

შექმენით სარეზერვო ასლები!

ნუ გააკეთებთ სარეზერვო ასლებს ან არ შეინახავთ მათ იმავე მესამე მხარის სერვერებზე, სადაც თქვენი პროექტი მასპინძლობს. როგორ ფიქრობთ, ეს სასაცილო და უსარგებლო რჩევაა? მაგრამ Telegram-ზე ჩეთის 700-ზე მეტი მონაწილე, რომლებიც ბოლოდროინდელ უსიამოვნო სიტუაციაში აღმოჩნდნენ ერთი ცნობილი მონაცემთა ცენტრის გამორთვით, ასე არ ფიქრობდნენ - იქ ყველაფერი იყო: შინაური ცხოველების პროექტებიდან დიდ სამთავრობო ვებსაიტებამდე. ხელისუფლება და კორპორატიული 1C და ბილინგის მონაცემთა ბაზები. მნიშვნელოვანი ნაწილი არის სარეზერვო ასლების გარეშე ან იმავე ადგილას სარეზერვო ასლებით. ასე რომ, გაანაწილეთ რისკები და შეინახეთ სარეზერვო საშუალება მინიმუმ მთავარ ჰოსტინგზე, ზოგიერთ საიმედო VDS-ზე და თქვენს ლოკალურ სერვერზე. გრძელვადიან პერსპექტივაში ის გაცილებით იაფი იქნება. 

შეწყვიტე საკუთარი თავის მიყვანა პროექტის საზიანოდ

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

არა კოდი, არამედ ნერვების შეკვრა

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

შეინახე მარტივი, სულელო

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

Დაიცავი შენი თავი

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

ჭაში არ შეაფურთხო

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

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

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

Სიყვარულით,
RegionSoft დეველოპერის სტუდიის გუნდი

ახალ წელს ჩვენ გავაგრძელებთ თქვენთვის მუშაობას და განვავითარებთ დესკტოპის მძლავრ CRM სისტემას RegionSoft CRM და მარტივი და მოსახერხებელი დამხმარე მაგიდა და ბილეთების სისტემა ZEDLine მხარდაჭერა.

წყარო: www.habr.com