Это продолжение статьи «Как исследовать незнакомый код». Начало доступно по ссылке.

Посмотрите, как используется код

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

В идеале ваша IDE позволит вам щелкнуть правой кнопкой мыши имя метода (или щелкнуть кнопку контекстной подсказки) и выбрать «Просмотреть ссылки». Это перечислит все места, где используется метод. Затем вы можете просмотреть их для контекста, который вы понимаете.

Если в вашей среде IDE нет этой функции, но вы работаете на скомпилированном или транспилированном языке, вы можете использовать еще одну хитрость — переименовать метод во что-то нелепое, например ThisBreaksOnPurpose. Ошибки компиляции сообщат вам, где использовался метод, хотя в случаях, когда к нему обращаются посредством отражения, вы не увидите ошибку до времени выполнения. Обязательно измените имя обратно после этого.

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

Поиск похожего кода

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

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

Полнотекстовый поиск — самая простая версия этого. Выберите выделяющийся фрагмент кода и вставьте его в универсальную панель поиска в IDE (часто привязываясь к сочетанию клавиш ctrl + shift + F). Инструменты поиска обычно включают параметр поиска «целое слово», что означает, что поиск по запросу care.exe не даст таких результатов, как scare.exertion. Если вы хотите еще больше сузить круг, вы можете искать с помощью регулярного выражения вместо текстовой фразы, что полезно, если вы ищете что-то вроде «число по обе стороны от побитового оператора >> или <<».

Иногда даже регулярное выражение не может достаточно сузить круг вопросов, и никто не хочет тратить несколько часов на просеивание результатов поиска в поисках чего-то, что может даже не помочь. Стоит потратить время на изучение некоторых продвинутых методов поиска. Многие программисты предпочитают инструменты командной строки Unix, такие как grep и awk, или, в Windows, рукописные сценарии PowerShell. Я предпочитаю JS Powered Search, расширение VS Code, которое позволяет определить логический поисковый запрос в JavaScript (полное раскрытие: я автор JSPS). Поскольку я пишу JavaScript на своей основной работе, это то, что для меня проще всего.

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

Запуск модульных тестов

В идеальной кодовой базе модульные тесты — это все, что вам нужно, чтобы понять поведение любого участка кода. Большинство кодовых баз не соответствуют этому идеалу; из соображений эффективности тесты имеют тенденцию быть расплывчатыми и иногда описывают устаревшее поведение. Тем не менее, рекомендуется проверить наличие тестов, выполняющих код, который вы изучаете. По крайней мере, они будут описывать входные и выходные данные кода.

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

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

Используйте отладчик

Если у вас есть несколько модульных тестов (или хотя бы простой, выполняющий код без утверждений), у вас есть отличная возможность для пошаговой отладки. Установите точку останова (в большинстве IDE это можно сделать, щелкнув рядом с номером строки в редакторе кода) или добавьте оператор точки останова/отладчика вверху фрагмента кода. Затем запустите тест. Как только вы нажмете точку останова, выполнение будет приостановлено, и вы сможете продвигаться вперед по одной строке за раз, входить в функции и выходить из них, а также проверять значения всех переменных в области видимости.

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

Отладка сверху вниз может быть менее полезной для кода, который выполняется десятки или сотни раз, например, для вложенных циклов. Для кода, подобного этому, вы можете добавить переменные, которые собирают данные на каждой итерации, чтобы вы могли просмотреть их позже. Многие IDE также позволяют устанавливать условные точки останова (или помещать оператор точки останова в блок if), чтобы можно было приостановить выполнение итерации, отвечающей определенным требованиям.

Поиск в базе знаний

Если ваша команда использует базу знаний, такую ​​как Stack Overflow for Teams, Confluence или вики-сайт GitHub, к настоящему моменту вы уже должны иметь довольно хорошее представление о том, какие термины или понятия можно использовать для поиска соответствующей документации. Вы можете перейти к этому шагу намного раньше, если ваша команда пишет документацию как стандартную часть процесса разработки. Имейте в виду, что документация не должна быть вашим единственным источником правды — она начинает устаревать в момент публикации, и единственное, на что вы можете полностью положиться, чтобы узнать, как ведет себя часть кода, — это сам код. Тем не менее, даже устаревшая документация может дать достаточно исходной информации и контекста, чтобы помочь вам избежать ошибочных выводов.

Документация может объяснить, «как» часть кода, но часто лучше объясняет «почему». Иногда вы понимаете, что делает фрагмент кода, но что-то в нем кажется неправильным. Прежде чем изменить его, вы должны приложить все усилия, чтобы понять, на какую информацию или ограничение действовал первоначальный программист.

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

Используйте аннотацию системы контроля версий (git blame)
К настоящему моменту вы узнали все, что скажет вам сам код, а также все, что вам расскажут Google, Stack Overflow и документация вашей команды. Вы эксперт. И даже тогда в головоломке могут быть недостающие части: причудливое дизайнерское решение, метод, который ломает шаблоны, за которыми следует остальная кодовая база, запах кода без очевидного оправдания. Последний способ собрать контекст — отследить исходного автора, сообщение фиксации и билет управления проектом, связанный с этим кодом.

В вашей системе контроля версий (Git, Subversion, Mercurial или любой другой, которую вы используете) есть инструмент, который раскрывает автора и коммит для любой строки кода в кодовой базе. В Git это команда git fault. В большинстве систем это называется либо «винить», либо «аннотировать». Вы можете запустить это в командной строке или в вашей среде IDE. Появится построчный список коммитов: хэш коммита, сообщение коммита и автор. Просматривая хэш коммита в системе управления версиями или в приложении управления проектами вашей команды, вы сможете найти исходный запрос на включение, который включал код, и оттуда вы, надеюсь, сможете перейти по ссылке на исходный тикет, в котором содержится функция или исправление ошибки. был запрошен.

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

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

Сначала разберитесь, потом напишите код

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

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

Переводил с английского ваш покорный слуга.