Как читать код: научный эксперимент по определению особенностей чтения

12 комментариев
Как читать код: научный эксперимент по определению особенностей чтения
Я прочитал одно исследование о том, как мы читаем код. В статье описывается эксперимент с устройством, способным следить за направлением взгляда человека и определять зоны, на которых испытуемый фокусируется, когда ему предлагают для просмотра кусок кода. Каждый из участников эксперимента получил по шесть фрагментов кода, содержащих по ошибке. Задачей испытуемых было проанализировать код и найти соответствующие ошибки. Вот выдержка из статьи: Слева на картинке изображён код, который суммирует числа от одного до заданного максимума. В правой части - траектория движения взгляда во время чтения кода. Заметьте как глаза кодера сначала сканируют заголовки функций, затем кратко сканируют тело функции, а уже затем взгляд фокусируется там, где проблема скорее всего должна быть в реальном коде (цикл) Чтение кода похоже на чтение Талмуда Это напомнило очень старый пост Джоэля Спольского. Джоэль цитировал в нём Сета Гордона: Тактика и техника чтения Талмуда, как мне кажется, могут быт полезны и для чтения кода. ТалмудКак полагается читать Талмуд:
  1. Работайте в парах, проговаривая вслух мысли друг другу.
  2. Аргументируйте и требуйте аргументации. Если ваш партнёр озвучивает какую-то идею X, и вы её не понимаете или имеете другую позицию, требуйте объяснений.
  3. Время от времени, когда вы имеете дело с каким-то участком текста, часто проще понять его содержание уже после того, как вы прочитаете текст целиком. Таким образом, если вы затупили в каком-то моменте, попробуйте пропустить его, поняв, что вы можете вернуться к нему позже. (Но так или иначе к нему надо будет вернуться).
  4. Читайте "изнутри" и "снаружи". Внутреннее чтение подразумевает перевод на английский (ну или любой другой язык, которым вы оперируете) фраз одну за другой, внешнее чтение предполагает перевод целого куска разом для осознания общего смысла. Если вы читаете только последовательно, вы можете потерять целое в частностях, при попытке осознать текст исключительно целиком по смыслу, вы теряете детали.
Сет описывает два типа кода. Некоторый код проще читать и понимать, он является основой остальной программы (Тип 1). Второй тип кода завист от другой части кода, и его проще понять, уже зная контекст (Тип 2). Это соответствует моим представлениям о том, как мне читать новый код.
  1. Зависимость классов и интерфейсов: обратите внимание на классы, которые не зависят от других классов. Это обычно небольшие и довольно простые объекты, чьё предназначение заключается в первоначальной поддержке организации работы. Они могут выполнять какие-то вычисления, но обычно созданы для хранения данных и поддержки get-set функций. Это код Типа 1. Просмотрите их в первую очередь.После того как вы ознакомитесь с базовыми блоками, вы можете перейти к изучению управляющих классов. Чаще всего это здоровенные "мохнатые" классы, которые представляют собой фактически ядро программы. Это классы Типа2. Убедитесь, что вы поняли из названий функций, какая из них чем управляет.После чего вы можете углубиться в их изучение. Управляющие объекты обычно можно понять только в их взаимодействии друг с другом, соответственно вы должны иметь представление о том, как они спроектированы до того, как уже погружаться в их исследование. (Хинт: управляющие классы не всегда называются соответствующим образом. Обычно это классы, вызывающиеся из main()).
  2. Предполагайте. Предполагайте, что могут значить имена функций и переменных. Если бы вы писали код, что бы делала функция GetNetIndex? Предположите, что она делает как раз то, что вы думаете. Если из названия функции очевидно вытекает её предназначение, пропустите её. Вы к ней всегда сможете вернуться, если вам это когда-либо понадобиться. Зачем тратить время на то, что вам сейчас не нужно? Если вы начнёте в этом всём сейчас копаться, вы начнёте забывать то, что прочитали перед этим. Сконцентрируйтесь на значении и структуре, а не реализации.
  3. Отладка решает. Юнит тесты важны, но реальный код значит куда больше. Если вы действительно хотите понять, как работает код, быстрейший способ сделать это запустить его. Раскочегарьте ваш IDE и на скорую руку напишите грязную и примитивную демку того, как вы в целом планируете использовать код. Шансы на то, что это сработает, минимальны. Я буду удивлён, если всё заработает с первого раза. Это Ок. Начните отладку.Через неё вы поймёте особенности работы кода (и его баги) изнутри гораздо быстрее, и вы сможете сфокусироваться на тех частях кода, которые действительно для вас важны.
Читабельный код - это важно
  • Правильные имена функций решают: мы давно все всё это прекрасно знаем, но мы всё равно должны понимать, что именно имена мы читаем в первую очередь. Хорошее, правильное название функции - и вам не придётся лишний раз углубляться в её реализацию.
  • Правильные имена переменных решают: опять-таки ничего нового. Вспомните, как часто глаза возвращаются к определению переменной и присвоению ней значений. Мы постоянно ищем в коде напоминания о значении переменной.
  • Циклы - корень всех зол: конечно, не одни они, но они хуже всех других утверждений. Вспомните, что прояснение работы циклов, это самое затратное по времени занятие при разборе кода. В них и скрывается большая часть ошибок. (Да, в индексе их не сильно меньше или даже столько же, я забыл, да). Комментирование в каком-то роде помогает, но сохранение простоты и читабельности кода определяет. Упрощайте сложность циклов.
  • Короткий код проще обрабатывать, поэтому достаньте свои тулы по рефакторингу из инструментария, время разделять функции.
  • Мой любимый гайд по написанию читабельного кода - это книга дяди Боба Мартина "Clean Code: A Handbook of Agile Software Craftsmanship." Даже если в некоторых моментах она скучна и в ней хватает переусердствований, она остаётся отличным пособием для практикующего кодера, разбирая многие важные моменты написания читабельного кода и рефакторинга.
Примечание о методе приведённого выше исследования Данный ресёрч, конечно, не является какой-то истиной о том, как мы читаем код, так как эксперимент был проведён всего лишь на пяти программистах. На мой взгляд, это слишком мало. Я имею в виду, что создавать крутое "взглядоотслеживающее" устройство, откалиброванное настолько, что может сказать, какая конкретно строчка читается в данный момент, чтобы испытывать его всего на пяти кодерах? Сложно ли было пригласить больше людей для участия в эксперименте? Мне бы было интересно поучаствовать в таком исследовании, чтобы узнать свои привычки чтения кода. В следующий раз возьмите меня. Оригинал: http://omergertel.com/2010/07/04/how-to-read-code/

Хотите сообщить важную новость? Пишите в Телеграм-бот.

А также подписывайтесь на наш Телеграм-канал.

Читайте также

Исследователи назвали самые стрессовые игры для геймеров
Исследователи назвали самые стрессовые игры для геймеров
Исследователи назвали самые стрессовые игры для геймеров
Появился алгоритм, который точно предсказывает риск заражения и смертности от коронавируса
Появился алгоритм, который точно предсказывает риск заражения и смертности от коронавируса
Появился алгоритм, который точно предсказывает риск заражения и смертности от коронавируса
1 комментарий
EY сделала «шпаргалку» для ИТ: налоги и условия работы в 10 странах
EY сделала «шпаргалку» для ИТ: налоги и условия работы в 10 странах
EY сделала «шпаргалку» для ИТ: налоги и условия работы в 10 странах
30+% белорусских айтишников заявили, что их компании готовы перевезти сотрудников за границу — полностью или частично (правда, из 60+ компаний на наши вопросы об условиях релокейта или помощи при релокейте ответили только 7). Компания EY изучила особенности осуществления деятельности в ИТ-сфере в 10 странах и собрала основную информацию по налоговым и юридическим вопросам.
Математики разрешили один из основных вопросов о двенадцатиграннике
Математики разрешили один из основных вопросов о двенадцатиграннике
Математики разрешили один из основных вопросов о двенадцатиграннике
2 комментария

Обсуждение

3

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

Anonymous
Anonymous
0

Все это конечно интересно, но как это будет применяться в жизни на практике?

Anonymous
Anonymous Senior Pomidor в Силикон Лаб
0

Ну я вижу здесь как минимум один плюс - можно отследить, какие части кода сложнее всего даются для понимания (чтения). В данном случае ещё раз подтвердилось мнение, что сложнее всего программистам даются циклы. Напишите программу, например, с foreach, который гораздо проще, и диаграмма приобретёт совершенно другой облик.

Anonymous
Anonymous ломаю стены головой в Aitoc
1

Хороший эксперимент.

Интересно было бы посмотреть на то как бегает взгляд по классу (а лучше не одному) написанному нашими программистами. Сразу были бы очевидны места где действительно есть проблемы с оформлением кода. А тут такая функция что даже не интересно...

Можно упростить в данном случае решение примененное в эксперименте: надо к IDEшке какой-нибудь написать модуль, который следит за тем между какими классами переключались и какие функции рассматривали. График тяжеловато будет нарисовать (оси выбрать) - но пользы мне кажется будет больше от эксперимента :)

0

Кстати, интересная мысль.
Если в окне просмотра отображать несколько строк (ну, штук пять, например), то по использованию полосы прокрутки можно отследить "ход мысли" не хуже, чем хитрым сканером, использованном в эксперименте.

Anonymous
Anonymous Software Engineering Team Leader в EPAM
0

Так естьуже нечто подобное в Eclipse: кнопки back/forward или оно же Alt+Back, Alt+Forward. Я иногда пользуюсь для переключения между классами где раньше работал. Правда графиков там нет :)

Anonymous
Anonymous developer в Synesis
0

Хехе, а я дольше всего втыкал в scanf, пытаясь понять, где же уязвимость =)

Anonymous
Anonymous
0

Странноватенько.. Я, например, сначала поискал бы функцию main..

0

Вообще-то сумма N первых членов арифметической прогрессии вычисляется безо всяких циклов по простой формуле.

15

Это и было главной ошибкой. Но к сожалению, большинство сразу фокусируется на деталях.

Anonymous
Anonymous ломаю стены головой в Aitoc
0

могу ошибаться но после первого просмотра мне показалось что printf-у просто не хватает параметров.

Anonymous
Anonymous Software Engineering Team Leader в EPAM
0

Забавно узнавать, что твою технику чтения конспектов по математике в универе, уже давным давно использовали древние иудеи при чтении талмуда :)

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

Следующий этап - это чтение изнутри, то есть разбираемся как реализованы методы классов.

Как знать, может кому данный метод и поможет.

Спасибо! 

Получать рассылки dev.by про белорусское ИТ

Что-то пошло не так. Попробуйте позже