x
 
Дмитрий Абрамов
19 декабря 2019
Советы почтой каждую неделю
Пожалуйста, получите наше письмо, чтобы подтвердить свой адрес:
Вы подписаны на «Советы за неделю»:

Не так давно вы сделали пост про то, как стать разработчиком. Меня особенно зацепил пункт про инженерную культуру (п.6).

Хочется узнать ваше мнение: что на ваш взгляд показывает уровень развития этой культуры в компании/команде?


Дмитрий!

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

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

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

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

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

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

Поделиться
Отправить

Цель рубрики — обсуждение вопросов дизайна всех видов, текста в дизайне и взаимоотношений дизайнеров с клиентами.

Мы публикуем комментарии, которые добавляют к уже сказанному новые мысли и хорошие примеры. Мы ожидаем, что такие комментарии составят около 20% от общего числа.

Решение о публикации принимается один раз; мы не имеем возможности комментировать или пересматривать свое решение, хотя оно может быть ошибочно. Уже опубликованные комментарии могут быть удалены через некоторое время, если без них обсуждение не становится менее ценным или интересным.

Вот такой веб 2.0.

Что делать, если меня, технического директора, потихоньку отстраняют от дел? Как написать аккуратный код? Часть третья: заменяемость Есть СТО, он классный, но при этом редко выходит в свет. Насколько, на твой взгляд, это может быть важно или полезно компании в целом? Как быть, если всё моё время уходит на разработку всё новых и новых фич? 1




Недавно всплыло

Как избежать «эффекта Тильды»? 3 Как работать в Фигме быстрее. Часть 3 1 Как разделать папайю 2 3