Чек-лист разработчика

Всегда

В первую очередь надо не забывать о правилах хорошего тона. Оскорбления не разрешаются никому и никогда. Мат тоже желательно исключить из лексикона. Мы должны работать вместе, а не против друг друга, поэтому иногда надо идти на компромиссы. Ясно и чётко излагай свои мысли, аргументируй и доказывай, и тебя услышат.

TL;DR

Git

сообщение должно точно описано где, что и почему было сделано;
обновление завендоренных зависимостей, изменения, не относящиеся напрямую к задаче и правки по ревью всегда оформляются отдельным коммитом;

Отчёты

пиши отчёт в первую очередь для себя, поясняя что и почему вызвало задержки, если они есть;
пиши отчёт так, чтобы менеджер понимал твой прогресс по задаче и отклонения от графика;

Другое

не бойся задавать вопросы;
имей запасную задачу;

Работа над задачей

Последовательность работы над задачей рассматривается в документе workflow.

Как оформлять коммиты

Язык написания коммитов у нас русский. Но это не исключает возможности использования оригинальных названий пакетов, классов и прочего.

Есть два подхода к сохранению изменений в историю:

атомарные коммиты — логически отделимые операции разделяются на отдельные коммиты;
массовый коммит со всеми изменениями по задаче:

Плюсы атомарного подхода:

чаще всего каждый коммит касается одного какого-то модуля или даже класса, таким образом проще смотреть историю по файлам (хотя теряется контекст: в рамках какой задачи были сделаны те или иные изменения, поэтому лучше прикреплять номер задачи к каждому коммиту);
историю можно читать в плоском виде, понимая где и что менялось;
легче использовать git bisect;

Минусы атомарного подхода:

если один файл меняется в нескольких коммитах подряд, то на ребейзе ты можешь познать все муки разрешения одинаковых конфликтов;
не всегда получается «красиво» сделать атомарный коммит, после которого код будет корректно работать (а он должен);
если увлекся и забыл закоммитить, то разбиение на коммиты постфактум такое себе развлечение;

Плюсы и минусы массового подхода являются противоположностями атомарного.

Мы не навязываем следование тому или иному подходу, за исключением того, что, если используешь массовый подход, то будь добр написать к нему подробный комментарий: что было сделано, как и почему. Ссылка на задачу, конечно, не помешает, но не избавляет от написания хорошего сообщения, потому что во время работы с кодом хочется узнать ответ здесь и сейчас, сделав git blame или посмотрев историю изменения файла, не переключаясь на трекер.

Помимо этого всегда должны выделяться в отдельные коммиты

обновления завендоренных зависимостей;
изменения, не относящиеся к решаемой задаче напрямую;
правки по ревью.

Ссылки

Как и зачем писать утренние отчёты

Идея писать отчёты сначала может показаться притянутой за уши, особенно в те дни, когда кажется, что в отчёте совершенно нечего написать. Хотя на самом деле отчёты придуманы именно для таких дней. Но давайте по порядку.

Разработчик

Для разработчика отчёт это время для того, чтобы взглянуть на свою работу со стороны. Иногда кажется, что весь день бьёшься над какой-то задачей и ни на миллиметр не приблизился к её решению, так о чём тут писать? Напиши про то как ты пытался решить проблему, почему эти попытки не увенчались успехом, какие подводные камни ты нашёл и так далее. Это поможет твоим коллегам избежать подобных проблем, а возможно кто-то из них сможет подсказать тебе решение.

Отчёт также это способ не распыляться в течении дня. Все мы сталкивались с ситуацией, когда приходишь на работу, а на тебе 50+ задач и все срочные, и вот уже тебе пишет начальник, что где-то что-то сломалось и надо срочно бежать чинить, а ближе к вечеру твой сосед просит пофиксить какую-то багу и заодно посмотреть его код. И вот рабочий день закончился, но количество задач совсем не уменьшилось. Конечно, на некоторые обстоятельства мы не в силах повлиять, но план на день хорошая опорная точка: это то, чем ты планируешь заниматься в течении этого дня. Тебя не отвлекают остальные 50+ задач, будь они хоть трижды срочные. Да и начальству порой можно ответить: «Хорошо, я записал, займусь этим завтра или даже сегодня, если успею».

Менеджер

Нет ничего хуже чем узнать в последний день о том, что задача не сделана. Представь себе гипотетического Валеру, которому дали задачу на неделю. Валера кивнул и пошёл делать. К середине недели Валера понимает, что задача куда сложнее, чем казалась в понедельник, но молча продолжает пилить код, надеясь, что по вечерам успеет доделать. И вот приходит пятница, а вместе с ней и радостный заказчик к нашему Валере и спрашивает: «Ну, как?». А Валера лишь грустно разводит руками и говорит: «Не успел…». Глядя на такую ситуацию со стороны становится очевидным, что сказать о том, что срок пролетает надо было ещё в среду. Ведь иногда заказчик может поменять формулировку или даже вообще отменить задачу. Главное вовремя донести до него возникающие сложности.

Что писать в отчёте

Пиши отчёт в первую очередь для себя. Настолько подробно, насколько это требует ситуация. Если ты сделал всё, что было запланировано, тогда можно просто повторить план в прошедшем времени, если план не выполнен, то тут хорошо бы описать в чём заключалась сложность выполнения плана.

Пиши отчёт так, чтобы менеджер мог понять на каком этапе реализации находится задача и насколько отклоняется от графика.

Что было сделано вчера?

Какие проблемы возникли?

Что планируется на сегодня

Другое

Если понимаешь, что закопался, то есть бьёшься над какой-то проблемой уже второй час и представления не имеешь в какую сторону копать, спроси. Есть два варианта: либо с такой проблемой никто не сталкивался и тогда придётся копать дальше самому, но при этом остальные будут понимать что ты копаешь и почему, либо кто-то уже сталкивался с такой проблемой и может дать тебе решение сразу. Но, конечно, если тебе дают решение, то постарайся его запомнить, потому что второй раз тебе, безусловно, повторят, но вот в третий раз могут и отправить копать самому.

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

vporoshok.me

Тэги