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