Який найкращий спосіб ознайомитися з великою кодовою базою? [зачинено]

Приєднання до існуючої команди з великою кодовою базою, яка вже існує, може бути страшним. Який найкращий підхід;

• Широкий; спробуйте отримати загальний огляд того, як все пов’язано, з коду
• Вузький; зосередьтеся на невеликих розділах коду за раз, розуміючи, як вони працюють повноцінно
• Виберіть функцію, яку ви хочете розвивати та вчитися
• Спробуйте отримати розуміння із діаграм класів та uml, якщо вони є (та актуальні)
• Щось зовсім інше?

Я працюю над тим, що наразі є програмою та бібліотекою C ++ на рівні близько 20 тис. Рядків (Редагувати: невелике за великою схемою!). У промисловості, я думаю, ви отримаєте вступ від досвідченого програміста. Однак якщо це не так, що ви можете зробити, щоб якнайшвидше почати додавати вартість?

-
Короткий зміст відповідей:

• Пройдіть по коду в режимі налагодження, щоб побачити, як він працює
• Створіть пару з кимось, хто більше знайомий з базою коду, ніж ви, по черзі ставши людиною, яка кодує, і людиною, яка спостерігає / дискутує. Обертайте партнерів серед членів команди, щоб знання поширювались навколо.
• Написати модульні тести. Почніть із твердження про те, як, на вашу думку, працюватиме код. Якщо вийде так, як ви очікували, ви, мабуть, зрозуміли код. Якщо ні, вам потрібно розгадати головоломку та зробити запит. (Дякую Донале, це чудова відповідь)
• Пройдіть існуючі модульні тести функціонального коду, аналогічно вищенаведеному
• Прочитайте UML, діаграми класів, генеровані Doxygen, та іншу документацію, щоб отримати широке уявлення про код.
• Виконайте невеликі редагування або виправлення помилок, а потім поступово накопичуйте
• Робіть нотатки, і не стрибайте і не починайте розвиватися; цінніше витратити час на розуміння, ніж створювати брудний або невідповідний код.

ця публікація є частковим копією найкращого способу ознайомитись із спадковою базою коду

Почніть із невеликого завдання, якщо це можливо, налагодьте код навколо вашої проблеми. Перехід через код у режимі налагодження - це найпростіший спосіб дізнатися, як щось працює.

Інший варіант - написати тести для функцій, які вас цікавлять. Налаштування тестового джгута - це хороший спосіб встановити, які залежності має система і де знаходиться її стан. Кожен тест починається з твердження про те, як ви вважаєте, як повинна працювати система. Якщо виявляється, що це працює так, ви чогось досягли, і у вас є якийсь робочий зразок коду для його відтворення. Якщо це не працює так, у вас є головоломка, яку потрібно розв’язати, і рядок запитів, який слід виконати.

Одне, що я зазвичай пропоную людям, про яке ще не згадували, - це те, що важливо стати компетентним користувачем існуючої бази кодів, перш ніж стати розробником. Коли до нашого великого програмного проекту приходять нові розробники, я пропоную їм витратити час на те, щоб стати досвідченими користувачами, перш ніж зануритися, намагаючись попрацювати над кодом.

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

Це цілком залежить від того, який тип учня і який ви програміст, але:

• По-перше, широко - потрібно уявлення про масштаб та розмір. Це може включати обробку документів / uml, якщо вони хороші. Якщо це довгостроковий проект, і вам буде потрібно повне розуміння всього, я дійсно можу прочитати документи належним чином. Знову ж таки, якщо вони хороші.
• Вузьке - виберіть щось кероване і спробуйте зрозуміти це. Отримайте "смак" коду.
• Виберіть функцію - можливо, іншу, ніж ту, яку ви щойно переглянули, якщо ви впевнені в собі, і почніть робити невеликі зміни.
• Повторіть - оцініть, наскільки добре все пішло, і подивіться, чи зможете ви скористатися більш глибоким повторенням ранніх кроків.

Сполучення із суворим обертанням.

Якщо можливо, переглядаючи документацію / базу кодів, спробуйте застосувати сполучення із суворою ротацією. Це означає, що ви двоє сидите разом протягом певного періоду часу (скажімо, 2-годинний сеанс), потім ви перемикаєте пари, одна людина продовжує працювати над цим завданням, а інша переходить до іншого завдання з іншим партнером.

Удвох ви обидві підбираєте знання, які потім можуть передаватися іншим членам команди, коли відбувається ротація. Що хорошого в цьому також, так це те, що коли об’єднується нова пара, той, хто працював над завданням (в даному випадку досліджуючи код), може узагальнити та пояснити поняття в більш зрозумілій формі. З плином часу всі повинні бути на подібному рівні розуміння і, сподіваємось, уникати синдрому "О, тільки Джон знає цю частинку коду".

З того, що я можу сказати про ваш сценарій, у вас є хороший номер для цього (3 пари), однак, якщо ви розподілені або не працюєте за однаковим часовим шкалою, це навряд чи стане можливим.

Я б запропонував запустити на ньому Doxygen, щоб отримати сучасну схему класів, а потім на деякий час увійти в систему. Це дає вам швидке велике зображення, яке ви можете використовувати, коли ви наближаєтесь і забруднюєтеся кодом.

Я погоджуюсь, що це повністю залежить від того, якого типу ти навчаєшся. Сказавши це, я був у двох компаніях, які мали дуже великі кодові бази для початку. Як правило, я працюю так:

Якщо можливо, перед тим, як переглянути який-небудь функціональний код, я проходжу вже написані модульні тести. Загалом вони можуть дуже допомогти. Якщо вони недоступні, я роблю наступне.

По-перше, я в основному ігнорую реалізацію і переглядаю лише файли заголовків або просто інтерфейси класу. Я намагаюся зрозуміти, яка мета кожного класу. По-друге, я заглиблююся на глибину впровадження, починаючи з того, що, здається, є сферою, яка є найбільш важливою. Це важко оцінити, тому час від часу я просто починаю зверху і просуваюся вниз у списку файлів. Я називаю це навчанням на перших широтах. Після цього початкового кроку я, як правило, глибоко переглядаю решту коду. Початковий погляд на широту допомагає закріпити / виправити будь-які ідеї, які я отримав від рівня інтерфейсу, а потім глибокий погляд показує мені шаблони, які були використані для впровадження системи, а також різні ідеї дизайну. Під глибиною спочатку я маю на увазі, що ви в основному проходите програму за допомогою налагоджувача, вступаючи в кожну функцію, щоб побачити, як вона працює, і так далі. Очевидно, що це неможливо з дійсно великими системами, але 20k LOC не так вже й багато. :)

Попрацюйте з іншим програмістом, який більше знайомий із системою, щоб розробити нову функцію або виправити помилку. Це метод, який я бачив як найкраще працює.

Думаю, вам потрібно пов’язати це з певним завданням. Коли у вас є час, перейдіть до того, до якого підходу ви налаштовані.

Коли у вас є щось, що потрібно зробити, зосередьтеся на вузькому фокусі і виконуйте це.

Запропонуйте команді виправити помилки на два тижні (якщо у вас є два тижні). Вони із задоволенням змусять когось взяти на себе відповідальність за це, і до кінця періоду ви витратите стільки часу на вирішення проблем із бібліотекою, що ви, мабуть, знаєте це досить добре.

Якщо у нього є модульні тести (я впевнений, що цього немає). Почніть з малого і переконайтесь, що модульні тести не провалилися. Якщо ви одразу вдивитесь у всю базу кодів, ваші очі засклять, і ви будете почувати себе пригніченими.

Якщо немає модульних тестів, вам потрібно зосередитися на тій функції, яку ви хочете. Запустіть програму та перегляньте результати речей, на які ваша функція повинна вплинути. Потім починайте переглядати код, намагаючись з’ясувати, як додаток створює речі, які ви хочете змінити. Нарешті змініть його та перевірте, щоб результати вийшли потрібними.

Ви згадали, що це додаток та бібліотека. Спочатку змініть програму та дотримуйтесь використання бібліотеки як користувача. Тоді після вивчення бібліотеки її буде легше змінити.

Починаючи зверху вниз, програма, ймовірно, має основний цикл або основний графічний інтерфейс, який контролює всі дії. Варто зрозуміти основний потік управління додатком. Варто прочитати код, щоб дати собі широкий огляд основного потоку програми. Якщо це програма з графічним інтерфейсом, створіть папір, який показує, які екрани є та як переходити з одного екрана на інший. Якщо це програма командного рядка, як виконується обробка.

Навіть у компаніях не рідкість мати такий підхід. Часто ніхто до кінця не розуміє, як працює програма. І люди не встигають вас розвести. Вони віддають перевагу конкретним питанням про конкретні речі, тому вам доведеться копатись та експериментувати самостійно. Потім, коли ви отримаєте своє конкретне запитання, ви можете спробувати виділити джерело знань для цієї частини програми та задати його.

Почніть з розуміння «проблемного домену» (це система оплати праці? Інвентаризація? Контроль у реальному часі чи що інше). Якщо ви не розумієте жаргону, який використовують користувачі, ви ніколи не зрозумієте коду.

Потім подивіться на об’єктну модель; можливо, вже існує схема, або, можливо, доведеться здійснити інженерну схему (або вручну, або за допомогою інструменту, як запропонував Дуг). На цьому етапі ви також можете дослідити базу даних (якщо така є), якщо слід слідувати об'єктній моделі, але це може не робити, і це важливо знати.

Погляньте на історію змін або базу даних про помилки, якщо існує якась область, яка часто з’являється, спочатку вивчіть цю частинку. Це не означає, що він написаний погано, але що це той біт, яким користуються всі.

Нарешті, робіть кілька приміток (я віддаю перевагу вікі).

• Існуючі хлопці можуть використати це, щоб осудно перевірити ваші припущення та допомогти вам.
• Вам доведеться повернутися до нього пізніше.
• Наступний новий хлопець у команді вам справді подякує.

У мене була подібна ситуація. Я б сказав, що ви йдете так:

• Якщо це додаток, керований базою даних, почніть з бази даних і спробуйте зрозуміти кожну таблицю, її поля, а потім відношення до інших таблиць.
• Оправившись із основним сховищем, перейдіть до рівня ORM. Ці таблиці повинні мати якесь представлення в коді.
• Закінчивши це, перейдіть до того, як і звідки беруться ці предмети. Інтерфейс? який інтерфейс? Будь-які перевірки? Яка попередня обробка відбувається у них перед тим, як вони йдуть до сховища даних?

Це краще ознайомить вас із системою. Пам'ятайте, що спроба написати або зрозуміти модульні тести можлива лише тоді, коли ви добре знаєте, що тестується і чому його потрібно тестувати лише таким чином.

А у випадку великого додатка, який не спрямований на бази даних, я б рекомендував інший підхід:

• Яка головна мета системи?
• Які основні компоненти системи вирішують цю проблему?
• Які взаємодії між собою має кожен із компонентів? Складіть графік, який відображає залежності компонентів. Запитайте когось, хто вже працює над цим. Ці компоненти повинні обмінюватися чимось між собою, тому спробуйте розібратися і з ними (наприклад, IO може повертати об'єкт File назад у графічний інтерфейс та подібні)
• Опинившись цим, зануртесь у компонент, який найменш залежний серед інших. А тепер вивчіть, як цей компонент далі поділяється на класи та як вони взаємодіють між собою. Таким чином, ви отримали зависання одного компонента в цілому
• Перехід до наступного найменш залежного компонента
• До самого кінця перейдіть до основного компонента, який, як правило, має залежність від багатьох інших компонентів, з якими ви вже працювали
• Переглядаючи основний компонент, можливо, ви повертаєтесь до тих компонентів, які ви раніше розглядали, тому не хвилюйтеся, продовжуйте працювати!

Для першої стратегії: візьмемо, наприклад, приклад цього сайту stackoverflow. Вивчіть сховище даних, що зберігається, як зберігається, які подання ці елементи є в коді, як де вони представлені в інтерфейсі. Звідки вони беруться і яка обробка відбувається на них, коли вони повертаються до сховища даних.

Для другого візьмемо, наприклад, приклад текстового процесора. Які там компоненти? IO, UI, Сторінка тощо. Як вони взаємодіють між собою? Рухайтесь далі, коли будете вчитися далі.

Будьте розслабленими. Письмовий код - це чиєсь мислення, заморожена логіка та стиль мислення, і на його читання знадобиться час.

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

Потім вам потрібно почати читати код деякий час без будь-якого тиску (пару днів або тиждень, якщо ваш начальник це забезпечить). Це часто допомагає скомпілювати / побудувати проект самостійно та мати можливість запустити проект в режимі налагодження, щоб ви могли пройти через код. Потім починайте мочити ноги, виправляючи дрібні помилки та роблячи невеликі покращення. Сподіваємось, ви скоро будете готові до середнього проекту, а згодом - до великого. Продовжуйте спиратися на своїх товаришів по команді, коли ходите - часто ви можете знайти того, хто бажає наставником вас.

Не будь занадто жорстким до себе, якщо борешся - це нормально. Щоб зрозуміти велику базу коду, може знадобитися багато часу, а може і років. Насправді часто трапляється так, що навіть через роки існують деякі частини коду, які все ще трохи лякають і непрозорі. Коли у вас простої між проектами, ви можете скопатись до цих областей, і часто ви виявите, що після кількох спроб ви можете зрозуміти навіть ці частини.

Удачі!

Можливо, ви захочете розглянути інструменти зворотного проектування вихідного коду . Я знаю два інструменти:

• Посилання SWAG Kit (лише для Linux)
• Академічна реклама Баугауза

Обидва інструменти пропонують подібні набори функцій, які включають статичний аналіз, який дає графіки взаємозв'язків між модулями в програмному забезпеченні.

Це в основному складається з графіків викликів та пристойностей типу / класу. Перегляд цієї інформації повинен дати вам хороше уявлення про те, як частини коду співвідносяться між собою. Використовуючи цю інформацію, ви можете скористатися фактичним джерелом деталей, які вас найбільше цікавлять і які вам потрібно зрозуміти / змінити спочатку.

Я вважаю, що просто перехід до коду може бути трохи приголомшливим. Спробуйте прочитати якомога більше документації щодо конструкції. Сподіваємось, це пояснить призначення та структуру кожного компонента. Найкраще, якщо існуючий розробник може провести вас через це, але це не завжди можливо.

Після того, як вас влаштовує структура коду високого рівня, спробуйте виправити помилку або дві. це допоможе вам зрозуміти фактичний код.

Мені подобаються всі відповіді, які говорять, що для отримання діаграми класів слід використовувати такий інструмент, як Doxygen, і спочатку спробувати зрозуміти загальну картину. Я повністю з цим згоден.

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

Подивіться цю відповідь про те, як використовувати інструменти тестового покриття, щоб знайти код для цікавої функції, не знаючи нічого про те, де ця функція, або як вона розподілена по багатьох модулях.

(попереду безсоромний маркетинг)

Вам слід перевірити nWire . Це плагін Eclipse для навігації та візуалізації великих баз коду. Багато наших клієнтів використовують його для проникнення нових розробників, роздруковуючи візуалізації основних потоків.