Как правильно читать исходный код?
Вопрос общепрактического характера. Как правильно читать исходные коды, особенно тех программ, чей код длинный, сложный, разбит на несколько (даже десятков) файлов, с кучей объявлений (в т ч extern), с классами, namespace-ами и т д?
Просто мне, как человеку, сильно любящему углубляться в устройство Android (даже в штатный Linux я так сильно не погружался, просто в силу его большей понятности и простоты устройства (для меня по крайней мере)), не раз приходилось пытаться читать исходные коды. Цель, конечно, простая как сложение 2х 2ек - понять принцип работы тех или иных функций, библиотек, программ. Только из недавнего: Как Java работает с UART в Android?. И разумеется, перед тем, как задавать подобные вопросы, я пытаюсь читать исходные коды программ, библиотек.
Но в том и проблема. Что в Magisk, что в python3-selinux, невзирая на неслабые знания и, какой-никакой, но опыт программирования на обоих языках (C++ и python соответственно), я просто ломаю голову, пытаясь досконально понять, что делает та или иная функция.
Но ключевое слово - досконально. Понятно, что основную информацию можно понять банально из названия файлов кода, названий функций, классов, namespace-ов. Но мне недостаточно, условно говоря, пояснения типа "парсит SELinux политику". У меня вопрос: "хорошо, а как именно это происходит? Как устроен формат sepolicy? Как он разбирается, что значат его байты, символы? Как именно политика пересобирается, как получается информация о контекстах?"
Но это не вопрос из разряда "как быть с слишком сложными вопросами". Здесь я задаю четкий вопрос: как правильно читать исходный код?
Не знаю, может это у меня одного такая проблема, но при чтении исходного кода легко запутаться, если он в нескольких файлах, использует ООП (классы, namespace, т п). При своих, пусть скромных, но каких-никаких знаниях, мне очень трудно читать исходный код.
Хотелось бы выслушать тех, кому это даётся +- хорошо. Может, есть инструменты, облегчающие чтение кода, есть какие-то техники, методы. Может есть статьи или даже литература по теме... Может, что-то по этому вопросу посоветуете...
Ответы (2 шт):
Никак, Ваше желание разобраться в коде бесполезно без документов по этому коду. Даже если Вы предположили, что поняли правильно написанное в коде, это не значит что вы правы. Инструментов по улучшению кода, выявлению проблем в коде, много. Инструментов объясняющих код нет. Только документация и только общение с автором кода. При этом, через два дня, сам автор уже не знает зачем он использовал ту конструкцию, а не эту и почему переменная названа - "Инкрементальное увеличение интового значения в цикле", а не "i".
Кроме этого не забывайте о локальных, принятых в Компаниях, правилах оформления кода. Человек работающий у нас сначала знакомиться с правилами оформления кода, потом тренируется писать код как принято у нас и только потом пишет код.
Вопрос довольно холиварный. Но всё же отвечу, хотя и несколько предвзято. На мой взгляд для чтения хорошо написанного кода не требуются никакие особые способности. А вот для чтения плохо написанного кода нужно ухищряться, но проблема в том, что плохой код может быть написан самыми разнообразными способами (в отличие от хорошего кода). Вам придётся учить шаблоны плохого проектирования, чтобы хорошо читать плохой код. Оно вам надо?
Хороший код:
- самодокументированный
- короткий (правильно отрефакторенный)
- понятный
- правильно использует ООП
Например (условный питоноподобный язык):
разгребание_очереди(очередь):
вывод("начинаю разгребать")
если очередь.не_пустая():
элемент = очередь.взять()
обработка_элемента(элемент)
иначе:
вывод("разгребание закончено")
класс очередь:
...
не_пустая():
...
взять():
...
обработка_элемента(элемент):
...
В хорошо отрефакторенном коде на каждом из уровней абстракции всё должно быть довольно понятно просто даже из названий классов, методов и переменных. Код должен быть короткий. Хотите разобраться детальнее - смотрите вызываемые функции, опускаетесь глубже от абстракций к конкретике. Для понимания сути происходящего всегда должно быть достаточно и текущего уровня абстракции. Но при необходимости можно и детали посмотреть на любую нужную глубину.