Якщо ви щойно ознайомилися з новим проектом, що перше, що ви шукаєте, щоб зрозуміти, як він працює?
Ви спочатку шукаєте дизайн? Якщо є дизайн, що ви шукаєте в ньому? Діаграми класів або діаграми розгортання або діаграми послідовностей чи щось інше?
Або ви йдете прямо за кодом? Якщо так, то як ви розумієте, як взаємодіють різні шари?
Відповіді:
Я починаю з коду. Окремі проектні документи, якщо такі є, настільки ж ймовірно помиляються або неправильно сприймаються, як ні. Отже, я починаю з спроби простежити якийсь простий потік через код; якщо це веб-версія, наприклад, це може бути запит або послідовність запитів. Після того, як я це зробив, у мене є своєрідний скелет, на який я можу повірити більше розуміння. Тоді я можу повернутися назад і прочитати проекти чи іншу документацію, але в цей момент у мене є щось конкретне, щоб їх пов’язати і підтвердити, щоб я міг виявити інформацію про сумніви. Або я можу просто продовжувати читати код, або тестувати справи тощо.
Я б почав з вищого рівня. Якщо є будь-яка документація, що стоїть перед користувачем - керівництво користувача або керівництво. Якщо цього не зробити, то подивіться на специфікацію вимог, щоб мати уявлення про те, що програмне забезпечення повинно робити. Я б хоч подивився на дизайн і спробував відобразити його на файли коду. Сподіваємось, вони структуровані в папки певним чином. Тоді я б вибрав частину дизайну і зайшов у файли, щоб слідкувати за потоком коду, не надто забиваючись до дрібниць.
Я починаю з налаштування системи розробників. Я використовую документально підтверджену процедуру. Це випускає кота з сумки про те, наскільки документація синхронізована з реальністю.
Це також підказує мені, що таке залежності. Це має значення.
Тепер, коли у мене встановлена програма для розробників, (і я помічаю документ про налаштування з виправленнями під час переходу), я будую версію. Я врешті-решт задаю питання протягом усієї цієї фази.
Тепер він побудований, я виконую вступну вправу з посібника користувача. Це приблизно говорить про те, що насправді робить система.
Зараз у мене є часткова підказка щодо системи, я читаю проектні документи, які я зараз вважаю пропорційно тому, наскільки помилялися документи досі.
Як тільки я перейду до фактичної поведінкової документації, я можу почати вивчати код і бачити, що там насправді. Вони ніколи не складаються, але я тепер знаю, у скільки вірити.
Потім я дивлюся на вихід IDE для коментарів "todo" та "fixme". Такі речі, як "виправити у версії 2.0", теж є підказками.
Отож, справа в тому, щоб дізнатися правдивість, і як зазначають люди, окремі проектні документи рідко актуалізуються або коректуються, але це означає, що люди думали в певний момент часу. І звичайно, тих людей, мабуть, немає навколо для допитів.
Моя перевага - почати з розробки, щоб отримати огляд проекту та спробувати зрозуміти деякі його основні особливості та / або структуру, перш ніж деталізувати деталі.
Завжди дизайн. З кодом варто пройти кроки налаштування розробника (перевірити джерело, створити проект, внести будь-які зміни конфігурації), але немає сенсу намагатися дізнатися структуру програми з її коду. Це говорить лише про те, що це за структура, а не про те, чому це структура, або як думають інші розробники, що основні та погані моменти стосуються архітектури. Ті, кого ви дізнаєтеся з діаграм дошки та чатів з розробниками.
Щодо складного програмного забезпечення, я підійшов би до нього приблизно так, ніби це новий проект розвитку. Почніть з великих ідей - бачення, контексту, сфери, зацікавлених сторін. Прочитайте деяку документацію користувача та отримайте уявлення про те, як вона використовується. Якщо можливо (або застосовно), пройдіть навчання з програмним забезпеченням користувача. Потім почніть вивчати вимоги та проектну документацію, щоб отримати уявлення про те, як це працює на високому рівні. Порадьтеся з дизайнерами, якщо вони все ще є. Подивіться на архітектуру системи в різних перспективах. Звідти починайте розкопувати основні функціональні можливості та переглядати якийсь код, повертаючись до вимог та проектуйте у міру необхідності. Переглядаючи код, запустіть програмне забезпечення, щоб побачити його в дії. Увесь час складайте деяку підсумкову документацію для подальшого використання - ви володієте Примітками клієнтів. Відділіться до тих пір, поки ви не матимете гарного уявлення про те, як це все працює і поєднується разом, але концентруйтеся на частинах, з якими ви будете працювати. На даний момент ви розумієте всю систему або принаймні частини, що стосуються вас.
Звичайно, в реальному світі ви, можливо, не маєте часу пройти все це, перш ніж вам доведеться забруднити руки, особливо це стосується великих проектів. Але це я б робив, якби це залежало від мене.
Ви повинні працювати між самим кодом та будь-якими документами на проектування.
Ви можете почати з коду чи дизайну, і це насправді не має значення. Читайте код, доки ви не повніше і по-справжньому заплутаєтесь, а потім перегляньте документи дизайну. Або прочитайте документи дизайну, щоб отримати зображення високого рівня, а потім подивіться на код, щоб побачити, як він виглядає. Повторіть майже нескінченно, поки ви працюєте з кодом.
Майте на увазі, що дизайнерські документи майже завжди застаріли та багато в чому невірні. Однак, якщо ви пам’ятаєте про ці моменти, застарілі документи все ще допоможуть вам зрозуміти розум автора в якийсь момент минулого. Багато питань на високому рівні все ще залишатимуться в силі, і ви, швидше за все, зможете швидше зрозуміти, як дістався код, де він є, якщо ви навіть датуєте зображення того, куди автор спочатку думав, що збирається йти.
Під час роботи над кодом та дизайном створіть власні документи, які описують ваше розуміння коду сьогодні. Можливо, ці документи - це простий ескіз чи два, можливо, вони є записами у вікі, можливо, вони чимось іншим. Не робіть їх занадто складними: жодних документів на 30 сторінок. Просто занесіть свої ідеї, що значно прояснить ваше власне мислення.
Це залежить від типу програми. Якщо це додаток, орієнтований на дані, я зазвичай починаю з дизайну бази даних. Якщо у нього є інтерфейс користувача, ви можете запустити (або хороший дизайн екрана), він також може дати вам хороше уявлення про те, що додаток робить дуже швидко (я говорю тут не більше кількох годин). Після цього я починаю копатися в коді, і це матиме більше сенсу, оскільки я знаю, що робить додаток.
Почну з проектної документації. Зокрема, специфікація - яка говорить про наміри речі, на яку дивиться.
Якщо можливо, я розглядаю дизайнерські замітки та документацію, щоб отримати загальний аромат того, як це було зроблено, продуманого процесу, стилю та характеру зацікавлених людей.
Якщо можливо, я тоді розмовляю з людьми, які працювали над цим - що це робить? Як? Чому? Де поховані тіла?
Серед розробників існує тенденція стрибати в код: "Дозвольте показати вам цей код". Це добре для них, але, як правило, викрадає мої потреби - це розуміння того високого рівня, який дає контекст для матеріалів низького рівня.
Він використовує величезну кількість мозку для перегляду невеликих шматочків коду з повного контексту та розуміння будь-чого значимого. Тож, якщо можливо, змусити розробників поговорити про ПРИНЦИП, структуру, блоки, модулі, що б там не було, це спричинить оцінку завдання.
Тільки тоді варто спробувати потрапити в код.
У великій схемі речей погляд на код - це як перегляд сторінки, повної 0-х та 1-х. Є сенс, але це потрібно багато часу, щоб зрозуміти це. Ознайомлення з тим, де шукати та які деталі мають значення, допомагає звузити пошуковий простір.
Все, що було сказано - коли немає ні доко, ні людей, і лише код - тоді для цього немає нічого, крім дивитися на код.
У такому випадку я, як правило, не намагаюся зрозуміти це повільним глибоким читанням, я швидко проходжу, прочитуючи читання всього. Іноді це просто відкрити файли і сидіти, натискаючи клавішу вниз. Ви можете отримати дивовижну оцінку великої картини, просто зробивши це. (І в деяких випадках я навіть виконуючи файли, що виконуються рядками, і шукати їх, шукаючи підписи та шаблони. Це було надзвичайно плідно протягом останніх 20 років.)
Почну з тестів. Якщо одиничні тести та інтеграційні тести добре написані, вони описують випадки використання. Якщо вони недостатньо добре написані або взагалі не написані (на жаль, це багато в чому так), я починаю з вхідних точок у коді та співпадаю з тими, що мають дизайн.
Тоді я напишу тести для кожного випадку використання, виявленого деревом, яке ви знайдете після дослідження точок входу, для перевірки коду та використання утиліт покриття коду, щоб побачити, що мені не вистачає. Ці тести мені точно говорять, як працює код.
Я завжди намагаюся додати значення тому, на що я дивлюся; написання тестів, очищення коду, рефакторинг великих (20+ рядків) функцій.
Я вважаю, що створення документації само по собі не додає коду реального значення, оскільки воно ніколи не взаємодіє з кодом.
ну що таке "дизайн"? ЧИТАЙТЕ? uml-діаграма? ви можете зробити проект дизайну на півдорозі (і більшість), ви не можете кодувати на півдорозі
будь-який дизайн буде просто думкою , тоді як код - це факт
Я буду посилатися на вторинні документи лише тоді, коли я не можу зрозуміти міркування коду
читання коду - важливий навик розробника. Ви також можете навчитися цьому зараз, ви все одно не побачите багато корисної документації під час своєї кар’єри
Потім я дивлюся на README, TODO та змінник розробника. Якщо я не розумію, чому було написано програмне забезпечення, як воно було написане та куди воно йде ... Я не використовую його.
Створіть спочатку дизайн, потім код, зверху вниз, якщо хочете, тож я розумію контекст на кожному рівні, над яким я маю працювати.
Але якщо мені доведеться зробити дуже конкретну зміну, як-от виправити звіт чи розрахунок, я просто заходжу і дивлюсь на код.
Більш конкретно, мій підхід "дизайн перший" такий:
Я починаю з моделі домену, якщо така є, якщо такої немає, я будую хоча б базову (хорошим початковим моментом є модель даних). Він визначає "глосарій" програми та співвідношення між об'єктами (класами).
На ній зображено "якими об’єктами обробляються" шляхом застосування.
Потім я шукаю модель випадку використання, щоб з'ясувати, "які процеси виконуються" додатком, хоча я віддаю перевагу карті процесів, якщо така є, яка показує послідовності процесів.
Після цього я повинен мати гарне уявлення про додаток, і тоді я можу зайнятися розробкою змін.
До речі, вищевказана відповідь - у контексті бізнес-додатків.
Код не бреше. Звичайно хороша ідея, щоб спочатку оглянути проект, щоб зрозуміти, що він робить. Однак якщо ваше завдання полягає в тому, щоб детально зрозуміти, як працює проект, дивлячись на код, принаймні для мене, це як переглядати головоломку по частинах за винятком того, що з кожним класом, на який ви дивитесь, ви додаєте інший шматок головоломки. Якщо код добре структурований, ви можете побачити шаблон, що формується з імен класів, навіть не досліджуючи, що робить клас. У багатьох випадках з коду ви можете отримати підказки та підказки, які допоможуть вам у подальшому.
Нарешті, ви отримуєте те, що є безповоротним уявленням про те, що робить програма, завершеною головоломкою. Документація може бути неповною або неточною, але код ніколи не бреше. Все це ви можете зробити, не розуміючи, що робить кожен окремий метод. Не кожен може дізнатися про проект таким чином, але якщо ви робите це часто, вам стає простіше, не кажучи вже про те, що ви можете отримати суть програми середнього розміру за пару годин навчання. Хоча я гадаю, що все зводиться до уподобань.
Після того, як я побачу код найважливішого модуля / точки застосування: побачивши код, я можу перевірити якість конструкції.
Приклад:
Ви повинні працювати в управлінні додатками веб-програми над фінансовою звітністю.
Після того, як я прочитав код про повідомлення, початок і кінець програми (для ймовірного блокування в db), головний процес створення даних, про що потрібно повідомити тощо тощо (наприклад, при зберіганні газу основний процес стосується розрахунок запасів газу в сховищі споживачів з подачею та впорскуванням; вторинним процесом є виставлення рахунків за цими даними, попередньо обчисленими)
Я спочатку піду з дизайном, а потім кодом одночасно. Це дуже важливо, тому що всі проекти різні. Потрібно розробити план і високий рівень робочого процесу процесу від А до Я, перш ніж ви зможете одночасно працювати над кодами. Кожне прийняте рішення має бути задокументоване, щоб інші команди (або ви самі), які розробляють / розробляють коди, дізнаються про останнє оновлення та про те, що було підтверджено.
Якщо є хороший проектний документ високого рівня, я його використаю. Він повинен бути стислим та сучасним. Якщо це занадто багатослівно або застаріло, я опікую код.
Звичайно, це залежить від проекту, чи не так? Надзвичайно складний або багатогранний проект, можливо, краще підходити за допомогою документації (якщо документація достатньо ґрунтовна.)
На мій погляд, єдиний простий модуль або проста програма майже завжди найкраще підходить на рівні коду.
Немає правильної відповіді на кожну ситуацію!