9 ¾ действительно полезных советов по работе с большими проектами
Я предпочитаю работать в маленьких командах: до 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 не успели протестировать. В масштабах компании это выливается в колоссальные перерасходы времени и денег. Поэтому очень важно прилагать максимум усилий, чтобы все происходило своевременно. Ни какие разумные запасы не выдержат, если «поедет» сразу несколько задач на критическом пути проекта. Всем работникам незримого фронта «кровавого энтерпрайза» предлагаю поделиться своим позитивным (или не очень) опытом в комментариях.
Комментарии (2)
ivanych
8 июля 2016 в 12:53
0↑
↓
> 2. Используйте формат именования коммитов
> Именование коммитов следует начинать с ID задачи в трекере.Что такое «именование коммита»? Описание коммита, что ли? «git commit -m 'вот_это_вот'»?
Если очень хочется, то пожалуйста, но, вообще говоря, в этом нет никакой необходимости. Номер тикета должен быть в названии ветки, а вставлять его в описание каждого коммита — лишний шум.
> 3. Заведите алиасы в git для подготовки pull request
Что там заводить-то? «git push origin название_ветки» — одна команда.
8 июля 2016 в 12:59 (комментарий был изменён)
0↑
↓
Восьмой совет должен быть нулевым. Итак:
(0) Общайтесь, общайтесь, общайтесь! В больших компаниях безумно важен т.н. «нетворкинг» и его применение может поднять вашу эффективность в разы. Знание проектов, сопряженных с вашими, и людей, которые в них работают, позволяет принимать более качественные решения в своем проекте. Иметь знакомых, которым можно задать вопрос по предметной области, попросить поделиться опытом работы с какой-либо технологией или третьей командой — бесценно. У других команд могут быть наработки, которые не грех и перенять.
В целом, важно понимать, что одна из крупнейших проблем в больших компаниях — это проблема коммуникации. Нехватка знаний инфраструктуры, бизнес-процессов, потребностей других отделов и команд приводит к тому, что значительная часть труда тратится или вхолостую, или на провторную прокладку путей, уже пройденных другими.
