Як найбільш ефективно налагоджувати код? [зачинено]

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

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

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

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

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

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

Останнє зауваження - я вважаю за краще називати помилки "помилками", а не "помилками" - Дейкстра попросив своїх колег за використання останнього терміна, тому що це нечесно, підтримуючи ідею, що згубні та непостійні феї помилок висаджують помилок у наших програмах, поки ми не були " t дивлячись, а не бути там через власне (неохайне) мислення: http://www.cs.utexas.edu/users/EWD/transcriptions/EWD10xx/EWD1036.html

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

1. Пишіть тести. Тестування не тільки чудово запобігає помилкам (на мій досвід, TDD правильно зробив усуває майже всі тривіальні, дурні помилки), але й дуже допомагає у налагодженні. Тестування змушує ваш дизайн бути досить модульним, що значно полегшує ізоляцію та копіювання проблеми. Також ви контролюєте довкілля, тому сюрпризів буде набагато менше. Більше того, як тільки ви отримаєте невдалий тестовий випадок, ви можете бути впевнені, що ви прибили справжню причину поведінки, яка вас турбує.

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

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

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

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

На цю тему я прочитала чудову книгу під назвою Why Programs Fail , в якій викладені різні стратегії пошуку помилок, починаючи від застосування наукового методу для виділення та усунення помилки, до дельтового налагодження. Іншою цікавою частиною цієї книги є те, що вона усуває термін "помилка". Підхід Зеллера такий:

(1) Програміст створює дефект у коді. (2) Дефект викликає інфекцію (3) Інфекція поширюється (4) Інфекція викликає збій.

Якщо ви хочете вдосконалити свої навички налагодження, я дуже рекомендую цю книгу.

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

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

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

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

1. З'ясуйте, у чому полягає сприйняття проблеми: перекладіть із замовника "Боб все ще не в системі" на "Коли я намагаюся створити запис користувача для Боба, це не вдається з повторюваним ключовим винятком, хоча Боб ще не є там'
2. З'ясуйте, чи це справді проблема чи просто непорозуміння (дійсно, Боб не там, нікого не називають bob, і вставка повинна працювати).
3. Спробуйте отримати мінімально надійні кроки, які ви можете виконати, щоб відтворити проблему - щось на кшталт "Враховуючи систему із записом користувача" Bruce ", коли користувальницький запис" Bob "вставляється, тоді виняток відбувається"
4. Це ваш тест - якщо можливо, помістіть його в автоматизований тестовий джгут, який ви можете запускати знову і знову, це буде неоціненним при налагодженні. Ви також можете зробити його частиною свого тестового набору, щоб гарантувати, що ця проблема не з’явиться знову.
5. Вийміть налагоджувач і починайте ставити точки прориву - з’ясуйте шлях коду під час запуску тесту та визначте, що не так. У той час як ви це можете зробити, ви можете також уточнити тест, зробивши його якомога вужчим - в ідеалі одиничним тестом.
6. Виправте це - перевірте тестові пропуски.
7. Переконайтеся, що вихідна проблема, як описано замовником, також виправлена ​​(дуже важливо - ви могли просто виправити підмножину проблеми). Переконайтесь, що ви не ввели регресії в інших аспектах програми.

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

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

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

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

1. Визначте, чи дійсно є помилка. Помилка ВЖЕ є різницею між поведінкою системи та вимогами; тестер повинен бути в змозі сформулювати очікувану та фактичну поведінку. Якщо він не в змозі забезпечити підтримку очікуваної поведінки, немає вимоги і немає помилок - просто чиясь думка. Відправте його назад.

2. Розгляньте можливість того, що очікувана поведінка неправильна. Це може бути пов’язано з неправильним тлумаченням вимоги. Це також може бути наслідком дефекту самої вимоги (дельта між детальною вимогою та вимогою бізнесу). Ви також можете їх відправити назад.

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

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

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

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

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

Коли ви дізнаєтесь, де знаходиться помилка, і можете придумати її виправлення, ось хороша процедура її виправлення:

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

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

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

Ось як я це роблю:

1. кожен раз використовуйте той самий метод, щоб знайти проблему. Це покращить ваш час реакції на помилки.
2. Найкращий спосіб - це, мабуть, читання коду. Це тому, що вся інформація доступна в коді. Вам просто потрібні ефективні способи знайти правильну позицію та вміння зрозуміти всі деталі.
3. налагодження дуже повільним способом, і це необхідно лише в тому випадку, якщо ваші програмісти ще не розуміють, як комп'ютер виконує інструкції asm / не може зрозуміти стеки викликів та основні речі
4. Спробуйте розробити такі методи доказів, як використання прототипів функцій для міркування про поведінку програми. Це допоможе швидше знайти правильну позицію

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

Припускаючи, що ви перебуваєте у виробничому середовищі, ось що вам потрібно зробити:

1. Правильно опишіть "помилку" та визначте події, які спричиняють її ставлення.

2. Визначте, чи "помилка" - це помилка коду чи помилка специфікації. Наприклад, введення імені з 1 літерою може вважатися помилкою для деяких систем, але прийнятною поведінкою для інших систем. Іноді користувач повідомляє про помилку, яку він / вона вважає проблемою, але очікування користувача щодо поведінки системи не входило до вимог.

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

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

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

6. Задокументуйте епізод адекватно.

7. Відпустіть виправлення (або нову версію)