Mga karaniwang gawain ng isang developer ng Java sa isang proyekto

Ano ang karaniwang mga responsibilidad ng isang developer ng Java? Pagkatapos ng lahat, kailangan mong maunawaan kung ano ang iyong pupuntahan at kung ano, sa huli, ang iyong gagawin, di ba? Ngayon gusto kong pag-usapan ang sampung pangunahing gawain na ginagawa ng isang developer ng Java. Ngunit una, kilalanin natin ang isang tool tulad ni Jira. O i-refresh natin ang ating memorya kung pamilyar na ito sa iyo. Ang Jira ay isang tool sa pakikipag-ugnayan ng gumagamit, bagaman sa ilang mga kaso ay ginagamit din ito para sa pamamahala ng proyekto. Sa madaling salita, ang pagbuo ng proyekto ay pinaghiwa-hiwalay sa maliliit na gawain na inilarawan sa tool na ito. Ang mga gawaing ito ay itinalaga (itinalaga) sa mga developer, na magiging responsable para sa kanilang pagpapatupad. Sa pamamagitan ng mga gawain ibig sabihin namin, halimbawa, pagdaragdag ng ilang pag-andar. Habang umuunlad ang pag-unlad, nagdaragdag ang mga developer at iba pang mga espesyalista ng mga komento tungkol sa kung sino ang gumawa ng ano at kung gaano katagal ang kanilang ginugol—sinusubaybayan nila ang oras. Ginagawa ito upang masubaybayan ang oras na ginugol: magkano ang ginugol at kung ano. Sa isip, ito ay ginagawa isang beses sa isang araw: sa gabi bago umalis, sinusubaybayan mo ang iyong 8 oras sa mga gawain kung saan mo ginugol ang mga ito. Ang pag-andar ng Jira ay mas malawak kaysa sa inilarawan sa itaas, ngunit ito ay magiging sapat para sa isang paunang pag-unawa. Kaya, ano ang mga responsibilidad ng isang developer ng Java?

1. Pagbuo ng mga bagong solusyon

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

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

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

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

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

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

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

5. Ревью codeа

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

6. Анализ codeа

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

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

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

8. Написание documentации

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

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

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

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

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