Connect with us

Разработка

Григорий Петров: Формирование навыков

Практика показывает: нельзя просто брать и делить программу на части при повышении концентрации сложности.

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

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

/

     
     
[button color=4d61d7 icon=arrow-left-2 url=https://apptractor.ru/develop/grigoriy-petrov-gibkie-metodologii.html] Предыдущая статья [/button]

 

В предыдущих колонках я подробно рассказал о кошельке Миллера – неприятной закономерности, которая делает из сложности программного обеспечения проблему. Самый простой и очевидный способ борьбы с кошельком – это разделение программы на небольшие части, в каждой из которых не больше 5-10 сущностей. Но у этого простого и очевидного способа есть недостаток, озвученный еще Дэвидом Уилером в известном афоризме:

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

Практика показывает: нельзя просто брать и делить программу на части при повышении концентрации сложности. Сложность любит концентрироваться в одних и тех же “слабых” областях архитектуры. Деление этих областей на части быстро создает количество слоев абстракции, выходящее за границы разумного. И за границы кошелька Миллера. Это особенно хорошо видно в проектах на Java, для которых декомпозиция технически проста и предпочтительна с архитектурной точки зрения. Stack Trace серьезного проекта на Java обычно содержит сотни вызовов: платформа, middleware, контейнеры, логика самой программы, снова middleware, коммуникационные и вспомогательные слои, слои инкапсуляции и адаптации… Несмотря на то, что каждый конкретный вызов – это всего лишь несколько строчек простого кода, длина цепочки вызовов делает логику работы очень трудной для понимания.

java

Навыки, как способ расширения кошелька Миллера

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

На тренингах я люблю иллюстрировать эту закономерность игрой в шахматы. Когда человек начинает изучать правила и играть, в его фокусе внимания только самые простые вещи: как ходят фигуры, какие из них под угрозой, не поставят ли мат в следующий ход. Кошелек Миллера полностью забит этой информацией, и больше внимания ни на что не хватает.

Человеческий мозг устроен так, что пытается приспособиться к повторяющимся действиям и минимизировать затраты энергии на их обработку. Со временем игроку уже не нужно держать в фокусе внимания правила, чтобы понимать, как ходят фигуры, какие есть на доске угрозы и будет ли мат. Выработанные навыки перестают занимать место в кошельке Миллера, освобождая его для более важных вещей: тактики и стратегии игры, создании ловушек для оппонента и всего того, что делает шахматы шахматами.

Навыки не занимают места в кошельке Миллера

Эта важная закономерность позволяет по-другому взглянуть на распределение сложности при разработке программного обеспечения. Код можно перемещать не только в исходные файлы проекта, но и в навыки программистов. Примером такой декомпозиции являются всевозможные фреймворки и библиотеки. Их ценность не только в готовом коде. Чем дольше разработчик пользуется фреймворком или библиотекой, тем лучше тренируются соответствующие навыки и тем меньше внимания требует сам код фреймворка. Хорошо знакомый с фреймворком разработчик почти не тратит усилий на восприятие кода фреймворка, что позволяет ему фокусировать внимание на действительно важных вещах: архитектуре, логике работы программы, контроле ошибок и многом другом.

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

Фреймворки и библиотеки: экономия фокуса внимания

xa3mjD0Jsgs

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

Единый стандарт кодирования в команде разработчиков и аккуратно подобранный набор инструментов крайне благоприятно влияют на работу команды. Но при этом каждый отдельный разработчик будет считать, что “сам бы он переписал все это намного лучше, и инструменты бы выбрал другие”. Это абсолютно нормально, и менеджеру необходимо объяснять команде, для чего нужно придерживаться единых практик. Бездумное следование прочитанным где-то кулинарным рецептам понижает мотивацию и увеличивает трения в коллективе. А вот жесткая, но разумная и аргументированная позиция дисциплинирует команду, позволяет разработчикам тратить меньше времени на изобретения велосипедов и переписываний “не понравившегося” кода.

Велосипеды, конечно, изобретать не перестанут. И код переписывать будут. Такова человеческая природа, и пытаться совсем это устранить – хороший способ потерять хороших разработчиков. Понимание происходящих процессов, постепенное закрепление единых стандартов кодирования и набора библиотек – хорошее подспорье, чтобы и волки были сыты, и овцы целы, и писец не пришел.

Комментарии
Если вы нашли опечатку - выделите ее и нажмите 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

Спасибо!

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