Как читать чужой код: гайд для новичков
Даже опытным разработчикам иногда сложно читать чужой код — тем более это тяжело дается джунам. Руководитель кампуса Elbrus Bootcamp Юрий Плисковский рассказывает, с чего начать и на что обратить внимание новичкам.
Зачем читать чужой код
Чтение кода — это приблизительно 90% задач, с которыми сталкивается разработчик. Даже если вы ищете баги в программе, пишете новый код или читаете документацию, вы постоянно сталкиваетесь с чужим кодом. Сложность в том, что разработчики пишут его очень по-разному: могут отличаться стиль, реализации или код может быть попросту некачественным.
Например, условие if/else на JavaScript можно написать так:
if (true)
//...
else
//...
А можно так:
if (true) /.../ else //...
Чем больше чужого кода вы читаете, тем быстрее можете разбирать логику и находить стартовые функции, без которых программа не заработает. Высокая насмотренность помогает понять, как писать код для программистов, которые будут его читать, а не для компьютера. Ниже разберем четыре шага, с которых стоит начинать читать чужой код.
Шаг первый
Как бы банально это не звучало, в первую очередь стоит определить язык программирования, на котором написан код. Это поможет разобраться со способами объявления переменных, функциями и другим синтаксисом.
После этого код нужно скопировать в редактор: он подсветит элементы синтаксиса и укажет, где находятся переменные, где — функции и методы. Это сделает код более наглядным и упростит его разбор.
Для каждого языка программирования существуют разные редакторы кода. В случае с JavaScript наиболее популярные — VS Code и WebStorm.
Шаг второй
Постарайтесь, не вдаваясь в детали, понять, как работает код. Для этого запустите его и посмотрите на результат в консоли. Если код рабочий, можно продолжать анализ. Если он выдает множество ошибок — вероятно, он работает некорректно и разбирать его не стоит.
Затем стоит проанализировать нейминг переменных, функций и методов и постараемся найти зацепки, которые покажут точку старта кода. Речь идет о функции, без которой выполнение кода не начнется. При определении входной точки бывают ошибки и это нормально — в этом случае стоит вернутся к анализу кода и попробовать определить ее еще раз.
На этом этапе стоит выяснить, что именно делает стартовая функция, какие переменные и методы нужны для ее выполнения.
Шаг третий
Переходим к анализу кода с помощью отладки. На этом этапе возможны разветвления: можно выполнить отладку простым способом с помощью console.log (без остановки выполнения программы), а можно более сложным и профессиональным — путем построчной остановки выполнения программы дебаггером.
Четвертый шаг
Отладка помогает глубже понять, как разные сущности в коде связаны между собой. После нее стоит составить mindmap — нарисовать на бумаге визуализацию этих связей. Например, вы видите, что основной функции для выполнения нужно число, которые формирует другая функция.
Визуализация поможет понять логику, на которой построен код, и освободить место в голове для его непосредственного анализа. При этом важно понимать, что визуализация нужна для длинного кода на несколько десятков строк. Если речь идет о программе на 30 строк, mindmap строить необязательно.
Где искать код
Самая большая база кода хранится на GitHub. Найти примеры кода можно по запросу «Лучшие проекты на JavaScript» (или на любом другом языке программирования) и изучить репозитории. Чем больше у него звезд, тем выше вероятность, что код в нем написан хорошо и работает без ошибок.
Кроме GitHub существуют учебные платформы — например, CodeWars и HackerRank, — где в награду за успешно решенную задачу пользователь получает доступ к лучшим решениям. Примеры можно брать и оттуда, но стоит быть осторожным: часто там попадается сильно оптимизированный код, который решает задачу в одну очень длинную строку. В промышленном программировании такие программы — боль: их логика понятна только автору, а другим разработчикам очень сложно его читать и поддерживать.
Резюмируя, можно сказать, что хороший пример кода, с которого стоит начинать, не должен содержать критических ошибок и багов, но и не должен быть нечитаемым (например, слишком коротким).
