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

Новости

Интересные материалы: 17.07

В нашей новой подборке визуальный калькулятор, проблемные A/B-тесты и сравнение гибридов.

AppTractor

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

/

Автор:

Весь день мы собираем лучшие материалы о разработке и маркетинге технологий, стартапов, мобильных приложений и игр для iOS и Android из самых разных источников:

Комментарии
Продолжить чтение

Медиа

Podlodka #68: Rust

Является ли Rust убийцей С++? Смогут ли мобильные разработчики писать на нём кроссплатформенные библиотеки? Что лучше – Rust или Go? Созрел ли Rust для того, чтобы использоваться в продакшене?

AppTractor

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

/

Автор:

Podlodka

Podlodka за фундаментальный подход, и чтобы найти ответы на эти холиварные вопросы мы вместе с энтузиастом Rust Степаном Кольцовым основательно обсудили различные аспекты этого языка программирования. Историческая справка, ключевые фичи языка и его недостатки, особенности синтаксиса, экосистема Rust, возможности его применения во фронтеде и мобильной разработке — благодаря опыту гостя выпуск получился максимально емким и информативным.

Комментарии
Продолжить чтение

Разработка

Дневники разработчиков: Snek Fite — «змейка» с непрямым управлением

Привет, меня зовут Михаил, я разработчик и вообще не занимаюсь приложениями-играми. Snek Fite — это первый опыт (ну, вернее, первый удачный: проект находится в играбельном состоянии и количество игроков понемногу растет).

AppTractor

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

/

Автор:

Итак, браузерная игра Snek Fite. С одной стороны, это действительно игра — по клетчатому полю движутся разноцветные змеи, пытаясь укусить друг друга за хвост. Кто стал самым длинным к концу последнего хода — того и тапочки.

Геймплей выглядит так:

С другой стороны, это симуляция программирования. Такая, где не нужно непосредственно писать код, но обучать свою змею придется — в игре нет прямого управления змейкой с клавиатуры, мышки или любого другого контроллера. Вместо этого — экран настроек, который вызывает умиление у любого человека, который пробовал делать свою игру в конструкторе со сценарным программированием (типа Scirra Construct 2, RPG Maker, да хоть Aurora Toolset).

Так выглядит экран настройки змеи. Девять полей, объекты, которые можно расставить по полю, логические операторы (must, must not и optional). Программирование для тех, кто не умеет писать код.

Успех твоей змеи напрямую зависит от того, какие паттерны поведения ты в нее заложишь. Вот такой паттерн, например, заставляет змею прикрывать собственный хвост в случае опасности (белые головы — вражеских змей).

А вот такой сложный паттерн (занимает три поля) дает команду твоей змее преследовать чужой хвост, если тот находится на расстоянии максимум в две пустых клетки от головы твоей рептилии.

В общем, это далеко не развлекуха с мобилочки на вечер. По крайней мере, для большинства. Snek Fite — игра по-своему хардкорная, и затягивает избранных. Зато если затянула — то можно стать таким, как наш игрок с никнеймами Zerro/Undefined (у него две змеи). Он сделал иллюстрированное руководство, где разобрал поведение змей, выигрышные тактики, частые вопросы и сделал много другой полезной работы. Руководство на английском.

Сейчас его змеи на первом и втором месте общего топа:

В игре сейчас есть три игровых режима — это Дуэль, Снейкоцид и Батл-рояль. В первом две змеи соревнуются друг с другом, во втором четыре, в третьем сразу девять.

Игра всегда заканчивается по истечении 1000 ходов. То есть примерно за минуту.

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

Игра — идейный наследник классической Snake Battle, которую российская компания Gamos выпустила в 1992. Геймплей был схожим, только онлайн-баталий не было — всё-таки это была эра MS-DOS и флоппи-дисководов.

Геймплей старой игры:

Сейчас добавляю в игру разные удобства, параллельно привлекаю игроков. Когда-нибудь позже напишу об опыте продвижения.

Монетизации в игре практически нет, играть можно бесплатно. Исключение — PRO-статус для совсем уж упоротых программистов, которые хотят заниматься нейросетями и машинным обучением (да, нейросеть может управлять змеей и корректировать модель ее поведения по ходу обучения).

В общем, если заинтересовал опыт — то пишите в комментариях, о чем хотелось бы почитать (матчмейкинг, разработка на VUE, организация базы данных для игры, выигрышные тактики, опыт продвижения или что-то еще). Сама игра живет по адресу snek.app.

Комментарии
Продолжить чтение

Медиа

Руководство по ориентированному на пользователя проектированию

Ориентированное на пользователя проектирование (User-Centered Design) – далеко не новая концепция.  Это стратегия проектирования и процесс, в котором потребностям, желаниям и ограничениям конечных пользователей продукта уделяется обширное внимание на каждой стадии процесса проектирования.

AppTractor

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

/

Автор:

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

В мобильной среде, которая постоянно развивается и становится все сложнее, как нигде важно давать пользователям именно то, что они хотят, и тут ориентированный на пользователя дизайн чрезвычайно полезен.

В этой книге от Appsee вы узнаете, что такое проектирование может дать вашему продукту, как внедрить его, какие инструменты использовать, получите советы и мнение лидеров индустрии о том, как использовать такой подход.

Скачать ее можно на сайте: https://www.appsee.com/ebooks/the-playbook-of-user-centered-app-making.

Комментарии
Продолжить чтение

Реклама

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

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

Вакансии

Популярное

X
X

Спасибо!

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