НСПК / 24.12.24 / перетяжка / 2W5zFK76vmn
НСПК / 24.12.24 / перетяжка / 2W5zFK76vmn
НСПК / 24.12.24 / перетяжка / 2W5zFK76vmn

10 ошибок начинающих разработчиков

Несмотря на сотни руководств и книг, начинающие разработчики продолжают допускать разные ошибки. В статье описаны 10 самых распространённых из них.

13К открытий13К показов

Разработка программного обеспечения — далеко не новая профессия, ей несколько десятков лет. За это время для новичков, которые только что пришли в профессию, сотни авторов написали тысячи книг и руководств. Несмотря на это, начинающие разработчики продолжают допускать ошибки. Основатель первого в России буткемпа для программистов Elbrus Георгий Бабаян помогает разобрать 10 самых распространённых ошибок новичков.

Слишком долгая работа над одной задачей

В школе или институте практически каждый получал «лайфхак» относительно контрольной или экзамена: если что-то не получается, не задерживайся над решением проблемной задачи, иди дальше. Когда решишь все, что можно решить быстро, возвращайся к проблемному заданию. В противном случае экзамен можно и завалить, потратив все время на поиск решения первой же задачи.

Это важный совет, который актуален и для разработки. Не стоит слишком долго работать над одной проблемой. Если что-то не получается, нужно либо отвлечься, а потом вернуться к выполнению, либо спросить у коллег или же поискать возможное решение в интернете.

Кроме того, есть еще один ценный совет — воспользоваться методом утенка. Как это работает? На стол кладется предмет. И разработчик начинает с ним разговаривать. Например, у него можно спросить, в чем проблема с текущей задачей. Задавать вопрос нужно не формально, а реально — как будто вы разговариваете с человеком. Правильно сформулировав вопрос, разработчик в большинстве случаев вскоре получает и ответ, потому, что в формулировке содержится 50% правильного решения.

Такой подход помогает быстро найти правильное решение проблемы, поскольку сознание фокусируется на ней. Это отличный психологический прием, позволяющий вывести мыслительный процесс из замкнутого цикла.

Нежелание гуглить в процессе поиска решения

Многие разработчики считают, что искать решение своей задачи в интернете — неправильно. На самом деле, фокус в том, чтобы максимально быстро и эффективно решить определенную задачу в сфере разработки ПО. Что именно при этом нужно или не нужно делать — личное дело каждого.

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

Даже очень опытные разработчики гуглят, так что не переживайте. Главное, чтобы вы понимали, что делаете, а не просто копипастили код. Базовые опыт и знания должны быть свои, но если возникло затруднение, то его стоит попытаться решить при помощи Google или Yandex. В следующий раз найденное решение придет на ум само собой.

Изучение теории вместо практики

Для разработчика крайне важна практическая работа. Можно быть лучшим теоретиком разработки на своем потоке университета, но застрять в ходе решения первой же практической задачи на новой работе.

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

В то же время, о теории тоже забывать не стоит, ведь она дает понимание того, что вы делаете в процессе работы над проектом.

Невнимательное изучение технического задания

Новички нередко относятся к решению практических задач не очень серьезно, не обращая внимания на детали.

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

Если что-то непонятно, лучше спросить у тимлида или более опытного коллеги, выяснив все необходимые моменты в самом начале работы.

Отсутствие pet-проектов

Pet-проектом называется проект, который разработчик делает для себя, вне основной работы, в свободное время.

Что может считаться pet-проектом? Все, что угодно:

  • Компьютерная игра или видеоигра.
  • Разработка электронного устройства.
  • Разработка приложения для мобильного телефона или ПК.
  • Разработка программной платформы для управления роботизированными устройствами.

Может показаться, что pet-проект отнимает свободное время и даже мешает работе. Но нет, на самом деле такие проекты помогают быстрее совершенствоваться в своей профессии, осваивать новые технологии и оставаться востребованным на рынке.

На основной работе спектр используемых для решения задач технологий и инструментов может быть достаточно узким. Ограничений же для собственного проекта нет — он может быть сколь угодно сложным и технологичным. Работа над пет-проектом позволяет совершать ошибки и затем исправлять их, не опасаясь подвести команду. Разработчик получает возможность искать новые идеи, пути решения проблем, изучать технологии.

В некоторых случаях pet-проекты превращаются в нечто большее, чем просто хобби. Если созданное приложение, сервис или устройство понравятся окружающим, они решают проблемы пользователей, хобби может превратиться в интересный бизнес. Если и нет — любой проект можно добавить в свое портфолио для демонстрации своих знаний, опыта и возможностей работодателям.

Незнание основ Git

Git — это система контроля версий. Она позволяет отслеживать изменения в своих файлах, а также работать над проектом вместе с другими людьми. Есть разные системы управления версий, но Git считается (и является) самой популярной системой, которая подходит как для индивидуальных разработчиков, так и для команд.

Git очень сильно упрощает процесс работы с другими людьми. Как крупные, так и мелкие команды используют Git для организации нормальной работы. Представьте себе ситуацию, когда есть исходный код проекта, который работает, причем неплохо. Но разработчик или команда принимают решение изменить код — для расширения функционала, например.

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

Еще один вариант — когда несколько разработчиков одновременно меняют код. Без Git делать это приходилось бы с локальной копией кода. И затем слить все изменения в единую базу без системы контроля версий было бы крайне сложной задачей. А с Git все просто. Причем если после слияния что-то работает не так, как нужно, мы используем вариант, описанный выше — просто откатываем изменения.

Git необходимо учить вне зависимости от того, какие языки или фреймворки предпочитает разработчик. Для работы с Git есть разные команды, знать которые нужно обязательно. При этом есть общеизвестные команды, а есть и те, без которых можно обойтись, но которые здорово упрощают взаимодействие с системой и собственным проектом.

Недостаточное внимание к верстке со стороны frontend-разработчиков

Верстка страниц — важная задача в работе всех специалистов, которые связаны с веб-страницами. Веб-разработчики, как фронтендеры, так и бэкендеры, сталкиваются с версткой во время работы. Конечно, backend-специалисту не обязательно знать все премудрости верстки. Главное — основы. А вот в случае frontend все иначе — представители этой профессии просто обязаны уметь верстать страницы «с точностью до пикселя».

Более того, необходимо понимать не только основы верстки, но и более глубокие вещи.

Компании, которые публикуют вакансии на должность фронтэндеров, всегда указывают в требованиях знание HTML, CSS, блочной верстки, часто — JavaScript. Сложно представить себе специалиста по фронтэнду, который не разбирается в верстке. Это как водитель грузовика, который не знает, как управлять машиной.

Слабое понимание рынка труда

Разработчик должен знать себе цену. В буквальном смысле нужно понимать, сколько вы можете зарабатывать. В противном случае может получиться так, что разработчик согласится на первое же предложение со стороны работодателя.

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

В некоторых случаях становится понятно, что нужно подтянуть свои слабые места, получить новые опыт и знания. В других, напротив, разработчик давно уже должен работать на более высокой позиции или в более крутой компании.

Плюс ко всему, собеседования на определенные должности во многих случаях однотипные — интервьюеры задают примерно одни и те же вопросы, просят решать похожие задачи. Во многих буткемпах, например в «Elbrus» есть специальные тренинги по прохождению собеседований, это очень помогает новичкам отточить свои навыки.

Неуверенность в своих силах

Все когда-то были новичками. В начале пути качество работы многих разработчиков оставляет желать лучшего, но это вовсе не значит, что результаты плохие и из-за этого стоит опускать руки.

Постепенно знаний становится все больше, так что вчерашний новичок получает возможность решать все более сложные задачи.

Главное — не останавливаться, работать, возможно — завести себе pet-проект, о котором говорилось выше, чтобы «набивать руку», осваивать новые методы работы и технологии. Чем больше работаешь, тем быстрее станешь профессионалом — здесь зависимость очень простая.

Следите за новыми постами
Следите за новыми постами по любимым темам
13К открытий13К показов