Як ви стежите за великими проектами?

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

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

Зараз я опинився в ситуації, коли мені потрібно взаємодіяти з великим проектом PHP Zend Framework, який розробив хтось інший, і я перевантажений спробою зрозуміти код, який поширюється на численні файли.

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

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

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

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

Немає ярлика. Ви просто мусите через це страждати.

Щоб відповісти на ваше запитання про те, як отримати діаграми, доксиген - це те, що ви хочете. AFAIK працює з PHP.

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

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

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

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

4. Отримайте доступ до всього процесу розгортання (найкраще це робити, коли оригінальні розробники тримаються за вашу руку). Якщо ви не можете взяти поточну базу коду і створити її і розгорнути через тестове / перевірочне / prod середовище, тості. Навіть найменша зміна вимагатиме перестрибування через усі обручі розгортання, то чому б не одразу ж опустити цю частину? Тим самим ви познайомитеся з усіма прекрасними серверами, базами даних, службами та сценаріями, якими користується додаток. Ви дізнаєтесь, де він живе.

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

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

---- Зауважте, що до цього часу я навіть не згадував уважно придивлятися до кодової бази. Є ЛОТ , з яким можна дізнатися про великий проект, навіть не дивлячись на код. У якийсь момент, звичайно, вам доведеться погодитися з кодом. Ось що мені допомагає:

7. Для діаграм доксиген - це чудовий інструмент, який створюватиме графіки викликів та інші відносини для вас. Трапляється, є можливість PHP! Якщо ви ще не пробували доксиген, вам абсолютно доведеться віджимати його. Хоча я не можу поручитися, наскільки зрозумілим він буде для коду в рамках, але це може допомогти. Оригінальні розробники часто шоковані тим, що вони бачать, коли їх представляють доксигенні документи свого коду. Хороша новина полягає в тому, що це дійсно допомагає пробігти їх пам’ять і допомогти вам краще.

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

9. Закладки IDE безцінні для тегування гарячих точок у кодовій базі. Вміння швидко перемикати їх сприятиме розумінню.

10. Читання останніх звітів про помилки та їх вирішення також є цінним для розуміння «гарячих точок» і допоможе вам досягти швидкості на найбільш релевантних частинах кодової бази.

За запитом, ось мій коментар як відповідь.

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

Якщо база даних містить тести (інтеграція або блок), їх іноді також варто перевірити.

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

а) Визначте використану рамку програмування, яка допомагає дізнатися, як працює програма.

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

в) Запустіть загальні користувацькі потоки (у додатку), а потім спробуйте вирівняти їх, як викладено код

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

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

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

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

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

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

Що я отримую - це велика одиночна модель, складена з декількох підмоделей, кожна з яких складається з пакунків, складених класифікаторами і т.д. Я маю на увазі, що один і той же метод може викликати один класифікатор у проекті А, а інший класифікатор - у проекті B. Єдиний спосіб побачити повну структуру проекту - це повернути їх обох одночасно. У мене немає часу для створення компонентних діаграм, і інформація не дуже точна. Я вважаю за краще просити комп’ютер скасувати повний проект для мене. Я роблю реверс при кожній ітерації з командою, і всі мої діаграми одразу оновлюються. Зворотна інженерія є поступовою і використовує відображення ідентифікаторів Java на UML. Я маю на увазі, що кожен елемент java відображається на єдиний та унікальний елемент MOF, який залишається однаковим протягом усього життя проекту, навіть якщо його відновлено. Це не дає більше обмежень для моделювання UML та дозволяє дуже велике та складне моделювання проектів. Для вашої інформації я працюю з проектом, що містить понад 5 000 000 рядків коду OOP. Усі мої проекти змінені належним чином і можлива графічна навігація

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