• XSS.stack #1 – первый литературный журнал от юзеров форума

Как читать чужой код больших проектов

dazayanarchy

RAID-массив
Пользователь
Регистрация
03.03.2024
Сообщения
55
Реакции
4
Разбитый на много директорий, модулей итд..

взять например реверснутую гта вайс сити
1741223893337.png

как в этом всем разобраться? зачем? просто очень хочется. Но не понятно ничего, что за что отвечает, что с чем связано и с чего начать.. Сразу путаешься

опытные программисты дайте пожалуйста советов
 
Последнее редактирование:
Пожалуйста, обратите внимание, что пользователь заблокирован
Не возможно одному понять такой большой проект, для этого есть команда, где каждый отвечает за свой модуль допустим.
Нет ли среди вас компьютерного гения? Гений должен уметь делать все сам.
 
Тебе надо не в тупую читать все строчки подряд, а для начала понять что делает приложение и разбить его на модули у себя в голове. Дальше соединить их, как они связываются и работают друг с другом и дальше по функциям идти и разбирать каждый модуль.
Самый проверенный вариант - скачать всю репу, запустить и построчно дебагером идти по каждой функции.
 
Разбитый на много директорий, модулей итд..
На каждый разбитый модуль есть наименование, уже от него понятно что кроется внутри, читаем название:
Animation - значит возможно тут работа с анимацией.
Audio - значит возможно тут работа со звуком
Weapon - значит возможно тут работа с оружиями.
и.т.д
Дальше проще, смотрим название, читаем комментарии (если есть), анализируешь что с чем связывается.
Не всё так сложно как кажется на самом деле.
 
Бро, надо просто пробегаться по коду, смотреть, за что +- отвечает каждый файл. Что к чему связывается и какие хранит функции.
Если надо что-то дописать\переписать, вспоминаешь где это хранится и где используется, чтобы там тоже поменять.
Легче читать в IDE, так как там проще навигацию делать по прототипам функций.
Короче кратко везде проходишься, учишь все как стих примерно.
Далее подробно разбираешь нужный тебе модуль.
Просто бывают еще проекты, где куча файлов в одной папке. В одном файле 5 классов, максимально разных)
Тут опыт тоже важен
 
На каждый разбитый модуль есть наименование, уже от него понятно что кроется внутри, читаем название:
Animation - значит возможно тут работа с анимацией.
Audio - значит возможно тут работа со звуком
Weapon - значит возможно тут работа с оружиями.
и.т.д
Дальше проще, смотрим название, читаем комментарии (если есть), анализируешь что с чем связывается.
Не всё так сложно как кажется на самом деле.
Так это одна из множества подпапок

 
Бро, надо просто пробегаться по коду, смотреть, за что +- отвечает каждый файл. Что к чему связывается и какие хранит функции.
Если надо что-то дописать\переписать, вспоминаешь где это хранится и где используется, чтобы там тоже поменять.
Легче читать в IDE, так как там проще навигацию делать по прототипам функций.
Короче кратко везде проходишься, учишь все как стих примерно.
Далее подробно разбираешь нужный тебе модуль.
Просто бывают еще проекты, где куча файлов в одной папке. В одном файле 5 классов, максимально разных)
Тут опыт тоже важен
Спасибо за ответ. А то я смотрю, энтузиасты даже код линукс дистрибутивов переписывают, исправляя там ошибки. Думаю что это за гении..
 
Разбитый на много директорий, модулей итд..

взять например реверснутую гта вайс сити
Посмотреть вложение 104818
как в этом всем разобраться? зачем? просто очень хочется. Но не понятно ничего, что за что отвечает, что с чем связано и с чего начать.. Сразу путаешься

опытные программисты дайте пожалуйста советов
Есть мнение что сегодня разработка без ИИ под рукой, говно мамонта. Насчёт разработки могу поспорить, но буквально на днях читал сурс на heskell при помощи https://github.com/features/copilot и знаешь, помогло ;-)
 
Последнее редактирование:
Всё сильно зависит от того для чего тебе это нужно.
Если просто почитать для роста над собой - это одно.
Если у тебя есть конкретная задача по доработке проекта - это другое.
Но в любом случае везде применим метод определенного интеграла - бьем задачу на маленькие кусочки, в каждом кусочке берем по точке, вычисляем значение в этой точке и суммируем.
Я рассмотрю случай из личной практики, когда мне дали проект, пару дней на разобраться и тут же накидали на тебя в таск-трекер кучу задач по доработке. Проекту много лет. Писали его разные люди. Проект с закрытым исходным кодом, то есть в гугле по нему чуть меньше чем ничего. Разные модули написаны с использованием разных стандартов языка, причем очень много собственных аналогов STL, оптимизированных под данный продукт.

Поскольку я на тот момент уже позиционировал себя как синьор-помидор, то и спрос был соответствующий.
У меня был куратор, которому я мог задавать вопросы, но поскольку он был очень занятой дядька, то вопросы должны быть точными.
Еще была система контроля версий, правда вместо любимого и общепринятого гита была черепашка (CVS). В общем весело.
А, еще забыл добавить , что проект представлял собой несколько десяткой решений в старой доброй VisualStudio. Причем там были сборки от 2008 студии до 2019 включительно. А суммарный объем репозитория в прямом смысле "до хуя".
Что делать?
1) Взял таску из трекера. Прочитал. Покурил. Повторял, пока не пришло понимание сути задачи. Главное не сорваться в бесконечный цикл.
2) Поскольку задачу составлял опытный дядька, то она была рассчитана на самых маленьких и тупеньких. То есть там были подсказки в виде ключевых слов и названий модулей, в которых следует вносить изменения. Это я к тому, что если вам задачу поставили не так, то пытайте постановщика задачи. В этом нет ничего зазорного.
3) Делаем поиск по ключевым словам. Определяемся с примерным местом внесения изменений.
4) Делаем новую ветку для проведения экспериментов. С черепахой такой номер так просто не прокатит. Я первое время мозг часто морщил, пытаясь перестроиться. А вот с гит - пожалуйста.
5) обязательно уточните про логги. Логи - наше всё. Вносим изменения, логгируем
6) Если вы угадали с местом внесения изменений - коммитим, в комментарии к коммиту указываем максимально подробную информацию.

У меня первая задача была очень простая. Условно говоря исправить опечатки в кнопках и там еще чет простенькое, не помню уже. А вот следующие задачи уже было сложнее.
Тут уже мне пришлось морщить мозг основательно.
Первое что я сделал - это скормил исходники doxygen, который построил мне диаграммы вызовов и сгенерировал документацию. Нет, документация в проекте была шикарная, но мне очень не хватало привычных инструментов. Ну и посмотреть data flow диаграммы тоже не мешало бы.
Я использовал https://code2flow.com/. Очень удобная штука.
В общем потихоньку у меня получилось разобраться в коде проекта. Не во всём, да оно и не требовалось. Примерный алгоритм действий я описал. При изучении кода для собственного развития рекомендую следовать по той же схеме. В любом случае одного чтения недостаточно для того чтобы разобраться. Вам придется вносить изменения. А для этого, для начала, требуется понимание крупноблочной структуры проекта и механизмов взаимодействия между блоками. Поэтому стрроим диаграммы, вычленяем модуль, который хотим изменить, затем уже его бьем на части и рекурсивно идем до нужного места. Вносим изменения. Тестируем, в случае успеха фиксируем результат. Ну и не забываем про документацию. Её иногда пишут для того чтобы ее читали.
 


Напишите ответ...
  • Вставить:
Прикрепить файлы
Верх