Connect with us

Разработка

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

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

Григорий Петров

Опубликовано

/

     
     

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

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

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

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

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

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

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

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

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

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

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

А что можно?

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

  • Соблюдать баланс между изоляцией разработчиков и командной работой. Хорошо, когда разработчики знают, что делают их коллеги и могут “подстраховать” в редких случаях. Хуже, когда несколько разработчиков работают над одной и той же частью проекта, постоянно споря и “сталкиваясь лбами”. Опытный тим лид разделяет проект на изолированные части, над каждой из которых работает отдельный боец. В случае, если он покинет компанию, его преемник сможет постепенно их переписать “под себя”. Если они небольшие, конечно.
  • Использовать и развивать стандарт кодирования. Внешняя похожесть кода – это, конечно, не панацея, но хоть немного уменьшает когнитивную нагрузку. А Continuous Integration позволяет сделать проверки автоматическими.
  • Чтение разработчиками кода друг друга. Не с целью поиска ошибок. А с целью “привыкания” к чужим ментальным моделям. Ну и ошибки иногда тоже находят, в качестве приятного бонуса.
  • Использование opinionated фреймворков, которые навязывают соглашения по именованию объектов, их взаимодействию и общей структуре проекта. Тут главное – побороть желание каждого разработчика “все переделать с нуля”. Выбранный фреймворк будет не нравиться всем, потому что не они его писали, зато бойцы смогут лучше понимать код друг друга. Оно того стоит.
Комментарии
Если вы нашли опечатку - выделите ее и нажмите Ctrl + Enter! Для связи с нами вы можете использовать info@apptractor.ru.
Advertisement
 
Click to comment

You must be logged in to post a comment Login

Leave a Reply

Реклама

Наша рассылка

Нажимая на кнопку "Подписаться" вы даете согласие на обработку персональных данных.

Вакансии

Популярное

X
X

Спасибо!

Теперь редакторы в курсе.