Как стать классным junior-разработчиком и как развиваться?
У большинства новичков очень выражен синдром самозванца и попадая на новую работу, человек теряется, не понимает, что ему делать. Поговорим о хард скиллах для джуна.
Поиск информации
Обращайте внимание, где вы ее ищите. Естественно, вы ее ищите в Google, но где именно? Большинство новичков ищет ответы на свои вопросы в ответах других разработчиков на таких сайтах как Stack Overflow. В принципе, Stack Overflow достаточно авторитетный ресурс, там лайкают правильные ответы и дизлайкают неправильные, но это не значит, что ему можно доверять всегда. Есть гораздо более точный и ответственный источник информации. Вы будете смеяться, но это ОФИЦИАЛЬНАЯ ДОКУМЕНТАЦИЯ! Если у вас проблемы с фреймворком, языком, тулзой, IDEшкой, библиотекой и прочим инструментарием, первое, куда вы должны пойти — в официальную документацию. Не нужно лезть в Stack Overflow, чтобы найти те самые выдержки из документации, а самим пойти в эту документацию.
Найдите ментора
Даже если вы уже работаете как новичковый разработчик, очень полезно будет привлечь кого-то из команды или найти человека за пределами работы, которому можно будет задавать вопросы. Иногда новичкам прямо дают наставников из команды, но не всегда. А моментов, когда вы будете застревать, в начале работы будет особенно много. Если вы хотите изучить новый язык программирования, курсы c# с ментором помогут сделать это в разы быстрее. Это отличный способ свичнуться на другой язык с минимумом потерь и максимальной скоростью.
Контроль качества
Перед тем как отправлять на Merge Request или Pull Request, откройте и перепроверьте то, что вы написали. Что должен проверить разработчик:
- Что проходит основной позитивный сценарий.
Например, вы писали функцию по добавлению пользователя к базе. Вы его вводите, нажимаете кнопочку — он появляется в базе. Залезьте в базу, проверьте, что он там появился. Откройте страницу, которая показывает пользователей, проверьте, что и там он тоже есть. И что все отображается как нужно — что не сбилась кодировка, имя с фамилией не поменялись местами, есть все поля и пр. Т.е. выполняется основной позитивный сценарий.
- Что происходит основной негативный сценарий
Например, вы пытаетесь добавить пользователя с пустыми полями и получаете сообщение, что поля должны быть заполнены. Пробуете ввести существующего пользователя — получаете соответствующее сообщение. Если негативных сценариев несколько — проверьте все. Позитивных сценариев очень много и этим уже занимаются QA, но негативных сценариев не так много и проверить их проще.
Эстимировать задачу нужно с расчетом, что вы все красиво написали, отрефакторили и протестировали таким образом как написано выше. Если вы все время будете отправлять неработающий код, к вам будет плохое отношение на работе. Говнокод — это не только грязный код, но в том числе неработающий или выполняющий не то что нужно.
Не игнорируйте мир вокруг своей работы
Вполне возможно, что задача, которую вы делаете сейчас, в контексте того, что делает остальная команда, скоро будет неактуальной. Например, вы стоите на митинге, слышите, что кусок, над которым вы работаете, планируется выкинуть, киваете и идете работать над фичей, которая скоро будет выкинула. Смысл? Поэтому очень важно слушать, что происходит вокруг. Смотрите на появление новых функциональных обязанностей для вашей системы, думайте, как ваша работа может быть связана с этим функционалом. Возможно, вы вносите какие-то ограничения в систему, о которых нужно сообщить всей остальной команде.
Разделяйте свои заботы
Думайте о том, что вокруг вас точно такие же разработчики. Ваша голова — хорошо, но несколько голов — лучше. Если вы пытаетесь разобраться, как работает кусок кода другого программиста, для того чтобы с ним интегрироваться, почти всегда есть смысл дернуть этого программиста и попросить помочь разобраться с его кодом. Если это не описано в документации. Если вы чувствуете, что застряли и никак не получается решить задачу, вы тоже можете обратиться к своим коллегам. Довольно часто бывает так, что вы настолько глубоко погрузились в работу, что не видите очевидных решений, которые могут быть на поверхности.
Пишите короткие методы
Чтобы разобраться, как правильно писать методы, рекомендую прочитать книгу Clean Code от Роберта Мартина. Это отличная книга, которую нужно прочесть каждому программисту, в том числе новичку.
Длинный метод — это источник постоянных проблем. Я понимаю, что иногда бизнес-логика такая, что иначе не получится. Все равно думайте, каким образом сделать декомпозицию метода, разрезать на отдельные кусочки, может быть вынести в отдельные классы, может быть найти какие-то другие решения, чтобы вам было удобно читать этот метод. Пишется метод один раз, а читать вы его будете сотни раз, к тому же не только вы, но и другие разработчики. Поэтому короткие методы — наше все.
Используйте правильные имена методов и переменных
Важно не только, чтобы методы были короткими, но, и чтобы все имена методов, переменных, классов, пакетов и пр. были логичными. Помним про правило Парето: 80% результата получается из 20% усилий. Правильные наименования — это фактически те самые 20% усилий в программировании. Очень плохо структурированный код с правильными названиями читается намного проще, чем очень хорошо структурированный код без логичных названий. Названия должны быть осмысленными, правильно сформулированными, в английских терминах. И без ошибок! Это очень важный нюанс. Много раз видел ситуацию, когда в системе есть абсолютно идентичные классы, но один назван правильно, а второй с опечаткой. И они живут одновременно. Потому что один программист написал метод с опечаткой в имени, второй программист пытался его найти и не нашел, т.к. есть ошибка, и написал точно такой же. Поэтому если вы не уверены в написании какого-то термина, проверяйте его в словаре.
Ищите конструктивную критику
Довольно часто программист не растет просто из-за того, что у него нет правильного фитбека от более опытного коллеги. Нужно, чтобы кто-то посмотрел в ваш код и сказал, в каком месте можно было сделать лучше, а в каком месте написано совсем не то. Такая конструктивная критика очень сильно помогает.
С другой стороны, не нужно принимать прям любую критику, потому что люди бывают разные, в том числе токсичные, которых хлебом не корми, дай покритиковать все что угодно. Поэтому старайтесь определять, дают ли вам полезный фидбек, который вас может чему-то научить, или это просто ничем не подкрепленная критика. Бесполезную критику игнорируем.
Ознакомьтесь с текстовым редактором/IDE
Очень важно хорошо изучить свой текстовый редактор или IDE, знать его горячие клавиши. Всем начинающим программистам очень сильно рекомендую отвыкать от использования мыши. Настройте все действия, которые вам нужно было делать мышью на комбинации клавиш. В идеале изучите те комбинации клавиш, которые там настроены по умолчанию, чтобы пересев на другой компьютер не пришлось все заново настраивать. Если говорить про Java, то и IDEA, и Eclipse имеют горячие клавиши практически на все действия, которые только могут прийти в голову. Горячие клавиши — это действительно очень удобно.
Прислушивайтесь к другим разработчикам
Всегда прислушивайтесь к более опытным разработчикам, даже если они говорят на темы, которые прямо вас не касаются. Послушайте, о чем они говорят, как они говорят, и какие проблемы обсуждают. Если эта тема вам интересна и/или вы что-то не понимаете — вы всегда можете спросить. В большинстве случаев разработчики с удовольствием продолжат свои разглагольствования благодарному слушателю. Это не только даст вам знания, но и поможет легче влиться в коллектив, и даже даст какое-то уважение среди коллег — все любят, когда их слушают.
Не бойтесь признавать свои ошибки
Больше всего бесит в новичковых разработчиках то, что они не признают свои ошибки. Человек, который не признает ошибок, обычно повторяет ее много-много раз. Если джун не слушает комментариев и скидывает ответственность на кого-то/что-то, то это максимально портит впечатление о человеке. Таким образом вы никак не защитите свое имя и только покажите, насколько вы упертый и непрофессиональный. Когда же человек признает ошибку — это внушает уважение, показывает, что человек слышит и принимает конструктивную критику.
У многих новичков есть убеждение, что если они будут много признавать своих ошибок, то его уволят с работы. Дело в том, что ваши ошибки и так все видят. Но если вы их признаете, значит вы их исправите и не будете допускать дальше. Если вы не признаете ошибок, значит другим придется жить с вами и вашими ошибками. Когда список ошибок накопится, это всем надоест и вот тогда вас действительно могут уволить. Поэтому признаем ошибки. Если не понимаете, в чем ошибка — просим пояснить. Это взрослый подход.
Надеюсь, что эти советы вам помогут.
