Читатели хабра, категорически вас приветствую! Я прошел путь от стажера до разработчика Java с опытом в 5+ лет. За это время было принято не мало хороших решений, но плохие тоже не отставали, о последних и возможном способе их решения я хочу рассказать, и возможно кому то это поможет не наступить на те же грабли что и я, или же менее болезненно “отодрать” их от своих ног, если вы уже попали на них.
В самом начале я думал: «Вряд ли есть что-то настолько же важное как сам код», а как оказалось вокруг есть еще очень много важных аспектов, которых было бы здорово услышать заранее. Материал будет разбит на две части: онбординг, работа с задачами, код-ревью, тесты и чистые код и архитектура.
1. Онбординг: не бояться спрашивать и просить помощи
Многие люди боятся спрашивать, потому что кажется: «Я и так должен сам разобраться». В итоге вы можете сидеть часами множить неудачные попытки с чем-то разобраться, и винить себя в некомпетентности, хотя очень вероятно, что проблема не в вас. На самом деле никто не ждет от вновь прибывшего сотрудника, тем более у которого еще нет многолетнего опыта за спиной, что он с ходу разберется во всем.
Задача онбординга – с наибольшим комфортом и за наименьшее время помочь вам влиться в процессы компании и команды. Поэтому смело задавайте вопросы и просите помощи при необходимости у ответственных лиц. При этом не забывая о балансе, есть вещи которые предполагается что вы знаете, например установить среду разработки, склонить проект, установить и настроить СУБД по конфигу и тому подобное. А есть вещи специфические для конкретной компании или команды, который вы не можете знать изначально, например где лежат конфигурации для различных стендов, какие политики именования веток в системе контроля версий, где взять доступы к внутренним API и так далее. И помните, вашем быстром и комфортном онбординге заинтересован бизнес, вы имеете полное право на него.
Например когда я пришел начинающим разработчиком в одну из компаний, где я работал, мне в первый день дали древнюю документацию, и сказали пройти по ней тестирование по знанию продукта, а после развернуть его, с тестированием я сходу справился, а вот с разверткой проекта возникла трудность, проект никак не стартовал. Я несколько часов штудировал доку и пытался найти чего же мне не хватает для поднятия проекта. Ведь мне дали большую доку, где, казалось бы, все необходимое уже точно есть, ведь люди наверняка поддерживают актуальность доки, но, к сожалению, я ошибался. Оказалось, что конфиги для поднятия проекта не актуальные, и я никак не смог бы сделать это самостоятельно. И прежде, чем корить себя после долгих неудачных попыток, лучше пойти и задать вопрос ответственному коллеге, ведь нет ничего зазорного в том, чтобы спрашивать о том, чего не могли значить чисто физически.
2. Не стесняться спрашивать того, кто дал задачу, но подходить к этому с умом
В начале карьеры (после тоже немало) особенно часто могут возникать ситуации, когда вы не поняли, что требуется в задаче. Не нужно думать, что вы не обладаете достаточным количеством знаний чтобы с ходу понять задачу. Проблема постановки задач преследует огромное количество специалистов, как начинающих, так и очень опытных. Но важно помнить о балансе, не нужно бегать с абсолютно любыми вопросами. Необходимо сначала постараться разобраться в вопросе, применить свои знания и опыт, а так же умение поиска информации, и только после этого идти к коллеге с собранной пачкой грамотно сформулированных вопросов.
Например, в одной из компании у меня была ситуация, когда на очередном распределении задач, я получил свою, в ней как мне, казалось, было все очень подробно расписано, с широко развернутым текстовым описанием, примерами, изображениями с уточняющей информацией и выглядело это как нечто внушающее доверие. Но у меня никак не получалось интегрировать функциональность в то место куда требовалось, я прилично времени сидел вчитывался в ТЗ, изучал целевой участок проекта, документацию по нему (в этом проекте она была хорошей в отличие от примера из первого пункта), но никак не мог ее интегрировать. Я думал: «Не пойму, такая красивая задача, все так хорошо описано, столько дополнительной информации, хорошая документация, а я не могу с ней справится». Оказалось, все довольно прозаично. Оказалось, что аналитик просто указал не тот участок приложения, а схожий, извинился и внес изменения в ТЗ.
Поэтому нужно смело уточнять все что вам не понятно, это естественная часть процесса решения задач. Лучше всего собрать список вопросов и подойти к ответственному сотруднику и обсудить максимум вопросов за раз. Это гораздо лучше каждые 5 минут бегать к коллеге с 1 новым вопросом.
Бывает, что сидишь с какой-то задачей, уже вопросы все задал, но все равно не получается ее решить. Скорее всего просто не хватает опыта решения задач в условиях реальной работы, и это нормально. Не нужно сидеть и заниматься самобичеванием, адекватные опытные коллеги не будут осуждать начинающего специалиста, они скорее с удовольствием помогут, ведь на самом деле отрадно и полезно помогать своим младшим коллегам.
3. Код-ревью. Защищаться и получать выгоду
Сомнительное ревью — вам могут сказать что-то вроде «Так пишут студенты», «Решение так себе» и не объясняют почему. Это не про вас. Это про неумение ревьюера в коммуникации.
Как-то раз мне сказали: «Мне не нравится, надо переписывать». Я спросил: «А что не так?» - «Так писать нельзя». И только после третьего вопроса «Почему именно не устроило решение?» я наконец получил внятный ответ. Хороший способ провести "эффективное" ревью. С тех пор я не стесняюсь переспрашивать. Уточните: «Расскажи, что именно не так». Если не помогает - фраза «Не понимаю, что вы говорите» часто отрезвляет. Она не обвиняет явно, но подчёркивает, что человек говорит невразумительно, и лучше бы ему изъясняться по-человечески.
Но оно бывает и таким: разговор начинается с того, что хорошо, но вот тут можно сделать более качественно - есть несколько подходов, вот первый, вот второй, вот примеры, где посмотреть. Если возникнут вопросы — сразу спрашивай, я помогу. Это бесплатный урок. Даже если ревьюер не сделал никаких замечаний, у таких коллег лучше лишний раз спросить: «А как бы вы сделали? Насколько вам нравится моё решение? Может, что-то можно улучшить?». Так можно быстрее улучшить свою экспертизу.
4. Сразу уделять большое внимание чистоте кода и архитектуры(уровень классов, сервисов и тп)
Лучше всего как можно раньше начать уделять большое вниманием этим аспектам, даже если вы видите, что в вашей команде кто-то на это забивал. Так как чем раньше начнете, тем меньше будет размер технического долга (скорость реализации в обмен на возможность поддержки и развития решения). Фраза «Потом отрефакторим», часто в действительности означает «Никогда»). А в результате мучительные и долгие правки которые делать либо вам, либо вашим коллегам, выслушивая много “лестных” слов в свой адрес, а вероятно и оба варианта сразу.
Например, в одной из компаний, где я работал, была практика выносить в отдельный общий модуль вещи, которые могут использоваться сразу в нескольких участках проекта и имеют идентичную структуру данных и функциональность и кажется, что для всех мест, где они используются - будут одинаковые изменения. Несколько месяцев, может лет, и в какой-то момент вполне предсказуемо изменения для разных участков проекта начали отличаться, не вносить их нельзя, так как заказчик уже стоит за дверью с мешком золота, и требует свои хотелки, причем побыстрее. А на этой вещи завязано множество критичных участков, и часть из них естественна не покрыта качественными тестами, следовательно, просто взять выкинуть старое и впихнуть туда новое не выйдет, нужно как минимум обеспечить хоть какие-то гарантии, что после изменений все зависимые участки не сломаются. И в итоге вам нужна куча времени, а как следствие и прилично денег компании на то, чтобы исполнить волю заказчика, который в ожидании своей хотелки то и думает, не пойти ли ему со своим мешком золота к более ответственным ребятам.
Таким образом, заботясь сразу о чистоте вашего кода и архитектуры, вы заплатите в разы меньше времени, а возможно и на порядок, чем если выберите подход “пока и так нормально”.
5. Не откладывать написание тестов
После того как вы реализовали какую-то функциональность, и прошло какое-то время, а тем более если это чужая функциональность, выбить время на покрытие ее тестами, будет сильно сложнее. Проще сразу заложить время на написание тестов в планируемое время на реализацию задачи.
Если у вас в команде плохо с культурой тестирования, можно сказать, что прежде, чем приступить к новой задаче, вы покроете тестами функционал предыдущей задачи.
Как-то раз была ситуация, когда нашей команде нужно было обновлять версию одной библиотеки для работы, и как на зло, с обновлением у нее изменился API, а тестов на участках, где она использовалась, было крайне мало. И помимо того, что тебе нужно разобраться с новым API, так тебе еще предварительно нужно покрыть все задействованные участки качественными тестами, а вспомнить как должны эти участки работать гораздо сложнее через несколько лет, чем в момент их создания. Поэтому, не забывая про тесты, вы сильно упрощаете себе жизнь на дистанции. И не забывайте о том, что тесты, это тоже код, и он тоже должен быть качественно спроектирован и реализован, и главное здесь не количество, а качество. Наличие бесполезных тестов хуже, чем их отсутствие, в основном бесполезные тесты дают ложное чувство безопасности, замедляют рефакторинг, множат себе подобных (плохой пример для других) и тратят время CI/CD.
Резюмируя
Это не исчерпывающих список, это то, что на мой взгляд было самое важное из опыта. Я постарался вкратце рассказать о каждом аспекте и если вам захочется что-то обсудить, с радостью отвечу в комментариях, а, если нужно будет раскрыть получше какой - либо из аспектов, могу написать дополнительный материал по ним.
В следующей части я расскажу про карьеру, отдых, синдром самозванца, споры, и саморазвитие. Спасибо большое за внимание, надеюсь эти статьи будет вам полезны.