Comments 26
За 5 лет ни раз не испытывали неудоств и даже это многократно помогало, например, когда нужно было по blame скрипта определить каким коммитом вносились изменения в конкретные строки и по тайтлу коммита было легко определить из какого таска эти изменения пришли.
<task_id> : <commit_title>
"Восьмой совет должен быть нулевым. Итак:
(0) Общайтесь, общайтесь, общайтесь! В больших компаниях безумно важен т.н. "нетворкинг" и его применение может поднять вашу эффективность в разы. Знание проектов, сопряженных с вашими, и людей, которые в них работают, позволяет принимать более качественные решения в своем проекте. Иметь знакомых, которым можно задать вопрос по предметной области, попросить поделиться опытом работы с какой-либо технологией или третьей командой — бесценно. У других команд могут быть наработки, которые не грех и перенять.
В целом, важно понимать, что одна из крупнейших проблем в больших компаниях — это проблема коммуникации. Нехватка знаний инфраструктуры, бизнес-процессов, потребностей других отделов и команд приводит к тому, что значительная часть труда тратится или вхолостую, или на провторную прокладку путей, уже пройденных другими.
Я одно время работал в очень крупном проекте недоумевал почему компания столько денег тратит на то чтобы мы с ребятами из Штатов и Бельгии ездили друг к другу, хотя все вещи которые надо было делать вполне решались удаленно. Сейчас уже задним числом понимаю насколько упрощалась и улучшалась работа, когда разговариваешь с живым человеком, с которым ты пил пиво у него дома с семьей, спорил о музыке, играл в футбол и тп, а не с абстрактной ячейкой матричного управления из почты.
В терминах РПГ — в диалогах появляются дополнительные опции :) Которые ускоряют/упрощают получение ресурсов и дают более реальную информацию о положении вещей
Поддержу. Моя практика работы в таких проектах показывает, что ветки, коммиты и прочее — это все конечно полезно, но далеко не главное. А главное — это обсуждение. Понять, что хотели сделать коллеги из другого проекта в своем релизе, и согласовать все изменения в 50 проектах гораздо сложнее, чем их закодировать. Иногда на порядок.
--rebase
, чтобы избежать мердж коммитов.А feature/hotfix ветки вливаем с
--no-ff
.Как показал мой опыт, имеет место именно незнание и часто нежелание думать сверх своих поставленных задач. «Я закомитил, моя хата с краю», «мы не можем сделать деплой, потому что другая команда сделала свою часть не так, как мы предполагали», «мы уже закончили свою часть, а они даже не начинали!» — это наиболее распространенные ответы которые мне приходилось слышать при авральных ситуациях.
Прежде всего надо строго определить рамки ответственности каждой команды в проекте, а также глобальных feature leads, ведущих инженеров которые будут отвечать за области(features) в продукте и не будут привязаны ни к одной из команд. Нужно это для того, чтобы команды имели арбитражную сторону к которой можно обратиться за разъяснениями и инструкциями «как всё должно быть на самом деле» в конкретной фиче.
То ли это уже даже последнему школьнику ясно, толи не сталкивались с таким. А это такая жесть, которая может испортить жизнь круче любых багов.
9 ¾ действительно полезных советов по работе над крупными проектами