- PVSM.RU - https://www.pvsm.ru -

9 ¾ действительно полезных советов по работе над крупными проектами

9 ¾ действительно полезных советов по работе над крупными проектами - 1
Я предпочитаю работать в маленьких командах: до 10 человек. Всех участников команды ты знаешь лично, чаще всего не нужно специально «бронировать время», чтобы обсудить что-то и принять решения.

Но случается и так, что мы беремся за работу над большими проектами. Под «большими» я понимаю композицию следующих факторов:

  1. Более 50 проектов в solution’е. Назначение не всех из них вы знаете
  2. Билд и выкладка длятся более 5 минут
  3. Над кодом работают десятки или сотни человек в разных офисах (возможно и странах)
  4. Существует четкое разделение труда и область ответственности каждой команды
  5. Существуют строгие регламенты, стандарты оформления кода, прохождение ревью является обязательным критерием выполнения задачи
  6. Учет рабочего времени производится позадачно, анализируются причины расхождения оценок и реальных трудозатрат

Бюрократия в этом случае – необходимое зло, тем ни менее, действующее на нервы. Чтобы избежать потерь драгоценных клеток я советую сразу подготовиться к тому, что придется поменять свой привычный workflow. Хорошая новость состоит в том, что, переучившись, вам не составит труда поступать также и на небольших проектах. Скорее всего, ваши коллеги будут приятно удивлены такой педантичностью

1. Используйте feature-бренчи и атомарные коммиты

Совет из разряда капитанских, однако если бы все соблюдали это правило статьи вроде этой [1] не набирали бы столько плюсов. Я не учился этой технике специально, просто в какой-то момент стал четко делить работу на подзадачи и по завершению каждой делать коммит. Использовать атомарные коммиты проще вместе с TDD, потому что сама разработка в этом случае ведется итерационно. Дополнительный бонус для вас состоит в том, что если вы сами накосячите в свой ветке, просто сделаете git reset --hard. Воспринимайте это как обязательные сохранения в сложных компьютерных играх.

Если коллеге в другой ветке потребуется ваш код, который еще не закончен он сможет не доживаясь мерджа сделать cherry-pick и забрать только интересующие его изменения, а не весь ваш «поток сознания».
Основной аргумент, который я слышу против этой практики «теряется состояние потока». Не могу его прокомментировать, потому что «состояние потока» нельзя измерить, потрогать и оценить.

2. Используйте формат именования коммитов

Именование коммитов следует начинать с ID задачи в трекере. Все современные системы управления проектами умеют синхронизироваться с билд-сервером и VCS. Кроме этого, проще отслеживать историю в репозитории.

3. Заведите алиасы в git для подготовки pull request

Всегда необходимо запушить все локальные коммиты в upstream, смержиться с master/dev-веткой. Это простые действия, но после заврешения работы над сложной задачей внимания может не хватать. Лучше поручить это автоматике.

4. Заведите себе чек-лист с распорядком дня

Например, такой:

  1. Проверить пул-реквесты, все ли прошли, нет ли отклоненных?
  2. Перевести задачу с отклоненным пул-реквестом в статус «разработка», назначить себя assignee, если там остался ревьюер или поле пустое
  3. Исправить отклоненные pull request’ы, перевести задачу в ревью, переоткрыть пул-реквест
  4. Взять задачу о которой договорились на сегодня в работу, перевести в статус разработка
  5. По завершению работы подмержить master/dev
  6. Исправить конфликты
  7. Провести smoke-тестирование
  8. Перевести задачу в ревью, открыть PR
  9. Перейти к следующей задаче

В некоторых организациях есть сильные dev-ops и достаточно запушить в upstream первый коммит, чтобы карточка перешла в нужный статус автоматически. Я всячески приветствую такие механики, но далеко не все и не везде настраивают такие автоматизации.

5. Договаривайтесь обо всем заранее

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

6. Подумайте о плане B

Даже если вы обо всем договоритесь, необходимый вам сотрудник может заболеть, его могут дернуть на нежданный факап. Всякое бывает. По возможности предусмотрите себе альтернативные задачи в случае блокировки.

7. RTFM

Серьезно, прочитайте. Это сэкономит время и нервы вам и вашим коллегам. Только… не доверяйте документации на все 100%. Документация никогда не бывает актуальной:)

8. Выстраивайте партнерские взаимоотношения с коллегами

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

9. В любой непонятной ситуации действуйте формально

Нет, я не призываю к итальянской забастовке [2]. Чем больше компания, тем меньше времени у руководства вникать в детали возникших проблем. Возможно вы геройски себя проявили и пытались изо всех сил исправить ситуацию. Если этого не вышло по голове вас не по гладят. И премию не дадут. И вообще вы останетесь крайним. Делайте все, что от вас зависит, но в рамках правил. В большинстве случаев, как бы вам не казалось, они разумны. Если правила не разумны – смените работу.

9 ¾. Будьте аккуратнее и предусмотрительнее, чем обычно

На полноценный совет это не тянет, поэтому я ограничился тремя четвертями. Чем больше народу на проекте, тем больше начинают «стоить» простои и ошибки. Разработчик отправил пул-реквест. Тимлид был занят и не провел ревью, код не смержили. На следующий день его товарищу по команде потребовался код из не слитого реквеста. Пул-реквест закдеклайнили, две фичи задержались, QA не успели протестировать. В масштабах компании это выливается в колоссальные перерасходы времени и денег. Поэтому очень важно прилагать максимум усилий, чтобы все происходило своевременно. Ни какие разумные запасы не выдержат, если «поедет» сразу несколько задач на критическом пути проекта [3].

Всем работникам незримого фронта «кровавого энтерпрайза» предлагаю поделиться своим позитивным (или не очень) опытом в комментариях.

Автор: marshinov

Источник [4]


Сайт-источник PVSM.RU: https://www.pvsm.ru

Путь до страницы источника: https://www.pvsm.ru/gtd/152754

Ссылки в тексте:

[1] этой: https://habrahabr.ru/post/179045/

[2] итальянской забастовке: https://ru.wikipedia.org/wiki/%D0%98%D1%82%D0%B0%D0%BB%D1%8C%D1%8F%D0%BD%D1%81%D0%BA%D0%B0%D1%8F_%D0%B7%D0%B0%D0%B1%D0%B0%D1%81%D1%82%D0%BE%D0%B2%D0%BA%D0%B0

[3] критическом пути проекта: https://ru.wikipedia.org/wiki/%D0%9C%D0%B5%D1%82%D0%BE%D0%B4_%D0%BA%D1%80%D0%B8%D1%82%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%BE%D0%B3%D0%BE_%D0%BF%D1%83%D1%82%D0%B8

[4] Источник: https://habrahabr.ru/post/305280/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best