Дмитрий!

Самый надёжный способ измерить инженерную культуру — изучить кодовую базу. Посмотреть метрики качества, сложность архитектурных построений, количество уровней абстракции, связанность кода и другие программистские штуки. Чтобы не погружаться в дебри, я опишу пару показателей, которые позволяют измерить уровень культуры извне.

Для начала узнайте, как часто на продакшне встречаются критичные баги. Если программисты постоянно ломают приложение, значит что‑то мешает им ответственно относиться к своей работе. Это может быть плохая кодовая база, либо плохо выстроенное взаимодействие с бизнесом — в таких командах часто ограничивают время, нужное на тестирование.

Хороший индикатор инженерной культуры — когда в команде очень мало тестировщиков. Это означает, что программисты самостоятельно проверяют свою работу. При отсутствии автотестов или сложной кодовой базе это было бы весьма обременительно.

Если есть доступ к исходникам, посмотрите — насколько детальны сообщения коммитов? Я люблю проверять сообщения, с которыми исправляют баги. Если исправления описывают подробно, к примеру «Fixed a bug when non‑confirmed user attempted to log in», это говорит, что программист скорее всего никуда не торопился — у него за спиной не стоял злобный менеджер, а баг чинился в спокойной обстановке. Когда чинят срочные и важные баги на проде, пишут что‑то вроде «fix» или «added __init__.py».

Загляните в пулл‑реквесты: насколько внимательно программисты проверяют код друг‑друга? В командах, где ценят инженерную культуру, код‑ревью достаточно жёсткий — у новичков в одном пулл‑реквесте может быть десяток комментариев. Если комментариев мало, или в них обсуждают стиль кода а не способы решения проблем — культура скорее всего низкая.

P. S. Это был совет об управлении разработкой. Хотите больше знать о планировании спринтов, управлении продуктом или о настройке инфраструктуры? Присылайте вопросы.

Управление проектомВеб‑разработка
Отправить
Поделиться
Запинить

Комментарии

Инженерная культура определяется подходом к разработке: тесты, единый стиль кода, код‑ревью, наличие веток для каждой задачи и связь с тикетинговой системой; наличие автоматического деплоя, а в идеале — CI/CD. Количество тестировщиков не определяет эту культуру, а зависит от объёмов производимого софта. Есть компании, где вообще нет тестировщиков, но это не означает, что у них высокий уровень инженерной культуры.

Менеджера — разгневанного или доброго, вообще не должно быть рядом с разработчиком. Тимлид просто обязан оградить свою команду от подобного.

Книги для изучения языка программирования устаревают ещё на этапе вёрстки. Есть, конечно, классика, типа The Art of Computer Programming. Всё остальное — напрасная трата времени. Есть миллион статей с примерами реализации реальных проектов на разных языках. Ну или Udemy вам в помощь.

29 янв 2020
Айрат Мустаев

> Хороший индикатор инженерной культуры — когда в команде очень мало тестировщиков. Это означает, что программисты самостоятельно проверяют свою работу.

Не согласен. Кто будет писать автоматические/интеграционные тесты? Кто будет следить за появлением новых багов? Кто будет придумывать сложные тест‑кейсы и критично относиться к новым функциональностям в части поиска багов? Обычно разработчики тестируют зелёные сценарии, то, что у них написано в критериях приёмки, и то, что они сделали в рамках технической реализации.

К инженерной культуре можно также отнести: процесс обучения, карьерную лестницу, разбор инцидентов, доступ к внутреннему коду (тех репозиториев, которые не являются чувствительными (механизмы поиска мошенников и т. п.)), коллективное владение кодом (в контексте ПР , код ревью и уменьшения bus фактора), процесс разгребания тех. долга и т. д.

12 июня 2023

Рекомендуем другие советы