Как быстро вникнуть в чужой код?

Question

[Славик]

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

Comments

[Сергей delphinpro]

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

[Славик]

Сергей delphinpro, что посоветуете? как выходите из положения?

Answer 1

[Иван Шумов]

Задавать окружающим вопросы. Ртом. Повторять пока не станет понятно

Comments

[Славик]

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

[Иван Шумов]

Славик, если для вас есть разница между офисом и удаленкой в "простоте" получения информации то (нужное подчеркнуть):

• вы не готовы к удаленке
  
• команда не готова к удаленке
  
• нет документации
  
• людям выгодно не делиться знанием о системе
  
• команда сама не в курсе о том чем занимается
  

[Saboteur]

Славик, Как раз на удаленке проще.
Можно спокойно задавать вопросы в письменном виде, с примером кода или названием файла, получать ответ, который не надо сразу запоминать, а можно всегда перепрочитать позже, или даже поиском пользоваться по чату/емайлу

[Славик]

Saboteur, Иван Шумов, Все понял, спасибо.

Answer 2

[DevMan]

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

при затыках иду штормить окружающих. но не раньше собственных попыток въехать.

Answer 3

[res2001]

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

Comments

[Славик]

Документации к сожалению нету.

[res2001]

Славик, Если документации нет, то сложить представление о коде можно погоняв ПО в разных режимах в качестве пользователя.

Answer 4

[Владимир Коротенко]

Привет всем сторонникам самодокументирования

По идее у вас должна быть вика с описанием архитектуры и списка методов

При подключении к проекту только просматриваете комменты и понимаете как оно работает

Если же нужно рефакторить то начинайте с комментов дальше прочитайте метод три раза
Первый бегло
Второй раз вдумчиво с анализом где баг
Третий где что исправить

Потом уже начинайте писать код

Кстати поэтому хорошо получать пачку багов тогда у вас код не уйдёт из головы и вы быстрее все перепишите

Многозадачность она сложная как для компов так и для людей

Comments

[Славик]

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

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

[Владимир Коротенко]

Славик, у меня выходит быстро но код в общем то относительно однотипный плюс баги в основном появляются из за разных фиксов от Микрософт

Answer 5

[approximate solution]

Как быстро разобраться в чужом кодировании и полноценно влиться в проект?

Если коротко, никак. И это как правило не нужно(выстрел в ногу).

Если менее коротко:
При трудоустройстве компания закладывает n-ное количество времени\денег для того что бы вы аккумулировали свой опыт и знания на проект, т.е постепенно влились в командную разработку путем чтения документация, настройки окружения, и тому подобного. В зависимости от проекта, может занимать от пары месяцев, до полугода(если мы говорим про крупный проект кровавого интерпрайза).

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