Всем привет, чисто стало интересно как разные люди ориентируются в чужом коде и сколько у вас на это уходит времени если вам никто не объяснят что и для чего? К примеру я использую метод, "а как бы я сделал", но он больше подходит для новой задачи, которую никто до тебя не делал а не для ориентировки в коде. Ну а чаще всего получается следовать логическому варианту, что смотрю на код, и такой думаю:"ага, значит он тут использует это, потом получает из этого и т.д."
Может у вас есть свои отличные методы? Не бойтесь, делитесь)))
Сначала поверхностно пробегаешься по тому, что можно назвать lifecycle чтобы понять что за чем идет. Это дает базовое понимание внутреннего устройства. Дальше читаешь код и комментарии (если они есть), документацию (если она есть). Переходишь между методами/функциями/классами, запускаешь через отладчик c остановкой в нужных точках, чтобы увидеть состояние приложения на нужный момент. Степень болезненности и геморройности данного процесса сильно зависит от качества архитектуры и качества кода в целом.
Крайне редко надо ориентироваться во всем коде. А для оринетирования в рамках грамотно поставленной таски (т.е. которая абсолютно декомпозирована) достаточно чуть чуть посидеть с отладчиком, чтобы найти концы.
Конечно реализация может не вписываться в архитектуру, но это потом можно и нужно отрефакторить.
Если вам вдруг ставят цель "разберись в чужом коде" - требуйте объяснения зачем это нужно и что потом делать будете.
OnYourLips, еще раз - в хорошем коде при хорошо инкапсулированной таске (а таких задач должно быть 100% при начале работы с проектом новичка) сломать что то стороннее крайне сложно. Но это теоретическая идиллия.
Читать, обращая внимания на имена функций и переменных. Рисовать схемы (диаграмма классов, потолков данных и т.д). Если можно переименовывать по-понятному.
Проходить в отладчике смотря как это работает в динамике
даже в своем коде, год спустя,смотришь и видишь фигу, чужой-вообще потемки, только если на каждой строке автор втсавляет комментарии, то кое что понять можно.