Григорий Петров: Программисты разной силы на одном проекте

Про ментальные модели я много раз рассказывал. Это уже 45-я статья цикла по управлению разработкой, поэтому пора раскрыть страшную правду. Мы не знаем, как работает наш мозг. Не знаем от слова «вообще». Лучшее на данный момент объяснение:

Когда мы получаем какой-то опыт – например, заучиваем стихотворение, наш мозг как-то меняется. Он меняется таким образом, что в будущем, при определенных обстоятельствах, мы можем прочитать это стихотворение. (с) Наш мозг – пуст

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

Силушка программистская

А между тем «изменения в мозгу» — это то, чем разработчики отличаются друг от друга. А мы, когда организуем процесс разработки, хотим эти отличия понимать. Потому что другие наши модели, которые про социальные взаимодействия, ограничивают размер команды цифрой около десяти. Да и коммуникации между разработчиками тоже не бесплатны. Ошибся в выборе одного или двух бойцов в команде — здравствуйте риски срыва сроков и провала проекта.

Как сравнить двух разработчиков? Опыт. Те самые «изменения в мозгу», о которых мы ничего не знаем. Изменения, вызванные предыдущим опытом: что разработчики читали, как учились, что разрабатывали, с кем общались. Изменения, которые позволяют разработчикам делать две вещи: читать и писать код.

Знакомые психологи очень не любят, когда я называю эти изменения ментальными моделями. Говорят, что ментальные модели — это такой зарезервированный в психологии термин, который совсем о другом. А то, что я называю ментальными моделями — это множество совершенно разных штук со своими названиями. Поэтому, раскрыв страшную тайну, я снова возвращаюсь к привычному термину. Если когда-нибудь мне понадобится написать научную работу по психологии, буду использовать термины по назначению. А читателям статей по управлению разработкой термин «ментальная модель» ближе и понятнее, чем «энграммы», «квалиа» и прочие «когнитивные карты».

Нельзя просто взять, и вместе писать код

И вот тут мы подходим к самому интересному. Код — не книга. Чтение и написание книг — это навык, эволюционировавший у нас тысячи лет. Заимствующий модели окружающего мира, язык жестов, устный язык и область в мозгу, ответственную за распознавание лиц. Для превращения голоса и текста в смысл мозг имеет огромные области «Брока» и «Вернике», которые для этого эволюционировали.

А для кода таких областей нет.

Образования нет. Фундаментальных учебников нет. Устоявшихся методологий нет. Все что есть — это опыт, который у каждого разработчика свой. Если опыт сильно различается, то таким разработчикам будет тяжело читать, понимать и поддерживать код друг друга. Даже такие фундаментальные вещи, как «действующие лица», о которых я недавно писал, будут различаться. И мы даже не можем использовать микроменеджмент и объяснить, как делать правильно! Потому что собственную картину мира в чужую голову запихнуть проблематично.

А что можно?

Индустрия молода, но мы уже успели заимствовать и придумать методы борьбы. Самое простое — это пытаться нанимать бойцов со сходным бэкграундом в технологиях и опытом работы. Из этого, кстати, есть странный вывод: для командной разработки не очень хорошо брать самых сильных специалистов. Нанять всех сильных не получится, и разница в опыте будет очень больно бить по проекту. А в случае ухода такого специалиста поиск замены будет очень непрост. Что еще можно делать?

• Соблюдать баланс между изоляцией разработчиков и командной работой. Хорошо, когда разработчики знают, что делают их коллеги и могут «подстраховать» в редких случаях. Хуже, когда несколько разработчиков работают над одной и той же частью проекта, постоянно споря и «сталкиваясь лбами». Опытный тим лид разделяет проект на изолированные части, над каждой из которых работает отдельный боец. В случае, если он покинет компанию, его преемник сможет постепенно их переписать «под себя». Если они небольшие, конечно.
• Использовать и развивать стандарт кодирования. Внешняя похожесть кода — это, конечно, не панацея, но хоть немного уменьшает когнитивную нагрузку. А Continuous Integration позволяет сделать проверки автоматическими.
• Чтение разработчиками кода друг друга. Не с целью поиска ошибок. А с целью «привыкания» к чужим ментальным моделям. Ну и ошибки иногда тоже находят, в качестве приятного бонуса.
• Использование opinionated фреймворков, которые навязывают соглашения по именованию объектов, их взаимодействию и общей структуре проекта. Тут главное — побороть желание каждого разработчика «все переделать с нуля». Выбранный фреймворк будет не нравиться всем, потому что не они его писали, зато бойцы смогут лучше понимать код друг друга. Оно того стоит.