Хабр полон прогнозов и советов о том, что делать в следующем году — какие языки учить, в какие сферы сворачивать, как поступать со своим здоровьем. Звучит вдохновляюще! Но у любой медали две стороны, и мы спотыкаемся не только в чём-то новом, а по большей части в том, что делаем каждый день. «Ну почему меня никто не предупредил!», — раздражённо восклицаем мы, обычно обращаясь к самому себе. Вызываем огонь на себя — мы собрали для вас список того, что НЕ стоит делать в 2020 году (а может, и всегда).
А гравитацию-то и не спросили
Нам бы очень хотелось расставить анти-рекомендации по порядку, от самого важного к самому незначительному. Но они настолько распространены, равнозначны и знакомы едва ли не каждому, что будем писать вразнобой. Ну что, прочекаем список?
Не надо идти в айти, если всё хорошо
Не изучайте новую технологию, чтобы сменить профессию или начать с нуля. Наше время прекрасно тем, что можно обучаться, менять работу, в корне менять сферу — и так хоть до самой пенсии. Это классная, соблазнительная штука. Но если вам больше 28-30, не стоит бросать всё ради того, чтобы войти в IT или уйти в новый стек (например, вы пишете высоко нагруженные системы на Java и внезапно решаете уйти в нейросети на Python). Причина простая: вам будет непросто. Во-первых, высока конкуренция со стороны специалистов, которые «сидят» на этом стеке с начала своей карьеры, во-вторых, вам придётся снова стать джуниором с низкой зарплатой, в-третьих, вам будет морально непросто стать подчинённым самого низкого уровня иерархии. Поэтому, если хотите двигаться в другую сторону, старайтесь это делать либо в русле текущей работы и текущих задач, либо развивайте новое знание как хобби, пилите пет-проект, чтобы прийти на новую работу уже не джуниором.
Стек на стек менять — только время терять
Не мечитесь между стеками технологий для своей разработки. Если вы пишете проект на одном языке, используете определённый фреймворк и библиотеки, не стоит бросать всё к чертям и переписывать на Dart, только потому что он показался вам интересным. Возьмите за правило найти обоснование для смены технологии — не только на уровне «хочу-не могу», но и на финансовом, и на инженерном уровне.
Не нужно стоять на своём и бронзоветь
Упираться в один язык или технологию и не изучать новое — такая же крайность, как менять стек с каждой новой технологией. Обязательно изучайте новые библиотеки и фреймворки, не будьте упрямы в сознании того, что всё лучше придумано до вас и допилено исключительно вами. Практически для каждого языка постоянно выходят обновления, которые иногда могут здорово улучшить ваш проект. Не ленитесь следить за динамикой вашего стека и, как только найдёте что-то крутое и полезное, — смело тащите в проект!
Своя голова хорошо, всегда хорошо
Не думайте чужими головами, своя — лучше. Увы, некоторые разработчики сидят и ждут, когда им поступит задание кодить от предыдущего error-а и до end-а, не пытаясь внести в проект что-то своё, разработать новую функцию, протестировать и предложить в продакшен. Зачем утруждаться, когда есть голова тимлида или руководителя компании, которые сами всё решат? Если вы узнали себя, то у нас плохие новости: пассивная позиция не поможет ни в карьере, ни в развитии. У вас есть шанс попробовать свои силы инженера-разработчика, а не кодера в настоящем боевом проекте и понять, куда двигаться, чего не хватает, но вы предпочитаете потратить своё время на что-то другое и делать ровно «от сих до сих». Такие в современном айти выживают всё хуже, выходите из анабиоза.
Пользователи — страшные люди
Не переоценивайте пользователей вашего программного обеспечения: если вы пишете не для программистов, рассчитывайте на то, что программа столкнётся с непробиваемым непониманием. Первые несколько дней или недель пользователь будет ненавидеть ваш софт, потому что «старый был не такой тупой». Чтобы этого избежать, делайте классную документацию и обучающие материалы. При установке или покупке очень навязчиво намекните, что мануалы стоит читать до начала работы с программой, а не после краха базы, потери пароля и самоконтроля.
Недооценивать пользователей тоже не стоит: они хитрее, умнее и любопытнее, чем вы думаете. Если вы считаете, что тот баг с форматом переменной и эксепшен на 138-м нажатии Enter с интервалом в секунду не всплывут, вы ошибаетесь — всплывут и повлияют на работу вашего приложения самым причудливым образом. Работает правило дилетанта: именно он справляется с тестированием лучше всего. Но пользователям почему-то не нравится находить баги на продакшене — никакой в них айтишной солидарности. В общем, чем больше вы уверены в своём ПО — тем лучше. В конце концов, лучше задержать релиз некоторых функций, чем добавить их в работающее приложение и сделать его внезапно сырым.
Хватит гуглить!
Перестаньте обращаться к одному только Google. Даже спорить не будем — в сфере разработки прямым запросом к поисковику можно найти очень многое. Чем глубже вы закопаетесь в поисках информации, тем больше «боковых» данных вы получите и больше узнаете, потому что будете узнавать что-то новое, не связанное с вашим запросом, но вероятно нужное в будущем. Обращайтесь к полноценным материалам, книгам, статьям и т.д. У языков и библиотек есть спецификации, коммьюнити, how to и таким образом вы получаете самый надёжный способ развивать навыки программиста — просто читать документацию, а не искать чужие локальные решения и фрагменты кода. А вдруг ваше решение будет оптимальнее, быстрее и круче?
Доверяй, но проверяй
Не используйте библиотеки и фреймворки, созданные сторонними разработчиками, не проверяя код и не адаптируя его под свои цели. У вас нет никаких оснований безоговорочно доверять этому автору кода, которого вы вообще не знаете. Да, различные преднамеренные вредоносные элементы в стороннем коде встречаются не так часто и паранойей страдать не стоит, но слепое копирование готовых частей ПО в свой проект может привести к непредсказуемым последствиям. Поэтому обязательно читайте и анализируйте код перед использованием и проводите тестирование после имплементации кода.
Делайте бэкапы!
Прекратите не делать бэкапы или держать их на тех же сторонних серверах, где хостится ваш проект. Думаете, смешной и напрасный совет? А вот более 700 участников чата в Телеграме, попавших в недавнюю неприятную ситуацию с остановкой одного известного дата-центра, так не думали — чего там только не было: от пет-проектов до крупных сайтов гос. органов и корпоративных баз 1С и биллинга. Значительная часть — без бэкапов или с бэкапами там же. Так что распределяйте риски и храните бэкап как минимум на основном хостинге, на каком-нибудь надёжном VDS и у себя на локальном сервере. В конечном итоге это выйдет гораздо дешевле.
Хватит проносить своё в ущерб проекту
Не делайте в рабочем проекте то, что хочется вам, а делайте то, что нужно клиентам. Да, безумно интересно и здорово создать свою нейронную сеть, обучить её и внедрить в свой софт, но если вашим клиентам нужен простой контакт-менеджер, это будет удорожающее излишество. Посмотрите, как работает проект, прочитайте документацию, прочитайте отзывы и заявки от клиентов и реализуйте то, что придаст проекту бизнес-ценность. Если хочется творить что-то научное или сверх сложное, начните с собственного проекта.
Не код, а комок нервов
Не пишите нечитаемый и недокументированный код. Нам знакома эта фишка: разработчик пишет код как бог на душу положит, специально его немного запутывает, чтобы никто из коллег не мог разобраться в написанном — такая своеобразная профилактическая месть до того, как что-то произошло. Однако вы подвергаете риску не только компанию (которая вам платит деньги за работу), но и самого себя: вполне вероятно, что вы сами не вспомните, что хотели сказать этой непреднамеренной обфускацией. То же самое с недокументированным кодом: полагаясь на свою логику именования переменных и функций и хорошую память, через пару лет вы можете не вспомнить, почему выбрали именно этот цикл, метод, паттерн и т.д. Документирование кода и хорошая его структура — крутая услуга коллегам, работодателю и прежде всего самому себе.
Keep it simple, stupid
Не усложняйте код, решения и проекты. Не нужно городить сложную структуру и плодить сущности без особой значимости. Чем сложнее ваш код, тем больше вы становитесь его заложником — вам будет максимально сложно его поддерживать и развивать. Конечно, знаменитый принцип KISS («Keep it simple, stupid») подходит не всегда, но он создан не зря: простота и изящность кода — залог успешного его применения и переиспользования.
Предохраняйтесь
Не игнорируйте безопасность — в 2020 году это буквально преступно. Даже если ваша компания, разработка и вы не интересны злоумышленникам, вас могут затронуть проблемы, связанные с поражением какого-то сегмента сети, хостинг-провайдера, с атакой на дата-центр, с хищением паролей почты и с небезопасным поведением сотрудников, которые могут украсть данные из компании, увести клиентов или программный код всего проекта. Если это в ваших силах и относится к зоне компетенции, постарайтесь защитить те проекты, с которыми работаете. Ну и сами соблюдайте информационную безопасность, это ещё никому не мешало.
Не плюйте в колодец
Не гадьте своему работодателю. На сегодняшний день коммуникации достигли такого уровня, что, например, все HR-ы города заочно знакомы между собой и могут обменяться любой информацией в чатах и закрытых группах (как помочь трудоустроиться, так и написать «Василий Иванов, системный архитектор, перед уходом убил все учётные записи, затёр бэкапы и отключил сеть, восстановление заняло 3 суток. Не берите его на работу»). Таким образом, ваше поведение сыграет исключительно против вас — и иногда не поможет даже релокация в другой город или столицу. Даже если вы уходите с обидой, нет лучше мести, чем стать полезным и классным сотрудником конкурента :-) А главное, полностью безнаказанно.
Так делать тоже не стоит. Но, как показывает опыт, не перестанем
А вообще, друзья, читайте советы, но делайте так, как вам кажется лучшим — ведь настоящие открытия совершаются тогда, когда мы сомневаемся в уже открытых истинах.