Почему программисту нужно уметь читать чужой код и как этому научиться?

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

Под чужим кодом мы понимаем:
- код вашего коллеги по проекту;
- код дополнительных библиотек и плагинов, которые вы используете в своем проекте;
- ну и, конечно, код платформы, на которой вы разрабатываете свое решение (конечно, если платформа идет с открытым исходным кодом ( OpenSource )).

Профессиональные программисты работают над сложными задачами и довольно часто документации не хватает, или она является не совсем корректной. И даже всезнающий Google не всегда поможет, особенно если вы наткнулись на не слишком популярную проблему. Именно для таких случаев и предназначен такой мощный инструмент, как чтение чужого кода. Это одна из причин, почему мы предпочитаем OpenSource технологии. Очень классно, когда есть доступ ко всему коду проекта (включая код платформы, на которой разрабатываете) и вы можете разобраться с багами самостоятельно. Быстро исправив их, а не ждать неделями ответа от тех, кто поддерживает данную платформу.

Таким образом, если программист не умеет разбираться с чужим кодом, скорее всего, он не будет автономным игроком в команде, всегда требуя помощи от коллег[/desc]. Довольно часто профессионалу быстрее и проще посмотреть в код, чем вычитывать документацию. Код никогда не врет.
Если вы работаете в команде, тогда вам приходится читать код ваших коллег.

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

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

Писать проект с нуля проще. Здесь не нужно разбирать чужой код или поддерживать стиль кода и форматирования предшественников. Все правила и тон проекта задаете вы сами. Это классно, если вы профи и знаете, как это делать правильно. Начинающим мы рекомендуем вливаться в команду и работать уже над существующим проектом. В таком случае человек имеет доступ к коду, написанному опытными членами команды. И только приняв правильные базовые принципы, переходить к проекту с нуля.
Чтение чужого кода также является очень мощным инструментом в процессе обучения программированию.
Далеко не каждый начинающий имеет доступ к команде программистов, которая работает над реальным проектом. Именно поэтому всем начинающим, которые уже умеют реализовать задачи по документации, мы рекомендуем переходить к более сложным заданиям, которые требуют погружения в чужой код. Код, с которым они имеют дело, но пока еще этого не осознают. Именно поэтому мы рекомендуем начинать с OpenSource технологий, где человек имеет доступ ко всему коду, включая и сам язык программирования.
Программирование - это идеальное ремесло, чтобы учиться из опыта других специалистов. Вам не нужно знать Гвидо ван Россума, чтобы перенимать опыт автора языка Python и применять его в своей ежедневной практике. Достаточно регулярно читать код его OpenSource проектов и довольно быстро иметь результат.
Думаю, большинство классных писателей не только много пишут, но и очень много читают других писателей. Каждый начинающий вбирает в себя сотни стилей других авторов и в конечном счете комбинирует для создания своего собственного неповторимого стиля. Так же и программист, чтобы перейти от учебного кода согласно туториала и документации, должен регулярно проводить время за чтением чужого качественного кода.

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

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

Так же и мы, обычно думаем, что код предшественников является хуже, чем наш. Даже свой собственный код мы перестаем любить после того, как пройдет 2 недели с его написания. И это нормально. Это означает, что мы прогрессируем и учимся новому. Тем не менее стоит переосмысливать свое отношение к чужому коду. Он всегда дает нам возможность учиться как следует делать и как делать не стоит. В конце концов, если мы не прочитали массу чужого отличного кода, откуда у нас возьмется понимание того, что такое качественный код и, как его писать?

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

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

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

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

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

3. Убедитесь, что понимаете все конструкции и функции, которые будут использованы в коде.
Второй раз пройдитесь по коду, но теперь обратите внимание на все места, которые вам непонятны с точки зрения конструкции языка, неизвестные для вас функции, внешние библиотеки. Если вы не суперэксперт вашего языка программирования, то найдете не одну новую для себя вещь.
Разберитесь с новыми для вас конструкциями и функциями используя документацию и Google. Без этого шансов понять код практически не будет. Этот процесс даст вам много новых знаний о вашей язык программирования. И те несколько часов стоят новых знаний.

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

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

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

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

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

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

10. Читайте чужой код в парах.
Очень классная практика. Даже если вы будете сидеть с человеком, который программирует не лучше, чем вы, мысли вслух помогут натолкнуть друг друга на правильный ход. Уже не говорю, что две головы всегда лучше, чем одна.
Ищите партнера для разбора чужого кода. Скорость разбора увеличивается в разы!

11. Если нет необходимости читать чужой код, все равно выделяйте 15-30-60 минут ежедневно на чтение чужого качественного кода. Как определить качественный ли код? Большинство популярных OpenSource библиотек, фреймворков, платформ написаны на хорошем уровне.

За первую неделю, если вы начинающий, вы можете не понять ни одной концепции в коде сложного фреймворка. Но с каждым днем ​​чужой код будет выглядеть немного проще и понятнее. Если не получается понять, надо заучить. А когда заучили, тогда приходит и понимание. Так и здесь. Нужно только терпение и понимание того, что за один присест никто не поймет весь код фреймворка Django . А ежедневные 30 минут работы помогут со временем разобраться во всех деталях.

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

Коллектив авторов форума программистов https://www.cyberforum.ru/