Pull to refresh

Comments 26

UFO landed and left these words here
Это же git. Ветка после мержа удаляется бесследно и получить ссылку на описания задачи в рамках которой вносились изменения оказывается невозможно.
UFO landed and left these words here
В git в моде ребейз, так что без мержей.
UFO landed and left these words here
Кроме этого большинство систем используют для смарт комитов именно ID задачи в тексте коммита, например так git commit -m '<TASK_ID>' fixed
UFO landed and left these words here
Мы у себя в проекте (используем Jira) пишем комментарии к коммитам так: "-: "
За 5 лет ни раз не испытывали неудоств и даже это многократно помогало, например, когда нужно было по blame скрипта определить каким коммитом вносились изменения в конкретные строки и по тайтлу коммита было легко определить из какого таска эти изменения пришли.
Извините, хабрапарсер съел теги. Комментарии к коммитам: "<task_id> : <commit_title>"
UFO landed and left these words here
Как вы находите ветку на основании коммита? Те способы, что я знаю, не слишком удобные, а иногда и не всегда работают.
UFO landed and left these words here
Но не тогда, когда у вас пара сотен веток. А когда понадобится выяснить в рамках какого таска вносились изменения в некий участок кода, причём эти изменения полугодовой давности. Боюсь, что в этом случае отследить ветвления в network будет весьма проблематично.
UFO landed and left these words here
В больших проектах git blame едва ли ни каждый день используется. Указывать номер задачи в каждом коммите — вполне оправдано

Восьмой совет должен быть нулевым. Итак:


(0) Общайтесь, общайтесь, общайтесь! В больших компаниях безумно важен т.н. "нетворкинг" и его применение может поднять вашу эффективность в разы. Знание проектов, сопряженных с вашими, и людей, которые в них работают, позволяет принимать более качественные решения в своем проекте. Иметь знакомых, которым можно задать вопрос по предметной области, попросить поделиться опытом работы с какой-либо технологией или третьей командой — бесценно. У других команд могут быть наработки, которые не грех и перенять.


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

Абсолютно верно, еще добавлю что очень полезно (особенно с удаленными коллегами) выстраивать личные (но без фанатизма :) ) отношения.

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

В терминах РПГ — в диалогах появляются дополнительные опции :) Которые ускоряют/упрощают получение ресурсов и дают более реальную информацию о положении вещей

Поддержу. Моя практика работы в таких проектах показывает, что ветки, коммиты и прочее — это все конечно полезно, но далеко не главное. А главное — это обсуждение. Понять, что хотели сделать коллеги из другого проекта в своем релизе, и согласовать все изменения в 50 проектах гораздо сложнее, чем их закодировать. Иногда на порядок.

Мы недавно ввели практику делать пулл с флагом --rebase, чтобы избежать мердж коммитов.
А feature/hotfix ветки вливаем с --no-ff.
Мне одно не понятно: неужели все эти советы становятся актуальными только после «50 проектов в solution’е»? Или может это такая специфика энтерпрайза: бить проект на 50 подпроектов по 1000 строк в каждом?
Я думаю, что если бы так поступали все и всегда, было-бы хорошо. Просто, к сожалению, культура совместной работы в нашей отрасли по прежнему оставляет желать лучшего и соблюдение даже этих простых практик требует определенной воли руководства. Если в команде из трех человек бардак, то она все еще может быть эффективно. Если бардак устраивают 50 человека работу парализует.
Не совсем так. Если бы так поступали все и всегда, то было бы плохо. Многие из этих советов полезны для больших проектов и вредны для небольших. Обычно команда из трёх человек эффективна именно потому, что в ней бардак. Если навести в ней порядок, то её эффективность упадёт в разы. Ведь на поддержание порядка расходуется организационный ресурс, которого в небольшой команде вырабатывается очень мало. Чтобы в команде вырабатывалось много организационного ресурса, в ней должно быть много менеджеров, которые только тем и занимаются, что непрерывно согласуют что-нибудь друг с другом, планируют последовательность действий, разрабатывают формальные подходы для непонятных ситуаций и т.д. А если в команде из трёх человек будет два менеджера, то скорость разработки скорее всего будет ниже приемлемого уровня. Энтерпрайз же может себе позволить иметь 200 менеджеров на каждые 100 разработчиков. Эти 100 разработчиков успевают разрабатывать то, что приносит столько денег, что их хватает всем.
Если быть совсем точным, то аккуратная работа с гитом и распорядок дня, думаю, будет полезен всем. Выстраивание эффективной коммуникации — это навык, который нужно развивать и в небольшой команде действительно может быть избыточен: можно просто подойти к соседнему столу.
Естественно. Гит и микропланирование в рамках одного дня — это мастхэв при любом раскладе. Даже при работе в соло-режиме.
Эффективность энтерпрайз проекта на мой взгляд, прежде всего напрямую зависит от правильной иерархии и насколько хорошо каждый участник понимает своё в ней место.
Как показал мой опыт, имеет место именно незнание и часто нежелание думать сверх своих поставленных задач. «Я закомитил, моя хата с краю», «мы не можем сделать деплой, потому что другая команда сделала свою часть не так, как мы предполагали», «мы уже закончили свою часть, а они даже не начинали!» — это наиболее распространенные ответы которые мне приходилось слышать при авральных ситуациях.
Прежде всего надо строго определить рамки ответственности каждой команды в проекте, а также глобальных feature leads, ведущих инженеров которые будут отвечать за области(features) в продукте и не будут привязаны ни к одной из команд. Нужно это для того, чтобы команды имели арбитражную сторону к которой можно обратиться за разъяснениями и инструкциями «как всё должно быть на самом деле» в конкретной фиче.
Странно что нету советов типа «не накатывайте фиксы сразу на продакшен».
То ли это уже даже последнему школьнику ясно, толи не сталкивались с таким. А это такая жесть, которая может испортить жизнь круче любых багов.
Sign up to leave a comment.

Articles