Поддержка  •  Дневник  •  Без рекламы  •  О сайте  •  Реклама  •  Поставить баннер  •  Прислать  •  Хроника  •  Translate Гости: 3    Участники: 0 Авторизация Авторизация   Регистрация 
Метод Научного Тыка
RULVEN
Поиск  
Blackball iMag | интернет-журнал
Каталог


Начало » Разработка ПО » Что айтишнику не стоит делать в 2020?
Мне повезёт!

Что айтишнику не стоит делать в 2020?


Добавлено: Пн 02.11.2020 • Sergeant
Источник: источник
Просмотров: 232
Комментарии: 0


Хабр полон прогнозов и советов о том, что делать в следующем году — какие языки учить, в какие сферы сворачивать, как поступать со своим здоровьем. Звучит вдохновляюще! Но у любой медали две стороны, и мы спотыкаемся не только в чём-то новом, а по большей части в том, что делаем каждый день. «Ну почему меня никто не предупредил!», — раздражённо восклицаем мы, обычно обращаясь к самому себе. Вызываем огонь на себя — мы собрали для вас список того, что НЕ стоит делать в 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 суток. Не берите его на работу»). Таким образом, ваше поведение сыграет исключительно против вас — и иногда не поможет даже релокация в другой город или столицу. Даже если вы уходите с обидой, нет лучше мести, чем стать полезным и классным сотрудником конкурента :-) А главное, полностью безнаказанно.

Так делать тоже не стоит. Но, как показывает опыт, не перестанем

А вообще, друзья, читайте советы, но делайте так, как вам кажется лучшим — ведь настоящие открытия совершаются тогда, когда мы сомневаемся в уже открытых истинах.



Мне нравится 0   Мне не нравится 0



Комментарии

Чтобы добавить видео с YouTube, нужно написать [@youtube=xxxxx] , где xxxxx – ID видео.


Комментарии: 0
Нет ни одного комментария.
RSS-лента
Поделиться ссылкой:
25 самых дорогих видов шоколада в мире 25 самых дорогих видов шоколада в мире
Путь к предварительным ласкам Путь к предварительным ласкам
Физрук
Коктейль виски со Швепсом – оригинальные и согревающие рецепты Коктейль виски со Швепсом – оригинальные и согревающие рецепты
Что такое технический долг и как им управлять Что такое технический долг и как им управлять
Настойка и наливка: в чём разница Настойка и наливка: в чём разница
Бутерброды со шпротами, которые станут вашими любимыми Бутерброды со шпротами, которые станут вашими любимыми

Новое
Что такое технический долг и как им управлять 2 дня назад, 09:09
Что такое технический долг и как им управлять
20 отличных рецептов куриных сердечек на мангале Сб 18.05.2024
20 отличных рецептов куриных сердечек на мангале
Какие полочные акустические системы стоит выбрать в 2023-2024 годах? Ср 15.05.2024
Какие полочные акустические системы стоит выбрать в 2023-2024 годах?
Архитектуры разработки ПО Пн 13.05.2024
Архитектуры разработки ПО
Сб 11.05.2024
Технический долг. Как не обанкротиться
20 рецептов из горбуши, которые станут вашими любимыми Сб 11.05.2024
20 рецептов из горбуши, которые станут вашими любимыми
Как работает спидометр в машине: вы всегда хотели это знать, но никто не мог объяснить на пальцах Ср 08.05.2024
Как работает спидометр в машине: вы всегда хотели это знать, но никто не мог объяснить на пальцах
5 ошибок при разработке высоконагруженных сервисов Пн 06.05.2024
5 ошибок при разработке высоконагруженных сервисов
20 способов приготовить куриные голени в духовке Вс 05.05.2024
20 способов приготовить куриные голени в духовке
Жаркое из курицы: 20 лёгких и вкусных рецептов Сб 04.05.2024
Жаркое из курицы: 20 лёгких и вкусных рецептов
Книги
Designing Data-Intensive Applications Вт 14.05.2024
Designing Data-Intensive Applications
Год: 2017
Fundamentals of Software Architecture Вт 07.05.2024
Fundamentals of Software Architecture
Год: 2020
Refactoring with C# Вт 23.04.2024
Refactoring with C#
Год: 2023

Разработано на основе BlackNight CMS
Release v.2024-05-19
© 2000–2024 Blackball
Дизайн & программирование:
О сайтеРеклама
Visitors
Web-site performed by Sergey Drozdov
BlackballРекламаСтатистикаПоддержка | МузыкаПлейлистыКиноВидеоИгрыАудиоПрограммыСтатьиКартинкиЮморФорумДневник сайтаПрислать контент