Типові завдання Java-розробника на проекті

Якими є звичайні обов'язки Java-розробника? Адже треба розуміти, на що взагалі йдеш і чим, зрештою, ви займатиметеся, вірно? Сьогодні мені хотілося б поговорити про десять головних завдань, які виконує Java-розробник. Але спочатку давайте познайомимося з таким інструментом як Jira. Або освіжимо знання в пам'яті, якщо він вам уже знайомий. Jira- Це інструмент для організації взаємодії з користувачами, хоча в деяких випадках він використовується і для управління проектами. Іншими словами, розробка проекту розбивається на невеликі завдання, що описуються в цьому інструменті. Ці завдання асайнят (призначають) на розробників, які будуть відповідальні за їх виконання. Під завданнями маємо на увазі, наприклад, додавання деякого функціоналу. Під час виконання розробники та інші спеціалісти додають коментарі про те, хто що зробив і скільки витратив часу — трекають час. Це зроблено для того, щоб відстежувати витрачений час: скільки і на що пішло. В ідеалі це робиться щодня: увечері перед відходом ви трекаєте свої 8 годин на завдання, на які їх витратабо. Функціонал Jira набагато ширший за описане вище, але цього буде достатньо для початкового розуміння. Отже,

1. Розробка нових рішень

Перш ніж щось створити та впровадити, потрібно це вигадати, чи не так? Як я і сказав, це може бути просто завдання у Jira, Яке повісять на вас, і ви будете працювати над розробкою нового рішення, помічаючи в Jira, скільки часу ви витратабо і на що. Також це може бути обговорення на груповому дзвоні команди: кожен зможе висловити свою думку та запропонувати підхід, який він вважає за найкраще. І тут мені хотілося б відзначити кілька моментів. По-перше, професія розробника - це вельми творчий напрямок, тому що вам потрібно вигадувати унікальні шляхи вирішення завдань, маючи на руках стандартні інструменти. Часто в однієї задачі може бути безліч різних рішень: відповідно, все залежить від творчої жилки розробника, накопиченої бази знань і досвіду. Тут ви можете проявити весь свій креатив і геніальність, але головне не переборщити: в такому випадку код стане надто складним і нечитаним і в результаті після вашого відходу, ніхто не буде до кінця розуміти, що це та як воно працює. І треба буде переписувати все з нуля. І вас можуть згадати. І неодноразово. І навряд це будуть теплі, добрі слова. А воно вам потрібне?По-друге, розробник повинен бути гнучким у тому плані, що ви не повинні впиратися в якесь одне рішення і ставати закритим для інших. Мовляв, треба робити лише так і ніяк інакше. Це може статися з різних причин: наприклад, ви хочете довести свою точку зору або ж ви вже розробабо і впровадабо своє рішення, до якого ви неабияк прикипіли і, зрозуміло, не хочеться визнавати, що воно не найкраще. Це може вас неабияк засліпити. Насправді потрібно вміти визнавати свої помилки та бути завжди відкритими до нового (“open-minded”), навіть якщо доведеться видалити функціонал, який ви писали не один тиждень і яким ви дуже пишаєтесь. Пам'ятаю, якось настрій всього дня зробив чийсь трек часу в джирі з коментарем: “Вилучив свій мертвонароджений функціонал. Поплакав”

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

Це логічний крок за попереднім — реалізація нового функціоналу. Вся робота над проектом розбита на завдання у джирі, які отримують розробники в міру завантаженості. Є різні підходи в цьому питанні - "методології", докладніше про які можна почитати в цій статті на JavaRush . Зазвичай завдання мають “Estimation”— прогнозований витрачений час виконання. Його виставляєте або ви самі, коли берете завдання, або тимлід, або під час планінгу розробники разом його прикидають. Цей час дуже рідко вгадується точно, оскільки на розробку впливає багато різних чинників. Наприклад, знайомий або не знайомий програміст з даною технологією, яким є його загальний досвід, різні підводні камені, які можуть стати видно вже під час розробки і т.д. Тому якщо при розробці функціоналу ви не вкладетеся в цей час, нічого страшного не станеться. Це лише загальні прикидки. Але знову ж таки, естімація завдань є не на всіх проектах і, як на мене, без неї жити набагато легше, особливо коли PM по кілька разів на день не тикає тебе в бік із запитанням - "Де естімейти?" Відповідно, ви берете завдання, розробляєте необхідний функціонал,GIT , і в джирі перекладайте статус завдання на “Ready for review” , тобто, готова для перегляду (перевірки) і моліться, щоб її вам не повернули із зауваженнями на доопрацювання.

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

Людині, що перевіряє ваш код, — ревьюєру — розроблений вами функціонал сподобався, але у нього постає питання: а де тести до нього? І він повертає вам завдання на доопрацювання. Тести - важлива частина будь-якого Java-програми. Запустивши їх, можна одразу відловлювати місця неправильної роботи програми. Наприклад, розробник вніс деякі зміни у частині системи, які потягнули у себе зміни поведінки у інший, і помітив цього під час розробки. Запустивши тести, він зможе побачити тести, що впали (правильно не спрацювали). Це підкаже йому, що у іншій частині системи щось зламалося. Тому він не заллє зміни на сервер, а продовжить доопрацьовувати своє рішення. Так, безперечно, мало які розробники мають любов до тестів, але не можна заперечувати ту користь, яку вони приносять додатку. Часто самі клієнти вказують,Тому потрібно знати різні види тестів і вміти їх писати. Java-розробники в основному пишуть юніт-тести та інтеграційні тести, а більшими (наскрізними) займаються AQA - тестувальники-автоматизатори. Докладніше про них та інших представників IT-професій ви можете почитати у моєму огляді .

4. Пошук та ремонт бага

Це теж дуже поширене і часте завдання Java-розробника. Основне завдання QA і AQA - відлов багів. Тобто, вони шукають місця неправильної поведінки програми, створюють завдання у Jira та вішають на когось. Наприклад, тимлід, який у свою чергу сам вирішує, на кого з розробників це призначити, залежно від їх завантаження та ознайомлення з даною ділянкою системи. Після цього розробник займається пошуком бага, проводячи годинник у дебагері, використовуючи при цьому опис завдання QA фахівцями, щоб повторити ситуацію, в якій відбувався баг. Далі розробник знаходить баг, лагодить його, відправляє на рев'ю. Ну і можлива ситуація, коли у розробника баг не відтворювався, і він повертає завдання QA фахівцю назад із коментарем про це. Начебто знайти і відремонтувати баг не так вже й довго, але тут є нюанси. Все залежить насамперед від знайомства розробника з даною ділянкою коду, досвіду та підкованості у теоретичних питаннях. Іноді баг можна знайти і полагодити за 20 хвабон, а іноді на це може піти три дні. Відповідно, даний вид завдань особливо складно оцінити заздалегідь, хіба що розробник, прочитавши опис, одразу зрозуміє, що де і з чим пішло не так. У такому разі припустити час він зможе більш-менш точно.

5. Рев'ю коду

Як говорилося вище, як тільки ви зробите завдання, його потрібно відправити на рев'ю, і якщо воно його пройде, то потрапляє в загальну гілку, якщо ні — його повернуть розробнику з коментарями, що потрібно виправити. Зрозуміло, що це все перевіряється не якими-небудь вищими силами, а іншими розробниками. Але в перевіряючі розробники допускають не всіх, а лише найдосвідченіших, які мають практику за плечима і які можуть відрізнити поганий код від хорошого. Рев'ю коду зазвичай проводиться за допомогою допоміжного інструменту, наприклад, Crucible. Рев'юери переглядають код і при потребі залишають зауваження під деякими рядками. Зауваження також можуть бути різних видів. Наприклад, критичні, без виправлення яких ревьюєр не пропустить код, та інші — скоріше просто коментарі з приводу обраного підходу, до яких розробник може прислухатися, взяти на замітку або проігнорувати. Команда може створити свій порядок та правила проведення ревью, домовитися про те, на що варто звертати увагу, а на що – ні, в межах яких термінів потрібно провести ревью коду тощо. Щоб проводити ревью, недостатньо одного лише досвіду: потрібно ще багато розвиватися в технічному напрямку, читати різні книги (наприклад, "Чистий код" ). Якщо цікаві нюанси проведення код ревью за версією Google, раджу прочитати цю статтю.

6. Аналіз коду

Оскільки проект пишеться одночасно кількома людьми, які мислять по-різному, їх код та підходи відрізнятимуться. І згодом усе потроху перетворюватиметься на кашу. Щоб покращити код, іноді створюють завдання з аналізу, можливо, якогось модуля або всього додатка, щоб знайти недоліки та позначити їх, а пізніше створити завдання для рефакторингу за цими зауваженнями. Також аналіз допомагає в тих ситуаціях, коли з початку розробки деякі простіші, короткі шляхи не було видно, але їх можна побачити зараз. Наприклад, одна й та сама логіка часто повторюється в деяких методах і, відповідно, її можна винести в окремий метод і перевикористовувати багаторазово. Ну або якийсь клас дуже боляче роздувся, або якийсь код став складно підтримуваним або застарілим, або ... Завдання на аналіз допомагають поліпшити якість коду і додатки.

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

Наступна частина аналізу – це рефакторинг коду. Він може бути застарілим, вже непотрібним, погано написаним, погано читаним тощо. Потрібно завжди прагнути досконалості (хоча його не буває) і актуального коду, прибираючи все зайве, адже це тільки плутає і заважає бачити суть функціоналу. Само собою зрозуміло, ці завдання на початку проекту ви навряд чи побачите: вони зустрічаються вже на пізніших етапах розробки, коли програма шліфується і доводиться до ідеалу.Тут, можливо, буде доречно порадитися з колегами, як вони це зробабо б і які вони бачать підводні камені. Суть таких завдань схожа на розробку нового функціоналу. Наприклад, ви отримуєте завдання відредагувати певний функціонал без зміни його поведінки. Для цього ви видаляєте старий, пишете свій та перевіряєте тести. Якщо ви все зробабо правильно, без внесення змін до тестів, вони повинні спрацювати, як і раніше. Після того, як у коді все залагоджено, відправляємо на рев'ю та йдемо пити каву))

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

Уявіть, що ви новий розробник на деякому проекті, що давно розробляється. Вам потрібно ознайомитися з ним або виконати якесь конкретне завдання, наприклад, по вилову бага. Як ви орієнтуватиметеся в проекті? Щоп'ять хвабон смикати своїх членів команди? А якщо вони будуть зайняті чи вихідні, що тоді? Для цього і існує документація, щоб людина, не знайома з функціоналом, могла зайти, знайти потрібну сторінку і швидко розібратися в тому, що робить її частина програми, що цікавить її. Але й документацію повинен хтось заповнювати ^^ Якщо на проекті є документація, яку повинні підтримувати розробники, при реалізації нового функціоналу вони описують його, і при різних змінах і рефакторингу актуалізують документацію. Ще можливі ситуації, коли для написання, підтримки та контролю документації беруть окремого фахівця – технічного письменника. Якщо такий фахівець є, це трохи полегшує життя пересічних розробників.

9. Участь у різних мітингах

Чимало часу розробників йде і різні наради, переговори, планинги. Найпростіший приклад - це "дейліки" (щоденні мітинги), на яких потрібно розповісти, що зробив учора і що збираєшся робити сьогодні. Крім цього потрібно телефонувати віч-на-віч, наприклад, з QA фахівцем, щоб він показав/пояснив нюанси відтворення бага, або обговорити нюанси та вимоги з бізнес-аналітиком, або організаційні питання з PM. Тому хоч розробник і може бути інтровертом, який віддає перевагу усамітненню, все ж таки він повинен вміти знаходити спільну мову з іншими людьми (ну хоча б трохи).Чим вище ранг у розробника, тим більше йому потрібно витрачати час на спілкування і менше писати код. Розробник-тимлід взагалі може витрачати половину, а то й більше робочого часу на одні лише розмови та наради і рідше писати код (так можна і хватку трохи втратити). Але якщо ви ще той любитель поговорити, з посади тимлід цілком можете розвинутися в управлінську сторону і зовсім забути про код, цілими днями спілкуючись з різними командами, замовниками та іншими управлінцями.

10. Проведення/проходження інтерв'ю

Якщо ви працюєте в аутсорсинговій або аутстаффінговій компанії, вам потрібно буде часто проходити зовнішні співбесіди, коли вас потрібно “продати” клієнту (тоді вас може співбесідувати людина з боку клієнта), і внутрішні для підвищення вашого рангу всередині компанії. Я б назвав це хорошим фактором для розвитку, тому що через часті співбесіди ваші знання завжди повинні бути у формі: ви не заіржавієте і не розслабитеся, адже якщо розслабитися в айті, можна і зовсім вилетіти зі сфери. Коли ви станете досвідченішим розробником, зможете побувати вже з іншого боку: не проходити, а проводити співбесіди. Повірте, ви сильно здивуєтеся, подивившись на це з такої позиції, адже проводити співбесіди може виявитися страшнішим, ніж проходити. Потрібно мати свою стратегію інтерв'ю, список питань, встигнути поставити запитання на всі необхідні теми за годину. Та й після цього ви несете відповідальність за фідбек, адже спираючись на нього людина може отримати або не отримати довгоочікуваний оффер або підвищення. Ну і навпаки: ви можете пропустити відверто слабкого кандидата на посаду, якій він не відповідає, і у вас потім можуть запитати: а як ти його взагалі пропустив із таким рівнем знань? Тому проходячи інтерв'ю, врахуйте, що людині навпроти вас теж нелегко, і вона також може відчувати стрес. а як ти його взагалі пропустив із таким рівнем знань? Тому проходячи інтерв'ю, врахуйте, що людині навпроти вас теж нелегко, і вона також може відчувати стрес. а як ти його взагалі пропустив із таким рівнем знань? Тому проходячи інтерв'ю, врахуйте, що людині навпроти вас теж нелегко, і вона також може відчувати стрес. Будь-яке інтерв'ю це стрес як для кандидата, так і для інтерв'юера. Мабуть, на цьому ми закінчимо. Дякую всім, хто дочитав: ставимо лайки та вчимо Java ^^