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