Типичные задачи Java-разработчика на проекте

Каковы обычные обязанности Java-разработчика? Ведь нужно понимать, на что вообще идешь и чем, в конце концов, вы будете заниматься, верно? Сегодня мне бы хотелось поговорить о десяти главных задачах, которые выполняет Java-разработчик.Но для начала давайте познакомимся с таким инструментом как Jira. Или освежим знания в памяти, если он вам уже знаком. Jira — это инструмент для организации взаимодействия с пользователями, хотя в некоторых случаях он используется и для управления проектами. Другими словами, разработка проекта разбивается на небольшие задачи, которые описываются в этом инструменте. Эти задачи ассайнят (назначают) на разработчиков, которые и будут ответственны за их выполнение. Под задачами имеем в виду, например, добавление некоторого функционала. По ходу выполнения разработчики и другие специалисты добавляют комментарии о том, кто что сделал и сколько потратил времени — трекают время. Это сделано для того, чтобы отслеживать потраченное время: сколько и на что ушло. В идеале это делается раз в день: вечером перед уходом вы трекаете свои 8 часов в задачи, на которые их потратили. Функционал Jira гораздо шире описанного выше, но этого будет достаточно для начального понимания. Итак, каковы же обязанности Java-разработчика?

1. Разработка новых решений

Прежде чем что-то создать и внедрить, нужно это придумать, не так ли? Как я и сказал, это может быть просто задание в Jira, которое повесят на вас, и вы будете трудиться над разработкой нового решения, помечая в Jira, сколько времени вы потратили и на что. Также это может быть обсуждение на групповом созвоне команды: каждый сможет высказать свое мнение и предложить подход, который он считает наилучшим. И тут мне хотелось бы отметить несколько моментов. Во-первых, профессия разработчика — это весьма творческое направление, так как вам нужно придумывать уникальные пути решения задач, имея на руках стандартные инструменты. Часто у одной задачи может быть множество различных решений: соответственно, все зависит от “творческой жилки” разработчика, накопленной базы знаний и опыта. Тут вы можете проявить весь свой креатив и гениальность, но главное не переборщить: в таком случае код станет слишком сложным и нечитаемым и в итоге, после вашего ухода, никто не будет до конца понимать, что это и как оно работает. И нужно будет переписывать всё с нуля. И вас могут вспомнить. И не раз. И вряд ли это будут теплые, добрые слова. А оно вам надо?Во-вторых, разработчик должен быть гибким в том плане, что вы не должны упираться в какое-то одно решение и становиться закрытым для других. Мол, нужно делать только так и никак иначе. Это может случиться по разным причинам: например, вы хотите доказать свою точку зрения или же вы уже разработали и внедрили свое решение, к которому вы изрядно прикипели и, понятное дело, не хочется признавать, что оно не самое лучшее. Это может вас изрядно ослепить. На самом деле нужно уметь признавать свои ошибки и быть всегда открытыми к новому (“open-minded”), даже если придется удалить функционал, который вы писали не одну неделю и коим вы очень гордитесь. Помню, как однажды настроение всего дня сделал чей-то трек времени в джире с комментарием: “Удалил свой мертворожденный функционал. Поплакал”

2. Написание нового функционала

Это логический шаг вслед за предыдущим — реализация нового функционала. Вся работа над проектом разбита на задачи в джире, которые получают разработчики по мере загруженности. Есть различные подходы в этом вопросе — “методологии”, подробнее о которых можно почитать в этой статье на JavaRush. Как правило у задач есть “Estimation” — прогнозируемое затраченное время на выполнение. Его выставляете либо вы сами, когда берете задачу, либо тимлид, либо во время планинга разработчики сообща его прикидывают. Это время очень редко угадывается точно, так как на разработку влияет множество различных факторов. Например, знаком или не знаком программист с данной технологией, каков его общий опыт, различные подводные камни, которые могут стать видны уже во время разработки и т.д. Поэтому если при разработке функционала вы не уложитесь в это время, ничего страшного не случится. Это всего лишь общие прикидки. Но опять же, эстимация задач есть не на всех проектах и, как по мне, без неё жить гораздо легче, особенно когда PM по пару раз в день не тыкает тебя в бок с вопросом — “Где эстимейты?” Соответственно, вы берете задачу, разрабатываете необходимый функционал, заливаете в общую ветку в GIT, и в джире переводите статус задачи на “Ready for review”, то есть, готовая для просмотра (проверки) и молитесь, чтобы её вам не вернули с замечаниями на доработку.

3. Написание тестов для функционала

Проверяющему ваш код человеку — ревьюеру — разработанный вами функционал понравился, но у него появляется вопрос: а где тесты к нему? И он возвращает вам задачу на доработку. Тесты — важная часть любого Java-приложения. Запустив их, можно сразу отлавливать места неправильной работы приложения. К примеру, разработчик внес некоторые изменения в одной части системы, которые потянули за собой изменения поведения в другой, и не заметил этого при разработке. Запустив тесты, он сможет увидеть упавшие (правильно не сработавшие) тесты. Это подскажет ему, что в другой части системы что-то сломалось. Поэтому он не зальет ломающие изменения на сервер, а продолжит дорабатывать своё решение. Да, несомненно, мало какие разработчики питают любовь к тестам, но нельзя отрицать ту пользу, которую они приносят приложению. Часто сами клиенты указывают, какого уровня покрытия тестами необходимо придерживаться (например, 80%).Поэтому и нужно знать различные виды тестов и уметь их писать. Java-разработчики в основном пишут юнит-тесты и интеграционные тесты, а более обширными (сквозными) занимаются AQA — тестировщики-автоматизаторы. Подробнее о них и других представителях IT-профессий вы можете почитать в моем обзоре.

4. Поиск и починка бага

Это тоже весьма распространенная и частая задача Java-разработчика. Основная задача QA и AQA — отлавливание багов. То есть, они ищут места неправильного поведения программы, создают задачи в Jira и вешают на кого-то. Например, тимлида, который в свою очередь сам решает, на кого из разработчиков это назначить, в зависимости от их загрузки и ознакомленности с данным участком системы. После этого разработчик занимается поиском бага, проводя часы в дебагере, используя при этом описание задачи QA специалистами, чтобы повторить ситуацию, в которой происходил баг. Далее разработчик находит баг, чинит его, отправляет на ревью. Ну и возможна ситуация, когда у разработчика баг не воспроизводился, и он возвращает задачу QA специалисту обратно с комментарием об этом. Вроде бы найти и починить баг не так уж и долго, но тут есть нюансы. Всё зависит в первую очередь от знакомства разработчика с данным участком кода, опыта и подкованности в теоретических вопросах. Иногда баг можно найти и починить за 20 минут, а иногда на это может уйти три дня. Соответственно, данный вид задач особенно сложно оценить заранее, разве что разработчик, прочитав описание, сразу поймет, что, где и с чем пошло не так. В таком случае предположить время он сможет более-менее точно.

5. Ревью кода

Как говорилось выше, как только вы сделаете задачу, ее нужно отправить на ревью, и если она его пройдет, то попадает в общую ветку, если нет — ее вернут разработчику с комментариями, что нужно поправить. Понятное дело, что это все проверяется не какими-нибудь высшими силами, а другими разработчиками. Но в проверяющие разработчики допускают не всех, а лишь самых опытных, у которых есть практика за плечами и которые могут отличить плохой код от хорошего.Ревью кода как правило производится при помощи вспомогательного инструмента, например, Crucible. Ревьюеры просматривают код и при надобности оставляют замечания под некоторыми строками. Замечания тоже могут быть различных видов. Например критические, без исправления которых ревьюер не пропустит код, и другие — скорее просто комментарии по поводу выбранного подхода, к которым разработчик может прислушаться, взять на заметку или проигнорировать. Команда может создать свой порядок и правила проведения ревью, договориться о том, на что стоит обращать внимание, а на что — нет, в пределах каких сроков нужно провести ревью кода, и т.д. Чтобы проводить ревью, недостаточно одного только опыта: нужно еще много развиваться в техническом направлении, читать различные книги (например, “Чистый код”). Если интересны нюансы проведения код ревью по версии Google, советую прочитать вот эту статью.

6. Анализ кода

Так как проект пишется одновременно несколькими людьми, которые мыслят по-разному, их код и подходы будут отличаться. И со временем все будет понемногу превращаться в кашу. Чтобы улучшить код, иногда создают задачи по анализу, возможно, какого-то модуля или всего приложения, чтобы найти недостатки и пометить их, а позже создать задание для рефакторинга по этим замечаниям. Также анализ помогает в тех ситуациях, когда с начала разработки некоторые более простые, короткие пути не были видны, но их можно увидеть сейчас. Например, одна и та же логика часто повторяется в некоторых методах и, соответственно, её можно вынести в отдельный метод и переиспользовать многократно. Ну или какой-то класс уж больно раздулся, или какой-то код стал сложно поддерживаемым или устаревшим, или… Задачи на анализ помогают улучшить качество кода и приложения. Хотя как по мне, анализ большого количества кода может быть скучноватым занятием.

7. Рефакторинг кода

Следующая часть анализа — это рефакторинг кода. Он может быть устаревшим, уже ненужным, плохо написанным, плохо читаемым и так далее. Нужно всегда стремиться к совершенству (хотя его не бывает) и к актуальному коду, убирая всё лишнее, ведь это только путает и мешает видеть суть функционала. Само собой разумеется, данные задачи в начале проекта вы вряд ли увидите: они встречаются уже на более поздних этапах разработки, когда приложение шлифуется и доводится до идеала.Тут, возможно, будет уместно посоветоваться с коллегами, как бы они это сделали и какие они видят подводные камни. Суть подобных задач похожа на разработку нового функционала. Например, вы получаете задачу отредактировать некоторый функционал без изменения его поведения. Для этого вы удаляете старый, пишете свой и проверяете тесты. Если вы все сделали верно, без внесения изменений в тесты они должны сработать, как и раньше. После того, как в коде всё улажено, отправляем на ревью и идём пить кофе))

8. Написание документации

Представьте, что вы новый разработчик на некотором давно разрабатываемом проекте. Вам нужно ознакомиться с ним или выполнить какую-то конкретную задачу, например, по отлову бага. Как вы будете ориентироваться в проекте? Каждые пять минут дергать своих членов команды? А если они будут заняты или выходные, что тогда? Для этого и существует документация, чтобы человек, не знакомый с функционалом, мог зайти, найти нужную страницу и быстро разобраться в том, что делает интересующая его часть приложения. Но и документацию же должен кто-то заполнять ^^ Если на проекте есть документация, которую должны поддерживать разработчики, при реализации нового функционала они описывают его, и при различных изменениях и рефакторинге актуализируют документацию. Ещё возможны ситуации, когда для написания, поддержки и контроля документации берут отдельного специалиста — технического писателя. Если такой специалист есть, это немного облегчает жизни обычных разработчиков.

9. Участие в различных митингах

Немало времени разработчиков уходит и на различные совещания, переговоры, планинги. Самый простой пример — это “дейлики” (ежедневные митинги), на которых нужно рассказать, что сделал вчера и что собираешься делать сегодня. Помимо этого нужно созваниваться один на один, к примеру, с QA специалистом, чтобы он показал/объяснил нюансы воспроизведения бага, или обсудить нюансы и требования с бизнес-аналитиком, или организационные вопросы с PM. Поэтому хоть разработчик и может быть интровертом, предпочитающим уединение, все же он должен уметь находить общий язык с другими людьми (ну хотя бы немного).Чем выше ранг у разработчика, тем больше ему нужно тратить времени на общение и меньше писать код. Разработчик-тимлид и вовсе может тратить половину, а то и больше рабочего времени на одни лишь разговоры и совещания и реже писать код (так можно и хватку немного потерять). Но если вы ещё тот любитель поговорить, с должности тимлида вполне можете развиться в управленческую сторону и вовсе забыть о коде, целыми днями общаясь с различными командами, заказчиками и другими управленцами.

10. Проведение/прохождение интервью

Если вы работаете в аутсорсинговой или аутстаффинговой компании, вам нужно будет часто проходить внешние собеседования, когда вас нужно “продать” клиенту (тогда вас может собеседовать человек со стороны клиента), и внутренние, для повышения вашего ранга внутри компании. Я бы назвал это хорошим фактором для развития, так как из-за частых собеседований ваши знания всегда должны быть в форме: вы не заржавеете и не расслабитесь, ведь если расслабиться в айти, можно и вовсе вылететь из сферы. Когда вы станете более опытным разработчиком, сможете побывать уже по другую сторону: не проходить, а проводить собеседования. Поверьте, вы сильно удивитесь, посмотрев на это с такой позиции, ведь проводить собеседования может оказаться страшнее, чем проходить. Нужно иметь свою стратегию интервью, список вопросов, успеть задать вопросы по всем необходимым темам за час. Да и после этого вы несете ответственность за фидбек, ведь опираясь на него человек может получить или не получить столь долгожданный оффер или повышение. Ну и наоборот: вы можете пропустить откровенно слабого кандидата на должность, которой он не соответствует, и у вас потом могут спросить: а как ты его вообще пропустил с таким уровнем знаний? Поэтому проходя интервью, учтите, что человеку напротив вас тоже нелегко, и он тоже может испытывать стресс. Любое интервью — это стресс как для кандидата, так и для интервьюера.Пожалуй, на этом мы и закончим. Спасибо всем, кто дочитал: ставим лайки и учим Java ^^