Хабр е изпълнен с прогнози и съвети какво да правим следващата година – какви езици да учим, в какви области да се насочим, как да се грижим за здравето си. Звучи вдъхновяващо! Но всяка медал има две страни, и ние се препъваме не само в нещо ново, а по-скоро в това, което правим всеки ден. "Защо никой не ме предупреди!", възкликваме ядосано, обикновено говорейки на себе си. Извикваме огън върху себе си – събрахме за вас списък с неща, които не трябва да правите през 2020 година (или може би винаги).
А гравитацията не беше питана
Бихме искали да подредим антирекомендациите по важност, от най-значимото до най-незначителното. Но те са толкова разпространени, равнозначни и известни на почти всеки, че ще пишем без ред. Какво, да проверим списъка?
Не бива да навлизате в IT, ако всичко е наред
Не учете нова технология, за да смените професията си или да започнете от нулата. Нашето време е прекрасно, защото можем да учим, да сменяме работа, да променяме напълно сферата си – и така до самата пенсия. Това е страхотно, изкушаващо нещо. Но ако сте над 28-30 години, не е разумно да оставяте всичко, за да влезете в IT или да преминете към нов стек (например, ако пишете високо натоварени системи на Java и изведнъж решавате да се занимавате с невронни мрежи на Python). Причината е проста: ще ви е трудно. Първо, конкуренцията с наличните специалисти, които работят с този стек от началото на кариерата си, е висока, второ, ще трябва отново да станете джунор с ниска заплата, и трето, ще ви е морално трудно да сте подчинен на най-ниското стъпало в йерархията. Така че, ако искате да се движите в друга посока, се опитайте да го правите или в рамките на текущата работа и задачи, или развивайте новите знания като хоби, работете по пет проект, за да дойдете на нова работа, не като джунор.
Сменям стековете – само време губя
Не се колебайте между стековете технологии за вашето разработване. Ако пишете проект на един език, използвате определен фреймворк и библиотеки, не е разумно да оставите всичко и да пренапишете на Dart, само защото ви се е сторил интересен. Вземете за правило да намерите обосновка за смяна на технологията – не само на ниво "искам-не мога", но и на финансово и инженерно ниво.
Не трябва да стоите на своето и да ставате бронзови
Да се придържате само към един език или технология и да не учите новото е също толкова крайно, колкото и да сменяте стека с всяка нова технология. Задължително изучавайте нови библиотеки и фреймворкове, не бъдете упорити в убеждението, че всичко полезно е създадено преди вас и е подобрено само от вас. За почти всеки език постоянно излизат обновления, които понякога могат значително да подобрят проекта ви. Не се ленете да следите динамиката на вашия стек и, щом намерите нещо страхотно и полезно, смело го добавяйте в проекта!
Собственото мислене е добро, винаги е добре
Не мислете с чужди глави, собствената е по-добра. За съжаление, някои разработчици седи и чакат, когато им се даде задача да кодират от предишната грешка до края, без да се опитват да внесат нещо свое в проекта, да разработят нова функция, да тестват и да предложат за продукция. Защо да се мъчите, когато главата на екипа или ръководителят на компанията сами ще решат всичко? Ако се разпознахте, имаме лоши новини: пасивната позиция няма да помогне нито в кариерата, нито в развитието. Имате шанс да опитате силите си като инженер-разработчик, а не само като кодер в реален проект, за да разберете накъде да се насочите, какво не ви достига, но предпочитате да отделяте времето си за нещо друго и да правите точно „от това до това“. Такива в съвременния ИТ оцеляват все по-трудно, излизайте от аноксия.
Потребителите – страшни хора
Не преувеличавайте потребителите на вашия софтуер: ако не пишете за програмисти, имайте предвид, че програмата ще се сблъска с непроницаемо неразбиране. Първите няколко дни или седмици потребителят ще мрази софтуера ви, защото „старият не беше толкова тъп“. За да избегнете това, направете чудесна документация и обучителни материали. При инсталиране или покупка много настоятелно намеквайте, че ръководствата трябва да се четат преди да се започне работа с програмата, а не след провал на базата, загуба на парола и самообладание.
Не трябва да подценявате потребителите: те са по-хитри, по-умни и по-любопитни, отколкото си мислите. Ако смятате, че бъгът с формата на променливата и изключението на 138-ото натискане на Enter с интервал от една секунда няма да се появят, грешите — те ще се появят и ще повлияят на работата на вашето приложение по най-странни начини. Работи правилото на дилетанта: той всъщност тестира най-добре. Но потребителите по някаква причина не обичат да откриват бъгове в продукцията — няма никаква ИТ солидарност в това. В крайна сметка, колкото по-сигурни сте в своя софтуер, толкова по-добре. По-добре е да забавите пускането на някои функции, отколкото да ги добавите в работещо приложение и да го направите неочаквано недовършено.
Достатъчно с търсенето в Google!
Спирайте да се обръщате само към Google. Дори няма да спорим — в сферата на разработката с директен запит към търсачката можете да намерите много неща. Колкото по-дълбоко затъввате в търсенето на информация, толкова повече "странични" данни ще получите и ще научите, защото ще откривате нова информация, която не е свързана с вашето запитване, но вероятно ще е полезна в бъдеще. Обращайте се към пълноценни материали, книги, статии и т.н. Язиците и библиотеките имат спецификации, общности, how to и така получавате най-сигурния начин да развивате уменията си като програмист — просто четете документацията, а не търсете чужди локални решения и фрагменти от код. Ами ако вашето решение е по-оптимално, по-бързо и по-добро?
Доверявай, но проверявай
Не използвайте библиотеки и фреймворкове, създадени от трети разработчици, без да проверявате кода и да го адаптирате за своите цели. Нямате никакви основания безусловно да се доверявате на този автор на код, когото изобщо не познавате. Да, различни умишлени вредоносни елементи в чужд код не се срещат толкова често и не е нужно да страдате от параноя, но сляпото копиране на готови части от софтуер в проекта ви може да доведе до непредсказуеми последствия. Затова задължително четете и анализирайте кода преди употреба и провеждайте тестове след внедряване на кода.
Правете бекъпи!
Престанете да не правите резервни копия или да ги съхранявате на същите чужди сървъри, на които хоствате вашия проект. Мислите, че е смешен и ненужен съвет? Но над 700 участници в чата в Телеграм, които преминаха през неприятна ситуация с спирането на известен дата-центр, не мислеха така — какво ли не е имало: от малки проекти до големи сайтове на държавни органи и корпоративни бази 1С и фактуриране. Значителна част от тях са без резервни копия или с резервни копия на същото място. Затова разпределяйте рисковете и съхранявайте резервната копия поне на основното хостинг, на надежден VDS и на вашия локален сървър. В крайна сметка това ще излезе много по-евтино.
Спри да внасяш собственото си в ущърб на проекта
Не правете в работния проект това, което искате, а това, което е нужно на клиентите. Да, изключително е интересно и прекрасно да създадете собствена невронна мрежа, да я обучите и да я внедрите в софтуера си, но ако на вашите клиенти им трябва прост мениджър на контакти, това ще бъде ненужно скъпо излишество. Погледнете как работи проектът, прочетете документацията, разгледайте отзивите и заявките от клиентите и реализирайте онова, което ще придаде бизнес стойност на проекта. Ако искате да творите нещо научно или свръхсложно, започнете с личен проект.
Не код, а кълбо от нерви
Не пишете нечетим и недокументиран код. Познаваме тази особеност: разработчикът пише код както му хрумне, умишлено го обърква, за да не може никой от колегите да разбере какво е написано — своеобразна превенция преди нещо да се е случило. Но вие застрашавате не само компанията (която ви плаща за работа), но и самия себе си: напълно е вероятно сами да не си спомняте какво сте искали да кажете с това непреднамерено объркване. Същото важи и за недокументирания код: разчитайки на собствената си логика на именуване на променливи и функции и на добра памет, след няколко години можете да не си спомняте защо сте избрали точно този цикъл, метод, шаблон и т.н. Документирането на кода и добрата му структура е страхотна услуга както за колегите, така и за работодателя, и преди всичко за самия вас.
Дръж го просто, глупаво
Не усложнявайте кода, решения и проекти. Не е необходимо да изграждате сложна структура и да създавате същности без значимост. Колкото по-сложен е вашият код, толкова повече ще станете негов заложник — ще ви е изключително трудно да го поддържате и развивате. Разбира се, известният принцип KISS („Дръж го просто, глупак“) не важи винаги, но не е измислен без причина: простотата и елегантността на кода са залог за успешното му използване и повторно разглеждане.
Предпазвайте се
Не игнорирайте сигурността — през 2020 година това е буквално престъпление. Дори ако вашата компания, разработка и вие не интересувате злоумышлениците, вас могат да засегнат проблеми, свързани с компрометиране на определен сегмент от мрежата, хостинг доставчика, атака срещу дата център, кражба на пароли от имейли и небезопасно поведение на служители, които могат да откраднат данни от компанията, да изведат клиенти или софтуерния код на целия проект. Ако това е в обсега на вашите възможности и се отнася до вашата компетентност, опитайте се да защитите проектите, с които работите. И не забравяйте да спазвате информационната сигурност, никога не е излишно.
Не плюйте в кладенеца
Не вредете на вашия работодател. Днес комуникациите достигнаха такова ниво, че например всички HR-и в града са драстично запознати помежду си и могат да обменят всяка информация в чатове и затворени групи (както за помощ при намиране на работа, така и да напишат «Василий Иванов, системен архитект, затвори всички акаунти, изтри бекъпи и изключи мрежата, възстановяването отне 3 дни. Не го наемайте»). По този начин вашето поведение ще действа само против вас — понякога дори не помага преместването в друг град или столица. Дори когато се оттегляте с обида, няма по-добра отмъщение от това да станете полезен и страхотен служител на конкурента 🙂 А най-важното, напълно безнаказано.
Не трябва да се прави и така. Но опитът показва, че няма да спрем.
А всъщност, приятели, читайте съвети, но правете така, както смятате за най-добре — защото истинските открития се правят, когато се съмняваме в вече установените истини. Честита Нова година, нека проектите ви бъдат успешни, кариерата — интересна, колегите и ръководителите — адекватни, а животът като цяло — успешен. Общо взето, за Нова година и за нов код!
С любов,
екипът на RegionSoft Developer Studio
През новата година ще продължим да работим за вас и да развиваме мощна десктопна CRM система и прост и удобен хелпдеск и система за тикети .
Източник: habr.com
