Как разбираться в огромных исходниках?

Question

[Filipp42]

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

Comments

[Victor Bomberow]

Мне кажется, на этот вопрос не может быть однозначного ответа. Главное -
периодически нужно проветривать помещение и самому выходить на улицу, делать зарядку для глаз.
А так, все средства для визуализации хороши, лично мне нравится карандаш, ручка, ватман и стикеры. Нашел точку входа - и погнал.
Если есть документация - это, конечно, хорошо, а если есть знающие люди - это тоже замечательно. Но в любом случае, чтобы погрузиться в проект, как ни крути, придется код прочесть и как-то у себя в воображении отобразить.

[Северное Сияние]

Как разбираться в огромных исходниках?

нужно проветривать помещение и самому выходить на улицу

[Алексей]

Наверное имелось ввиду что выходить на улицу нужно через окно, которое открыли для проветривания помещения.

Answer 1

[TheAthlete]

В программировании есть такое понятие как модульность - большие системы делятся на модули, каждые из которых отвечают за свою часть работы - ядро linux, графическая подсистема, драйвера. Если взять ядро линукс, то там есть много модулей - драйвера на оборудование - видеокаты, звуковые карты и т.д. на самом нижнем уровне, подсистема для мултиплексирования ввода-вывода (select/poll/epoll) и т.д. Каждый разработчик занимается своей задачей, своим модулем в ядре Linux. Например, если ты пишешь на Node.js можно начать интерисоваться, что же внутри. И найти цепочку, которая ведет в ядро Linux (упрощенно): Node.js -> libuv -> epoll и далее разбираться, как этот системный вызов работает на уровне ядра и начать изучать исходный код ядра Linux для этого системного вызова.

Answer 2

[Андрей]

Самым твоим большим ограничением, внезапно, будет твоя собственная оперативная память, которая, в моменте, согласно исследований британских ученых, способна удерживать 7+-2 объекта (от 5 до 9 в среднем). Если у тебя объектов для рассмотрения тысячи, десятки тысяч или сотен тысяч и больше - желаю успехов. :)

Вторым твоим ограничением будет неспособность долго и пристально фокусироваться на процессе сканирования чужого кода. Внимание будет постоянно пытаться убежать куда-то, на что-то менее пугающее, что-то более понятное и привычное, приятное. Это называется прокрастинация, Макс Дорофеев фпомасч.

Более того, по мере сканирования кода будет возникать масса моментов, где непонятно что сделано, как сделано, зачем сделано, какие у этого последствия, соответственно все это надо расследовать отдельно и как-то запоминать, документировать, структурировать и пр. Что будет еще больше переключать из контекста в контекст и нужно уметь их фиксировать и как-то возвращаться, восстанавливать картину. Это весьма утомительно, а ресурс мозга таки ограничен.

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

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

Ах да, если ты уже успел подвыгореть, то всё вышесказанное сильно усугубляется.

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

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

Основные прорывы происходят именно в этом ресурсном состоянии. Искать надо его, если сумеешь найти и удержать - считай что ты счастливый человек.

Comments

[AlexHell]

согласно исследований британских ученых, способна удерживать 7+-2 объекта (от 5 до 9 в среднем). Если у тебя объектов для рассмотрения тысячи, десятки тысяч или сотен тысяч и больше - желаю успехов. :)

у этого есть продолжение, примерно следующее: можно объединять низкоуровневые объекты в высокоуровневые (для программирования это скажем подсистема графическая, в которую входят классы рисующие нечто, но в данный момент не важно как и что), и таких высокоуровневых объектов можно держать такое-же кол-во т.е суммарно около 6 (9 это врятли), но уровня - любого

Более того, по мере сканирования кода будет возникать масса моментов, где непонятно что сделано, как сделано, зачем сделано, какие у этого последствия, соответственно все это надо расследовать отдельно и как-то запоминать, документировать, структурировать и пр.

люто плюсую, и изза этого факта сам стараюсь писать код и документацию сразу (хотябы коменты - почему тут так сделано а не иначе)

[Filipp42]

AlexHell, Скажите, а функциональная парадигма в умеренных количествах, помогает в написании чистого и понятного кода?

[AlexHell]

Filipp42, любая парадигма или подход, примененный к месту может способствовать пониманию кода (и автором и потом читающими)

в моей практике и передача функций как аргументов - встречалась, это лучше чем паттерн "стратегия" из классического ООП (без ссылок на функции который)

[Андрей]

Filipp42, пониманию кода способствует мощная самодисциплина всех участников при его разработке, единые соглашения и контексты.

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

Мы практикуем довольно жесткое ревью кода. Но этот процесс ломается если сваливают ключевые разработчики. Но это уже продолб руклей.

Answer 3

[Северное Сияние]

Никак.
Если речь про коммерческие проекты, где сменилось 10 поколений разрабов, то всё делается методом тыка, с осторожностью. Если проект не подразумевает модульности или ООП, то это жопа.

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

Comments

[Qualiant]

А если код хорошо написан?

[Алексей]

А СУБД Oracle хорошо написана?
https://news.ycombinator.com/item?id=18442941

[Северное Сияние]

Qualiant,

А если код хорошо написан?

даже если хорошо, то чем больше кода, тем сложнее в нем разбираться.

[Qualiant]

Северное Сияние, но от этого есть польза. Вы же пишете, что пользы нет, даже если код хороший.

Answer 4

[Антон Р.]

- Как съесть слона?
- По кусочкам. И с кетчупом.

Comments

[profesor08]

Самому - никак, так как слон протухнет, а ты отравишься и сдохнешь.

[mkone112]

profesor08, разумеется его стоит предварительно заморозить, желательно до -200С.

[profesor08]

mkone112, на пару тысяч лет, чтоб когда дойдет время до трапезы, уже не было необходимости.

Answer 5

[profesor08]

Как разбираться в огромных исходниках?

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

Answer 6

[Ernest Faizullin]

надо разобрать логику проекта с разработчиком этого проекта. Иначе будет сложно, легче с нуля поднять тему, чем ковыряться.

Comments

[profesor08]

надо разобрать логику проекта с разработчиком этого проекта

Это бывает только во влажных фантазиях. В реальности разбираться будешь сам, даже спросить не у кого будет.

[Qualiant]

Лентюй,

потому что написание документации бизнес оплачивать не хочет

Смотря какой. Если бизнесмен реально бизнесмен, а не торгаш, и работает на перспективу, он понимает, что оплатить создание документации это дешевле, чем в будущем оплачивать человеко-часы, потраченные на то, чтобы разобраться в проекте наощупь.

Answer 7

[xmoonlight]

Профилирование и составление всей архитектурной схемы проекта (или его части).