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

Медиа

Podlodka #79: Highload для начинающих

На этот раз Podlodka погрузилась в мир высоких нагрузок, и помог в этом Алексей Акулович, разработчик в команде backend инфраструктуры ВКонтакте.

AppTractor

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

/

Автор:

Podlodka

Разобрались в том, когда начинается highload, с какими типовыми проблемами сталкиваются разработчики высоконагруженных систем и как с этим справляться. Варианты масштабирования, оптимизация работы с данными, шардирование, кэширование, мониторинги – тема масштабная, и разговор получился насыщенный. Не обещаем, что после выпуска вы сразу напишите свой первый production-ready высоконагруженный сервис, но понимание того, что происходит под капотом на бэкенде у крупных сервисов точно увеличится!

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

Новости

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

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

AppTractor

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

/

Автор:

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

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

SDK

CleverPumpkin выпустила систему управления встроенными покупками CleverPay

Российская студия CleverPumpkin выпустила систему управления встроенными покупками для iOS и Android приложений. Она позволяет легко управлять платежными страницами, проводить сегментацию, валидацию, эксперименты с ценами.

AppTractor

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

/

Автор:

CleverPay.io — это iOS/Android SDK с отдельной  административной частью для эффективной работы со встроенными покупками и подписками.

CleverPumpkin  объясняет, что с помощью этого инструмента (эксперименты с ценообразованием, триггерные скидки, распродажи с time-rush offer и пр.) в приложениях своих клиентов им удалось поднять конверсию с 3% до 7.5%, а чек — с $0.9 до $1.6.

CleverPay берет оплату каждый месяц по количеству активных пользователей приложения. От 0.8 до 0.6 центов – например, при MAU 11,000 пользователей использование SDK будет стоить 77 долларов в месяц.

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

Новости

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

Сегодня у нас квантовое программирование, курсы и открытые проекты, тренды и хаки.

AppTractor

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

/

Автор:

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

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

Реклама

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

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

Вакансии

Популярное

X
X

Спасибо!

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