8 Рад для швидкого розуміння чужого коду, бібліотека програміста

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

Таке часто трапляється з проектами, що дісталися «у спадок» від попередніх розробників. Вам вже треба писати нові блоки, а в старій базі over 9 000 строк коду. Як швидко освоїтися і не потонути юному падаванів?

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

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

  1. Попросіть наставника пояснити вам цілісну структуру коду, його філософію і стиль. Пориньте в історію проекту, розпитайте, чому система саме така і якою вона була раніше. Якщо в коді використовуються сторонні фреймворки і бібліотеки, складіть їх список. Вивчіть окремо мануали і документацію цих сторонніх ресурсів, це допоможе потім вичленувати їх із загальної маси коду.
  2. Попросіть дати вам просте завдання (пофиксить баг, додати фичу), яке під силу будь-якому новачкові.
  3. Сядьте, заспокойтеся, дихаєте рівно. Намагайтеся виконати завдання самостійно, але попросіть наставника підійти до вас через 15-20 хвилин. Як правило, за 15 хвилин можна розібратися майже в усьому; якщо не виходить за 15 хвилин - не вистачить і кількох годин. Тому, якщо ви застрягли, припиняйте роботу і запитайте поради.
  4. Код-рев'ю. Надішліть код на рев'ю наставнику. Отримайте від нього цінні вказівки про те, які шматки існуючого коду можна використовувати в конкретній ситуації і як правильно вбудувати ваші зміни в код.
  5. Повторіть кроки 2-4.
  1. Розкрийте палати розуму: постарайтеся охопити всю картину цілком. Визначте основні модулі та їх функціональність. На це звичайно потрібно 2-3 дні по 6-7 годин. Побродите по модулях, познайомтеся з ними ближче.
  2. Зайдіть в баг-трекер. Пошукайте виправлені баги і вивчіть способи, якими вони виправлялися. По можливості звертайте увагу на ті баги, які виправлялися досвідченими учасниками проекту. Створіть окрему гілку з кодом, де баг ще не виправлений; і окрему з кодом, де баг виправлений. Подивіться на зміни в файлах і на змінені шматки коду. Зверніть увагу на два моменти: а) що і як виправляє багфикс; б) чому фікс реалізований саме так. На цю роботу теж необхідно витратити 2 дні (проаналізувати 2-3 бага).
  3. Час фіксують самому. Знайдіть декілька простих багів в баг-трекері і спробуйте їх виправити. Почніть з визначення модуля, в якому задіяний баг. Якщо ви добре попрацюєте над кроком 1, на це не знадобиться багато часу. Найскладніше - виправити баг так, щоб не вибиватися з основних принципів проектування в даному проекті. Можна спробувати написати пробний фікс, не особливо намагаючись відповідати загальній структурі проекту, просто щоб перевірити, чи працює фікс чи ні. Якщо працює, міняйте фікс, вже дотримуючись усіх прийняті правила реалізації.
  4. Напишіть нову фічу. Якщо ви розібралися у всіх модулях і маєте уявлення про їхню роботу, написання нової фічі не надасть особливої ​​складності. Чи не складніше, ніж робота з API. Найскладніше - зробити фічу універсальної (щоб її могли використовувати інші).

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

- Що робить цей код?
- Як він це робить?
- Що потрібно зробити, щоб він став краще?
- В якому місці це потрібно зробити?

Переклад написаний Люсею Ширшова.


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

[...] повинен знати кожен програміст? 8 порад для швидкого розуміння чужого коду Як перетворити програмування в професійне [...]

Наш паблік ВКонтакте

випадкові статті

8 Рад для швидкого розуміння чужого коду, бібліотека програміста