Як читати тисячі рядків коду без будь-якої документації? [зачинено]

Раніше я шукав хороший контроль TimeLine для проекту WPF. Я знайшов відповідь в цьому , які направляють мене в цей проект CodePlex .

Тепер я хочу змінити код, щоб забезпечити мої потреби в культурі. Але є деякі невідповідності!

Моє запитання:

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

Редагувати:

Будь-який ярлик буде чудовим!

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

1. Крок через код
2. Перейменуйте за потребою
3. Рефактор за потребою
4. Повторіть, поки ви повністю не зрозумієте

... і код буде вам за це вдячний. ;-)

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

Щось, що Йоел Спольський написав ще колись у своєму блозі (зараз не можу знайти цю статтю) зі мною щодо цього:

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

Тому я думаю, що головне - просто бути повільними, методичними та науковими. А як вже казали інші - коментуйте це (і навіть рефактор), як ви йдете. Не впадайте в думку «Я повинен просто подивитися на це і зрозуміти негайно».

О, і так, я все ще інколи потрапляю в цю пастку. "Робіть, як я кажу, не так, як я", і все це. :)

SE-Radio опитало Дейва Томаса з цього приводу

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

Мені довелося це зробити нещодавно з проектом понад 100 000 LOC. Моя перша ідея полягала в тому, що легше бачити візерунки з графіків 100 або навіть 1000 вузлів, ніж із 100000 рядків тексту.

Тому я витратив 45 хвилин і написав коротку програму Python (<100LOC), щоб проаналізувати те, що мені потрібно від неї, та намалювати об'єктні відносини. Я створив джерело Graphviz , яке є дуже простою мовою. (Тут немає нічого особливого в Python: Ruby, C # або Common Lisp або все, що може зробити це так само добре.)

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

(Можливо, це тому, що я взяв компілятори , але мені здається дивним, що коли програміст стикається з проблемою, відповідь, як видається, завжди є "написати програму!", За винятком випадків, коли проблема стосується вихідного коду до програми.: - )

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

Зрозумійте, що насправді не існує ярликів до повної витримки. (І якщо у вас виникли проблеми з цією фразою, то ваша освіта дуже нехтувала. Це з "незнайомця в чужій країні", Роберт А. Хайнлайн.)

Прочитайте його, одну сторінку за раз, одну процедуру за раз. Додати коментарі. Намалюйте зображення основних структур даних. Розпізнайте алгоритми. Спирайтеся на попередні знання.

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

Що б ви не писали стільки, скільки можете, так як ви йдете разом, щоб ніхто ніколи не опинявся в такому самому положенні, як у вас.

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

читати 14 тисяч рядків коду Java не має сенсу. Функціональність пошуку - це ваше збереження життя

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

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

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

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

Я б почав з використання редактора Leo в режимі @shadow з активним використанням клонованих вузлів . Це дозволяє додавати примітки та коментарі до кожного досліджуваного розділу без зміни коду , а примітки завжди будуть у контексті, поруч із кодом, про який йдеться. Ось приклад робочого процесу документів:

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

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

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

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

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

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

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

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

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

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

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

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

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

І я переглянув документ http://queue.acm.org/detail.cfm?id=2063168, який розповідає про стиль кодування або про те, як ми можемо використовувати простір, відступ, зміну шрифту, як і більшість IDE, які ми можемо використовувати для написання СТОЛЬКО CLEANER код, де ми, люди, можемо зрозуміти стільки, скільки і машини. Більше наголошує на написанні коду для безкоштовного коментування, щоб наш код виглядав як самі абзаци.