Connect with us

Разработка

Григорий Петров: Управлять можно только тем, что можно измерить

На мой взгляд, для того, чтобы бороться с проблемой сложности, нужно понять причину ее возникновения. Что значит – “код сложно читать”?

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

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

/

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

 

Приветствую вас, коллеги!

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

Чтобы разобраться в этом, проведем небольшой мысленный эксперимент. Ученый написал короткую фразу, отражающую какую-нибудь закономерность. Она понятна ему и другим ученым. Затем он взял часть этой фразу и углубил ее, добавив несколько слов. Фраза стала длиннее, но все еще понятна и ему, и коллегам. Усложняя фразу раз за разом, мы будем наблюдать интересный эффект – с каждым разом самому ученому будет все труднее и труднее прочесть и понять фразу целиком. Но, несмотря на это, небольшие ее фрагменты все еще можно будет относительно безболезненно понимать и расширять. В конце концов, мы придем к ситуации, когда сам автор не сможет прочесть и понять фразу целиком. Почему это происходит? Если несколько теорий и множество гипотез.

Кошелек Миллера

0_e0c92_cbe8ab7c_orig

Из всех объяснений сложности чтения и понимания кода мне больше всего нравится закономерность, обнаруженная в 1956 году американским учёным-психологом Джорджем Миллером. Работая в Bell, он исследовал возможности памяти людей, работавших с компьютером. Согласно его наблюдениям, человек может запомнить и удерживать в кратковременной памяти от 5 до 9 разных элементов. В своих работах Миллер сравнивает человеческую память с “кошельком” фиксированного объема, в который можно одновременно положить не больше девяти монет произвольного номинала. Если же объектов больше девяти, то наш мозг начинает группировать их, чтобы количество групп также не превышало емкости кошелька Миллера.

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

Многие разработчики знают такие фундаментальные правила разработки:

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

Таких правил в популярных книгах по разработке можно найти сотни. И все они косвенно указывают на одно и то же – любой участок программы для своего понимания не должен требовать удержания в памяти более семи элементов. Это (на мой взгляд) ключевое правило я очень мало где видел сформулированное именно таким образом. А ведь именно его несоблюдение приводит к тому, что проекты с многомиллионным бюджетом “гниют” изнутри, и их приходится раз в несколько лет переписывать с нуля.

[notice]

Интерлюдия: Когнитивное искажение “Я всегда это знал”

hindsight-is-20-20

Я уверен, что большинство читателей, прочтя предыдущий абзац, с удовлетворением отметило про себя “ну да, я всегда это знал, так и есть”. К сожалению, среди особенностей нашего мозга не только кошелек Миллера мешает нам добиваться успеха. Другая особенность, которую я хочу отметить, это “hindsight bias” (если кто из моих читателей имеет глубокие знания в социальной психологии и точно знает, как это правильно переводится на русский – буду благодарен, если отправите мне письмо). Это когнитивное искажение срабатывает после того, как мы услышали какое-то утверждение или увидели какое-либо событие. Мозг быстро встраивает услышанное в существующие логические цепочки и нам начинает казаться, что произошедшее очевидно, что все именно к этому шло, и так и должно было случиться. Не верьте своим ощущениям – как бы “очевидно” не казалось вам большинство утверждений, это всего лишь свойство нашего мозга, на самом деле можно сходу назвать более десятка разных причин возникновения сложности, и все они будут выглядеть “логично, понятно и я всегда об этом знал”. Даже те, которые противоречат друг другу.

[/notice]

Способы борьбы с кошельком Миллера

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

  • Рассказать про нее всем участникам процесса и перебороть hindsight bias. Второе очень важно, так как вам хором ответят “это очевидно, мы всегда об этом знали” и к завтрашнему дню забудут. Не потому, что люди плохие, а потому, что мозг так работает.
  • Использовать практику code review, когда код, написанный одним человеком, начерно, по диагонали, просматривается другим. Это нужно не для того, чтобы найти какие-то ошибки в программах, а для того, чтобы проверить, насколько код легко читается. Как показывает практика, даже зная о кошельке Миллера, первые годы трудно отслеживать количество упоминаемых в коде объектов. Зато для другого человека это будет самоочевидно – “я не могу быстро понять вот этот фрагмент, да и в целом непонятно, что и как новый код делает”. С практикой code review тоже не все так просто – при ее введении нужно объяснить для чего она вводится, потому что есть разные code review для разных целей. Например, при написании софта для критичных приложений, к примеру, управления самолетами, код просматривается несколькими людьми с целью проверить, соответствует ли он принятым стандартам и не имеет ли ошибок. Для борьбы со сложностью достаточно, чтобы разработчики просматривали код друг друга – нет необходимости его детально вычитывать, это займет больше времени, вдумчивое чтение кода занимает больше времени, чем его написание.
  • Использовать систему continuous integration, проверяющую формальные метрики кода – максимальную длину строк кода, размер функций, количество методов в классе и т.д. Если подходить к этому без фанатизма, то практика может стать хорошим подспорьем, особенно на начальных этапах, если большинство разработчиков в команде не готовы к тому, чтобы как-то взаимодействовать со сложностью кода.

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

Комментарии
Если вы нашли опечатку - выделите ее и нажмите Ctrl + Enter! Для связи с нами вы можете использовать info@apptractor.ru.
Advertisement
Click to comment

You must be logged in to post a comment Login

Leave a Reply

Новости

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

Дизайн и прототипирование, PWA и звуки, которые важны.

AppTractor

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

/

Автор:

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

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

Разработка

“Крутись и уворачивайся”: история разработки Circle vs Spikes

Немного о себе: 30 лет, программированием начал заниматься относительно поздно, всего 2 года назад. Имелся технический бэкграунд, но в целом от программирования был далек. Знакомых кодеров тоже не было, пришлось самому набивать шишки, пытаясь понять, что и как делать. Привлекла идея делать мобильные приложения, так как хотелось работать на себя. Ну а что может быть интереснее геймдева. Таким образом была поставлена цель – научиться делать мобильные игры.

AppTractor

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

/

Автор:

Но сначала нужно было изучить основы. Решил взяться за фундаментальные вещи: теория, алгоритмы, проектирование и т.д. Промучившись месяца два понял, что нужно ставить практические задачи, а теорию изучать уже по мере надобности. Стал изучать Java, которая повсеместно используется для Android. Да и фреймворк LibGDX, о котором я уже тогда начал думать, был на Java.

Освоив на достаточном уровне Java и LibGDX, я захотел пройти весь путь от идеи игры до публикации. Хотелось начать с чего-то простого. Пришла мысль сделать 2D-аркаду, в которой надо уворачиваться от препятствий, двигаясь при этом по сложной траектории.

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

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

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

Крутись и уворачивайся

В игре вы управляете кругом, который движется по орбите. При этом орбита вместе с кругом движутся вперед. Таким образом соединяются две траектории: круговая и прямолинейная. Это делает механику интересной, заставляет просчитывать наперед это сочетание. Кругом надо уворачиваться от множества разных препятствий (шипов, маятников, лазеров, блоков…). Управление при этом предельно простое – касанием экрана можно менять направление вращения по орбите.

Игра поделена на небольшие уровни, длительностью по 30-40 секунд. Это при условии, конечно, что проходите их с первого раза. Но такое будет происходить редко. Игру я сознательно сделал сложной, так как насмотрелся супер-легких игр, в которых игрокам буквально указывают, куда нажимать. Если вы любите принимать вызовы, то моя игра вам понравится.

На то, чтобы сменить направление вращения (другими словами – на каждое касание) требуется 1 заряд. Уровень вы начинаете, имея 100 зарядов. Цель – истратить как можно меньше зарядов за уровень. То есть нельзя бездумно тыкать по экрану, нужно просчитывать траекторию и использовать заряды с умом.

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

Имеется поддержка Google Play Игр:

  1. Достижения – за каждое из которых открывается новый скин или цветовая тема.
  2. Лидерборды
  3. Сохранения и синхронизация между устройствами

Музыку мне сделал друг, специально для игры, за что я ему очень благодарен. Кому интересно, вот ссылка на его страничку в Soundcloud: https://soundcloud.com/octonick.

Также я постоянно делаю новые уровни, так что пройдя все – не спешите удалять игру. Я планирую часто выпускать обновления.

Если у вас есть какие-либо вопросы, пишите, постараюсь ответить всем: ibragames.com@gmail.com.

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

Новости

Unity переезжает в Google Cloud

Google Cloud и Unity образовали стратегический альянс, и теперь инфраструктуру игр можно будет просто и быстро размещать в облаке Google.

AppTractor

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

/

Автор:

В первую очередь это касается мультиплеерных игр в реальном времени. Набор сервисов и инструментов поможет в создании, тестировании, запуске и масштабировании «подключенных» игр, весь доступ к ним будет прямо внутри Unity.

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

 

 

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

Новости

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

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

AppTractor

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

/

Автор:

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

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

Реклама

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

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

Вакансии

Популярное

X
X

Спасибо!

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