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