Поради щодо налагодження з дуже малою інформацією? [зачинено]

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

З усім цим я можу займатися більшу частину часу без проблем.

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

В основному, це зводиться до цього:

• Велика і складна база коду, я не на 100% знайомий
• За багатьма способами все може піти не так
• Дуже мало інформації про те, як з'явилася помилка

Хтось має поради, підказки, пропозиції тощо, як налагодити подібні речі?

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

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

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

Гарним початком може стати ця книга .

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

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

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

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

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

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

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

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

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

Продовжуйте ітерацію, поки не зрозумієте базу коду.

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