Як зануритися у великі бази коду?

Які інструменти та методи ви використовуєте для вивчення та вивчення невідомої бази коду?

Я думаю про такі інструменти, як grep, ctagsодиничні тести, функціональні тести, генератори діаграм класів, графіки викликів, кодові показники на зразок sloccountтощо. Мене зацікавлять ваші враження, помічники, якими ви користувались чи писали самі, та розмір бази коду, з яким працювали.

Я усвідомлюю, що ознайомлення з базою коду - це процес, який відбувається з часом, і знайомство може означати все, що завгодно, від "я вмію узагальнити код" до "я можу переробляти і скорочувати його до 30% від розміру". Але з чого навіть почати?

Я завжди робив таке:

Відкрийте кілька копій мого редактора (Visual Studio / Eclipse / Що б там не було), а потім налагоджуйте та виконайте розриви рядків, переступаючи код. Дізнайтеся про потік коду, простежте стеження, щоб побачити, де знаходяться ключові моменти, і перейдіть звідти.

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

Як ви їсте слона?

По одному укусі :)

Серйозно, я намагаюся спочатку поговорити з авторами коду.

Чи потрібно мені рубати, поки не закінчу роботу

Значною мірою, так (вибачте).

Підходи, які ви можете врахувати:

1. Спробуйте дізнатися, що повинен робити код, у бізнес-плані.
2. Прочитайте всю документацію, яка існує, незалежно від того, наскільки це погано.
3. Поговоріть з усіма, хто може щось знати про код.
4. Перегляньте код у відладчику.
5. Введіть невеликі зміни і подивіться, що порушується.
6. Внесіть невеликі зміни до коду, щоб зробити його більш зрозумілим.

Деякі речі, які я роблю для уточнення коду, є:

1. Запустіть засіб для вирівнювання коду, щоб добре відформатувати код.
2. Додайте коментарі, щоб пояснити, що я думаю, що це може зробити
3. Змініть назви змінних, щоб зробити їх зрозумілішими (використовуючи інструмент рефакторингу)
4. Використання інструменту, який висвітлює всі сфери використання певного символу
5. Зменшення безладу коду - коментований код, безглузді коментарі, безглузді ініціалізації змінних тощо.
6. Змініть код, щоб використовувати поточні умови коду (знову за допомогою інструментів рефакторингу)
7. Почніть витягувати функціональність у змістовні процедури
8. Почніть додавати тести, де це можливо (не часто можливо)
9. Позбудьтеся магічних чисел
10. Скорочення дублювання, де це можливо

... і будь-які інші прості вдосконалення.

Поступово сенс, що стоїть за цим усім, повинен стати зрозумілішим.

Що стосується місця для початку? Почніть з того, що ви знаєте. Я пропоную входи та виходи. Часто ви можете зрозуміти, що це таке і для чого вони використовуються. Прослідкуйте за даними через додаток і подивіться, куди вони йдуть і як вони змінюються.

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

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

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

Далі, я думаю, ваш запропонований підхід, безумовно, є хорошим кроком. Ви повинні спершу на високому рівні зрозуміти, яка мета коду.

Безумовно, працюйте з наставником чи кимось із команди, якщо вам доведеться відповісти на запитання.

Також скористайтеся можливістю підтримати код, якщо виявлені дефекти (хоча іноді для цього не потрібно зголоситися ... дефект знайде вас!). Користувачі можуть пояснити, для чого вони використовують програмне забезпечення та як дефект на них впливає. Це часто може бути дуже корисним знанням при спробі зрозуміти значення програмного забезпечення. Крім того, входження до коду з цілеспрямованою ціллю для нападу іноді може допомогти зосередити вас, коли ви зіткнетесь із «звіром».

Мені подобається робити наступне, коли у мене дійсно великий вихідний файл:

• Скопіюйте весь безлад на буфер обміну
• Вставте у Word / textmate все, що завгодно
• Зменшити розмір шрифту до мінімуму.
• Прокрутіть униз, дивлячись на шаблони в коді

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

Це вимагає часу

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

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

"Чому ти зробив цю частину таким чином"

"Я помітив, що більшість людей в Інтернеті роблять це так, а ви все робили по-іншому. Чому це?"

"Що змусило вас вибрати технологію X над технологією Y?"

Відповіді на ці запитання допоможуть вам зрозуміти історію проекту та обґрунтування рішень щодо проектування та впровадження.

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

cscope може робити все, що ctags може зробити для C, плюс, він також може перелічити, де називається вся поточна функція. Плюс це дуже швидко. Легко масштабується до мільйонів LOC. Акуратно інтегрується в emacs та vim.

Лічильник коду C і C ++ - cccc може генерувати кодові метрики у форматі html. Я використовував wc також для отримання LOC.

doxygen може генерувати виділений синтаксис та перехресний код у html. Корисно для перегляду великої бази кодів.

Те, як я рекомендую з Drupal, і це насправді не конкретно для Drupal: почніть з трекера проблем. Напевно з’являться старі незакриті звіти про помилки. Чи можете ви їх відтворити? Якщо так, оновіть квиток, що підтверджує його. Якщо ні, закрийте її. Ви знайдете таким чином безліч способів використання програмного забезпечення, і ви зможете зазирнути в кодову базу, де воно виходить з ладу. Або ви можете почати переглядати код і бачити, як він надходить до місця аварії. Таким чином, ви не просто почнете розуміти кодову базу, але й накопичите тонну карми, і ваші питання будуть щиро вітати громаду.

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

Колись у мене був досить фантастичний інженер-програміст, який сказав мені, що найдорожчою формою аналізу та обслуговування коду було проходження коду, по черзі; Звичайно, ми програмісти, і це дуже багато з цим приходить. Я вважаю, що щасливим носієм є: (у цьому порядку): 1. Отримайте зошит для створення нотаток про те, як ви розумієте, як працює код, і додайте до нього, як йде час. 2. Дивіться документацію про код 3. Поговоріть з авторами чи іншими особами, які підтримували базу коду. Попросіть їх про "мозковий дамп" 4. Якщо ви до кінця розумієте деякі відносини класів на рівні деталей, зробіть покрокову налагодження коду, щоб зробити деякий синтез між тим, як ви думали, що код працює, і як насправді працює код.

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

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

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

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

1. Запустіть усі тести, якщо вони є, і подивіться, який код охоплений, а який - ні.
2. Якщо код, який потрібно змінити, не охоплюється, спробуйте написати тести, щоб покрити його.
3. Змініть код. Не зламайте тести.

Див. “ Ефективна робота Майкла Пір’я із спадщинним кодексом”

Ось мій короткий список:

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

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

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

4. Наскільки добре я знаю мови та рамки, які використовуються в цьому проекті? Тут важлива різниця між поглядом на деякі речі та переходом: "Так, це бачили десяток разів раніше і знаємо це досить добре" та "Що у світі тут робиться?". Хто думав, що це гарна ідея? " такі питання, що, хоч я не сказав би їх вголос, я б думав про них, особливо якщо я дивлюся на застарілий код, який може бути досить крихким, а люди, які його написали, або недоступні, або просто не пам'ятаю, чому все робилося так, як було. Для нових областей, можливо, варто витратити трохи додаткового часу, дізнавшись, що таке структура та які шаблони я можу знайти в цьому коді.

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

• Ви додаєте нові функції?
• Ви виправляєте помилки?
• Ви рефакторинг код? Чи нові стандарти для вас чи вони дуже знайомі?
• Ви повинні просто ознайомитися з базою коду?

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

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

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

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

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

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

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

Я так багато зробив ...

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

1. Отримайте цілі, які система повинна вирішити (якщо вони не написані) - напишіть її. Запитайте менеджера, інших працівників, навіть колишніх, якщо вони є в наявності. Запитайте замовника або шукайте будь-яку частину документації.
2. Отримайте специфікацію. Якщо його не існує - напишіть його. Не варто просити когось про це, як ніби його не існує, тоді ви потрапляєте в ситуацію, коли інші не дуже переймаються. Тож єдиний спосіб написати власний (згодом це буде набагато простіше звернутися до нього).
3. Отримайте дизайн. Не існує - напишіть. Постарайтеся якомога більше посилатися на будь-які документи та вихідний код.
4. Напишіть детальний дизайн на частину, яку потрібно змінити.
5. Визначте, як ви її тестуєте. Таким чином, ви можете бути впевнені, що старий і новий код працюють однаково.
6. зробити так, щоб система могла бути побудована за один крок. І тест зі старим кодом. Покладіть його на SVC, якщо його ще немає.
7. Внесіть зміни. Не раніше.
8. переконайтесь через місяць або близько того, що нічого не порушено.

Ще один необов'язковий todo, який може знадобитися між кожним кроком: f off менеджер (власник проекту), який скаже вам, що "ці зміни потрібно зробити вже вчора". Після кількох проектів він може навіть почати допомагати отримувати специфікації та документи заздалегідь.

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

PS: Я пам'ятаю один код, який використовувався для 5 клієнтів з різними налаштуваннями. І кожна зміна (нова функція) вимагала думати про те, "які деталі використовуються" та "які клієнти конфігурації мають", щоб нічого не гальмувати і не копіювати код. Встановлення їхніх налаштувань для проектування відеороликів та написання специфікацій скорочує цей час на роздуми майже до 0.

Роздрукуйте вихідний код і починайте його читати. Якщо вона особливо велика, роздрукуйте лише окремі її частини, щоб краще зрозуміти та робити стільки приміток / коментарів, скільки вам потрібно.

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

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

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

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

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

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

Зазвичай я запускаю якийсь інструмент складності коду для коду, щоб повідомити мені, де є проблемні області. Області, які мають високий бал, можливо, дуже важко оновити. Наприклад, я зіткнувся з функцією, яка набрала 450 за цикломатичною шкалою. Звичайно, сотні ІФ. Дуже важко це підтримувати чи змінювати. Тож будьте готові до найгіршого.

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

Робіть невеликі кроки, навіть найменша зміна коду може мати великий вплив.

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

Якщо лише 1 метод / функція викликає C, то це досить безпечна зміна. Якщо 100 методів / функцій викликають C, це матиме більший вплив.

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

Якщо це велика кулька грязі, ви, можливо, ніколи не зрозумієте (або захочете зрозуміти) її внутрішню роботу.

Деякі речі, які я роблю ...

1) Використовуйте інструмент аналізу джерела, як Source Monitor, щоб визначити різні розміри модулів, показники складності тощо., Щоб відчути проект та допомогти визначити сфери, які нетривіальні.

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

3) Іноді я малюю схеми у Visio, щоб отримати кращу картину архітектури. Це може бути корисним і для інших у проекті.

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

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

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

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

Ось процедура, яку ми використовуємо для усунення дублікатів.

• виберіть стандартний префікс коментаря для дублікатів (ми використовуємо [dupe]відразу після маркера коментаря;
• пишіть специфікації зі своїми командами про імена, які слід використовувати для повторної процедури;
• перший раунд: всі беруть деякі файли та додають [dupe][procedure_arbitrary_name]перед дублюваною процедурою;
• другий раунд: кожен приймає процедуру або підмножину процедури і присвоює значення, що вказує на порядок подобається різним реалізаціям однакової мети (рядок буде тоді:) [dupe][procedure_arbitrary_name][n];
• третій тур: відповідальний за кожну процедуру переписує її у відповідний клас;
• четвертий тур: grepщасливий!

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

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

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

Маленька річ, яку я хотів додати:

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

Я рекомендую використовувати вільний літак серед безлічі варіантів вибору карти розуму.

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

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

Створення / оновлення документа про створення програмного середовища. Усі інструменти, примхи, встановлення варіантів тощо.

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

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

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

І хоча це не документація, пов’язана з цим проблема - це все химерні, вручну інтенсивні процедури, які роблять ваші товариші по команді. Автоматизуйте їх за допомогою пакетів, sql-скриптів тощо, і поділіться ними також. Зрештою, процедурні знання, напевно, такі ж великі, як декларативні знання з точки зору продуктивності в нових умовах. Що б там не було, не робіть цього; скоріше, скриптуйте його та запустіть сценарій. Риболовля знову б'є.

Я написав досить тривалий пост на цю тему. Ось уривок

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

1. Створіть аркуш словника
2. Вивчіть програму
3. Перегляньте наявну документацію
4. Зробіть припущення
5. Знайдіть сторонні бібліотеки
6. Проаналізуйте код

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

взято з: Процес для вивчення нової бази коду

Є кілька невеликих порад, якими я можу поділитися.

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

• Наступним кроком буде пошук коду, в який я можу прорватися і почати досліджувати. По дорозі я знайду залежні модулі, бібліотеки, рамки тощо.

• Наступним кроком буде створення простої діаграми класу з її обов'язками (як картки CRC)

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

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

Вже давно мені довелося зануритися у велику кодову базу. Але за останні кілька років я багато разів намагався залучати нових розробників до команд, де у нас була існуюча, досить велика база коду.

І метод, який ми успішно використали, і я б сказав, є найбільш ефективним способом без сумніву IMHO, - це парне програмування.

За останні 12 місяців у нас було 4 нових члени команди, і кожен раз новий член з'єднувався з іншим членом, добре знайомим з кодовою базою. На початку старший член команди мав би клавіатуру. Приблизно через 30 хвилин ми передамо клавіатуру новому члену, який буде працювати під керівництвом старшого члена команди.

Цей процес виявився досить успішним.