Я предпочитаю работать в маленьких командах: до 10 человек. Всех участников команды ты знаешь лично, чаще всего не нужно специально «бронировать время», чтобы обсудить что-то и принять решения.
Но случается и так, что мы беремся за работу над большими проектами. Под «большими» я понимаю композицию следующих факторов:
- Более 50 проектов в solution’е. Назначение не всех из них вы знаете
- Билд и выкладка длятся более 5 минут
- Над кодом работают десятки или сотни человек в разных офисах (возможно и странах)
- Существует четкое разделение труда и область ответственности каждой команды
- Существуют строгие регламенты, стандарты оформления кода, прохождение ревью является обязательным критерием выполнения задачи
- Учет рабочего времени производится позадачно, анализируются причины расхождения оценок и реальных трудозатрат
Бюрократия в этом случае – необходимое зло, тем ни менее, действующее на нервы. Чтобы избежать потерь драгоценных клеток я советую сразу подготовиться к тому, что придется поменять свой привычный workflow. Хорошая новость состоит в том, что, переучившись, вам не составит труда поступать также и на небольших проектах. Скорее всего, ваши коллеги будут приятно удивлены такой педантичностью
1. Используйте feature-бренчи и атомарные коммиты
Совет из разряда капитанских, однако если бы все соблюдали это правило статьи вроде этой не набирали бы столько плюсов. Я не учился этой технике специально, просто в какой-то момент стал четко делить работу на подзадачи и по завершению каждой делать коммит. Использовать атомарные коммиты проще вместе с TDD, потому что сама разработка в этом случае ведется итерационно. Дополнительный бонус для вас состоит в том, что если вы сами накосячите в свой ветке, просто сделаете git reset --hard. Воспринимайте это как обязательные сохранения в сложных компьютерных играх.
Если коллеге в другой ветке потребуется ваш код, который еще не закончен он сможет не доживаясь мерджа сделать cherry-pick и забрать только интересующие его изменения, а не весь ваш «поток сознания».
Основной аргумент, который я слышу против этой практики «теряется состояние потока». Не могу его прокомментировать, потому что «состояние потока» нельзя измерить, потрогать и оценить.
2. Используйте формат именования коммитов
Именование коммитов следует начинать с ID задачи в трекере. Все современные системы управления проектами умеют синхронизироваться с билд-сервером и VCS. Кроме этого, проще отслеживать историю в репозитории.
3. Заведите алиасы в git для подготовки pull request
Всегда необходимо запушить все локальные коммиты в upstream, смержиться с master/dev-веткой. Это простые действия, но после заврешения работы над сложной задачей внимания может не хватать. Лучше поручить это автоматике.
4. Заведите себе чек-лист с распорядком дня
Например, такой:
- Проверить пул-реквесты, все ли прошли, нет ли отклоненных?
- Перевести задачу с отклоненным пул-реквестом в статус «разработка», назначить себя assignee, если там остался ревьюер или поле пустое
- Исправить отклоненные pull request’ы, перевести задачу в ревью, переоткрыть пул-реквест
- Взять задачу о которой договорились на сегодня в работу, перевести в статус разработка
- По завершению работы подмержить master/dev
- Исправить конфликты
- Провести smoke-тестирование
- Перевести задачу в ревью, открыть PR
- Перейти к следующей задаче
В некоторых организациях есть сильные dev-ops и достаточно запушить в upstream первый коммит, чтобы карточка перешла в нужный статус автоматически. Я всячески приветствую такие механики, но далеко не все и не везде настраивают такие автоматизации.
5. Договаривайтесь обо всем заранее
Вообще обо всем. Процессы в больших организациях регламентированы, а работы у ключевых сотрудников, принимающих решение всегда выше крыше. Если вам позарез нужно ревью завтра в обед, договоритесь сегодня вечером. Нужна помощь со сложным куском кода, до которого вы доберетесь вечером. Уточните у человека, чья помощь вам нужна с утра. У него могут быть свои дела. Если вам потребуется прояснять требования с сотрудниками из других отделов/клиентом начинайте это за неделю.
6. Подумайте о плане B
Даже если вы обо всем договоритесь, необходимый вам сотрудник может заболеть, его могут дернуть на нежданный факап. Всякое бывает. По возможности предусмотрите себе альтернативные задачи в случае блокировки.
7. RTFM
Серьезно, прочитайте. Это сэкономит время и нервы вам и вашим коллегам. Только… не доверяйте документации на все 100%. Документация никогда не бывает актуальной:)
8. Выстраивайте партнерские взаимоотношения с коллегами
Изучите, с кем вам предстоит взаимодействовать. Кто может вас заблокировать? Чьи распоряжения вы должны выполнять, а чьи нет? Кто может вам помочь в случае чего? Вам необязательно любить всех коллег, просто ведите себя по-человечески. Не вредничайте и не хамите. Испорченные отношения с другими сотрудниками могут аукнуться самым неожиданным образом.
9. В любой непонятной ситуации действуйте формально
Нет, я не призываю к итальянской забастовке. Чем больше компания, тем меньше времени у руководства вникать в детали возникших проблем. Возможно вы геройски себя проявили и пытались изо всех сил исправить ситуацию. Если этого не вышло по голове вас не по гладят. И премию не дадут. И вообще вы останетесь крайним. Делайте все, что от вас зависит, но в рамках правил. В большинстве случаев, как бы вам не казалось, они разумны. Если правила не разумны – смените работу.
9 ?. Будьте аккуратнее и предусмотрительнее, чем обычно
На полноценный совет это не тянет, поэтому я ограничился тремя четвертями. Чем больше народу на проекте, тем больше начинают «стоить» простои и ошибки. Разработчик отправил пул-реквест. Тимлид был занят и не провел ревью, код не смержили. На следующий день его товарищу по команде потребовался код из не слитого реквеста. Пул-реквест закдеклайнили, две фичи задержались, QA не успели протестировать. В масштабах компании это выливается в колоссальные перерасходы времени и денег. Поэтому очень важно прилагать максимум усилий, чтобы все происходило своевременно. Ни какие разумные запасы не выдержат, если «поедет» сразу несколько задач на критическом пути проекта.
Всем работникам незримого фронта «кровавого энтерпрайза» предлагаю поделиться своим позитивным (или не очень) опытом в комментариях.
Комментарии (26)
Scf
08.07.2016 12:59+6Восьмой совет должен быть нулевым. Итак:
(0) Общайтесь, общайтесь, общайтесь! В больших компаниях безумно важен т.н. "нетворкинг" и его применение может поднять вашу эффективность в разы. Знание проектов, сопряженных с вашими, и людей, которые в них работают, позволяет принимать более качественные решения в своем проекте. Иметь знакомых, которым можно задать вопрос по предметной области, попросить поделиться опытом работы с какой-либо технологией или третьей командой — бесценно. У других команд могут быть наработки, которые не грех и перенять.
В целом, важно понимать, что одна из крупнейших проблем в больших компаниях — это проблема коммуникации. Нехватка знаний инфраструктуры, бизнес-процессов, потребностей других отделов и команд приводит к тому, что значительная часть труда тратится или вхолостую, или на провторную прокладку путей, уже пройденных другими.
Timeless
08.07.2016 14:22+1Абсолютно верно, еще добавлю что очень полезно (особенно с удаленными коллегами) выстраивать личные (но без фанатизма :) ) отношения.
Я одно время работал в очень крупном проекте недоумевал почему компания столько денег тратит на то чтобы мы с ребятами из Штатов и Бельгии ездили друг к другу, хотя все вещи которые надо было делать вполне решались удаленно. Сейчас уже задним числом понимаю насколько упрощалась и улучшалась работа, когда разговариваешь с живым человеком, с которым ты пил пиво у него дома с семьей, спорил о музыке, играл в футбол и тп, а не с абстрактной ячейкой матричного управления из почты.
В терминах РПГ — в диалогах появляются дополнительные опции :) Которые ускоряют/упрощают получение ресурсов и дают более реальную информацию о положении вещей
sshikov
08.07.2016 19:31+1Поддержу. Моя практика работы в таких проектах показывает, что ветки, коммиты и прочее — это все конечно полезно, но далеко не главное. А главное — это обсуждение. Понять, что хотели сделать коллеги из другого проекта в своем релизе, и согласовать все изменения в 50 проектах гораздо сложнее, чем их закодировать. Иногда на порядок.
Miraage
08.07.2016 14:09+2Мы недавно ввели практику делать пулл с флагом
--rebase, чтобы избежать мердж коммитов.
А feature/hotfix ветки вливаем с--no-ff.
defuz
08.07.2016 14:15+1Мне одно не понятно: неужели все эти советы становятся актуальными только после «50 проектов в solution’е»? Или может это такая специфика энтерпрайза: бить проект на 50 подпроектов по 1000 строк в каждом?
marshinov
08.07.2016 14:23Я думаю, что если бы так поступали все и всегда, было-бы хорошо. Просто, к сожалению, культура совместной работы в нашей отрасли по прежнему оставляет желать лучшего и соблюдение даже этих простых практик требует определенной воли руководства. Если в команде из трех человек бардак, то она все еще может быть эффективно. Если бардак устраивают 50 человека работу парализует.
Shamov
08.07.2016 16:54Не совсем так. Если бы так поступали все и всегда, то было бы плохо. Многие из этих советов полезны для больших проектов и вредны для небольших. Обычно команда из трёх человек эффективна именно потому, что в ней бардак. Если навести в ней порядок, то её эффективность упадёт в разы. Ведь на поддержание порядка расходуется организационный ресурс, которого в небольшой команде вырабатывается очень мало. Чтобы в команде вырабатывалось много организационного ресурса, в ней должно быть много менеджеров, которые только тем и занимаются, что непрерывно согласуют что-нибудь друг с другом, планируют последовательность действий, разрабатывают формальные подходы для непонятных ситуаций и т.д. А если в команде из трёх человек будет два менеджера, то скорость разработки скорее всего будет ниже приемлемого уровня. Энтерпрайз же может себе позволить иметь 200 менеджеров на каждые 100 разработчиков. Эти 100 разработчиков успевают разрабатывать то, что приносит столько денег, что их хватает всем.
marshinov
08.07.2016 19:13Если быть совсем точным, то аккуратная работа с гитом и распорядок дня, думаю, будет полезен всем. Выстраивание эффективной коммуникации — это навык, который нужно развивать и в небольшой команде действительно может быть избыточен: можно просто подойти к соседнему столу.
Shamov
08.07.2016 21:35+1Естественно. Гит и микропланирование в рамках одного дня — это мастхэв при любом раскладе. Даже при работе в соло-режиме.
spamas
08.07.2016 16:31Эффективность энтерпрайз проекта на мой взгляд, прежде всего напрямую зависит от правильной иерархии и насколько хорошо каждый участник понимает своё в ней место.
Как показал мой опыт, имеет место именно незнание и часто нежелание думать сверх своих поставленных задач. «Я закомитил, моя хата с краю», «мы не можем сделать деплой, потому что другая команда сделала свою часть не так, как мы предполагали», «мы уже закончили свою часть, а они даже не начинали!» — это наиболее распространенные ответы которые мне приходилось слышать при авральных ситуациях.
Прежде всего надо строго определить рамки ответственности каждой команды в проекте, а также глобальных feature leads, ведущих инженеров которые будут отвечать за области(features) в продукте и не будут привязаны ни к одной из команд. Нужно это для того, чтобы команды имели арбитражную сторону к которой можно обратиться за разъяснениями и инструкциями «как всё должно быть на самом деле» в конкретной фиче.
Ivan22
11.07.2016 11:02Странно что нету советов типа «не накатывайте фиксы сразу на продакшен».
То ли это уже даже последнему школьнику ясно, толи не сталкивались с таким. А это такая жесть, которая может испортить жизнь круче любых багов.
ivanych
> 2. Используйте формат именования коммитов
> Именование коммитов следует начинать с ID задачи в трекере.
Что такое «именование коммита»? Описание коммита, что ли? «git commit -m 'вот_это_вот'»?
Если очень хочется, то пожалуйста, но, вообще говоря, в этом нет никакой необходимости. Номер тикета должен быть в названии ветки, а вставлять его в описание каждого коммита — лишний шум.
> 3. Заведите алиасы в git для подготовки pull request
Что там заводить-то? «git push origin название_ветки» — одна команда.
senia
Это же git. Ветка после мержа удаляется бесследно и получить ссылку на описания задачи в рамках которой вносились изменения оказывается невозможно.
ivanych
Название ветки вписывается в описание мержа. И гитхаб и гитлаб так делают по умолчанию. Т.е. технически это коммит, да, но не каждый коммит в ветке, а мержевый коммит. Вписывать это в каждый коммит внутри ветки ни к чему.
senia
В git в моде ребейз, так что без мержей.
ivanych
Сливаете ветки в мастер без --no-ff?.. ССЗБ.
marshinov
Кроме этого большинство систем используют для смарт комитов именно ID задачи в тексте коммита, например так git commit -m '<TASK_ID>' fixed
ivanych
> git commit -m '<TASK_ID>' fixed
На это вообще нельзя ориентироваться, в общем случае нет соответствия один-к-одному тикет-коммит. Для решения тикета может потребоваться (и скорее всего потребуется) более одного коммита. Должно быть соответствие тикет-ветка, а коммиты внутри ветки замусоривать повторяющимися строчками не стоит.
xotey83
Мы у себя в проекте (используем Jira) пишем комментарии к коммитам так: "-: "
За 5 лет ни раз не испытывали неудоств и даже это многократно помогало, например, когда нужно было по blame скрипта определить каким коммитом вносились изменения в конкретные строки и по тайтлу коммита было легко определить из какого таска эти изменения пришли.
xotey83
Извините, хабрапарсер съел теги. Комментарии к коммитам: "
<task_id> : <commit_title>"ivanych
Можно, конечно, писать в каждый коммит. Но это означает, что во все коммиты ветки будет вписана одна и та же подстрока ""<task_id>: ". Я предпочитаю не забивать описания коммитов лишним текстом. Если вдруг изредка возникает нужна посмотреть, откуда взялся коммит, то достаточно посмотреть, в какой ветке он был.
crocodile2u
Как вы находите ветку на основании коммита? Те способы, что я знаю, не слишком удобные, а иногда и не всегда работают.
ivanych
Смотрю в network в Гитлабе. Очень удобно.
xotey83
Но не тогда, когда у вас пара сотен веток. А когда понадобится выяснить в рамках какого таска вносились изменения в некий участок кода, причём эти изменения полугодовой давности. Боюсь, что в этом случае отследить ветвления в network будет весьма проблематично.
ivanych
Никаких проблем. Поиск по хешу показывает вам этот хеш, там же наглядно видна ветка, в которой он был, и остальные коммиты в этой ветке.
Это чутка не юникс-стайл, согласен, мне всё лень разобраться, как это в консоли скомандовать. Но это, я считаю, лучше, чем забивать все коммиты повторяющимся текстом, который понадобится раз в пол-года. Его еще и вписывать надо, тоже труд.
Apathetic
В больших проектах git blame едва ли ни каждый день используется. Указывать номер задачи в каждом коммите — вполне оправдано