Відповіді:
Не припускайте нічого
Часто спокушати просто сказати "о, я знаю, що робить цей біт коду, це добре". Не робіть цього. Перевірте кожне припущення і ретельно пройдіть все.
Тестування поступово .
Перш заглибимось у свій код і протестуй його від найменшого модуля, який поступово рухається вгору. Таким чином, ти не зазнаєш великого стресу, намагаючись зрозуміти, де саме може бути проблема.
Це також означає, що він впливає на менший код одночасно, оскільки ви рухаєтесь поступово .. так як часом у мене виникали проблеми, коли я щось виправляв, і це призводить до порушення багатьох інших речей. Я вдячний своєму начальникові за це, коли він навчав мене цьому, коли я поспіхував.
Розділити і перемогти - це хороший підхід. Спробуйте визначити деякий видимий вхід (вхід користувача / подія мережі ...) та вихід (журнал, вихід для користувача, вихідне мережеве повідомлення ...), між якими існує проблема. Спробуйте поставити відбитки на значні шматки або значні точки між ними і спробуйте звузити місце, де помилка в коді.
Розділити і перемогти також може дуже добре у випадку регресії над кодом, керованим версіями. Знайдіть дві конструкції - одну, де вона працює, як очікувалося, інша з регресією. Зменшіть прогалину до тих пір, поки у вас не залишиться купа чеків як потенційних підозрюваних.
Замість того, щоб подрібнювати двійкові помилки, пишіть тести у формі
Щоб перевірити, що ви насправді знаєте, що це правда щодо функціонування програми, а не те, що ви вважаєте правдою.
Більшість IDE полегшують вилучення методів та генерацію тестових заглушок xUnit. Скористайтеся цим.
Чому б не посипати налагодження? Тому що після того, як ви закінчите, вам, ймовірно, доведеться скасувати більшу частину роботи та видалити неабияку кількість цих налагоджень. Коли ви пишете тести, ваша налагодження допоможе у запобіганні та виявленні майбутніх помилок.
Як казали інші - нічого не припускайте. Особливо це стосується коду, який ви написали. При налагодженні інших кодів ви швидше сповільнюєтесь, оскільки код для вас новий або ви не довіряєте кодеру. Під час налагодження власного коду занадто просто припустити, що ви його правильно написали, сповільнюйте!
Для фактичного процесу налагодження:
Додавання одиничних тестів та ведення журналу спочатку ефективніше, ніж спочатку використання налагоджувача. Ви також отримуєте додаткову перевагу від того, що одиничні тести допоможуть не вводити майбутні помилки, а реєстрація допоможе налагоджувати сесії в майбутньому.
Перш ніж перейти через невеликий фрагмент коду, подивіться, чи зможете ви точно визначити результат. Це, як правило, летить перед обличчям, щоб нічого не припускати (за що я проголосував BTW), але, як ви набираєтеся досвіду, це може допомогти звузити, де шукати.
Це може здатися тривіальним, але дізнайтеся нюанси налагоджувача та вивчіть гарячі клавіші. Іноді налагоджувачі можуть бути досить повільними, що ваш розум дивується, коли ви перебираєтесь. Якщо ви можете іти в ногу з машиною і не розгулюєтесь, це може допомогти.
Якщо ви можете змінити код під час налагодження:
подібно до:
bool isLessThan5 = a < 5;
bool isGreaterThan10 = a > 10;
if ( isLessThan5 || isGreaterThan10 )
{
// more code here
}
замість:
if ( a < 5 || a > 10 )
{
// more code here
}
У випадках, коли ви не можете все налагодити, з будь-якої причини навчитесь «гумову качку» з колегою. Іноді акт пояснення проливає світло. (гаразд, можливо, це не зовсім в темі питань, але я думаю, що це досить близько, щоб зробити підставу згадати)
Дві речі, засновані на витрачанні більшості останніх 22 років на підтримку коду, написаного іншими людьми.
Зрозумійте види помилок, які ви схильні писати.
Наприклад, я дуже прискіпливий кодер, тому щойно мій код складається, він зазвичай не містить тривіальних помилок. Тож мої помилки, як правило, дивні складні речі, такі як тупикові потоки. З іншого боку, у мене є друг, який здебільшого пише тривіальні помилки - крапки з комою в кінці C ++ для циклів, тому наступний рядок виконується лише один раз, таку річ.
Не припускайте, що інші люди пишуть такі самі помилки, як і ви.
Я не знаю, скільки разів я витрачав час, витягуючи великі налагоджувальні пістолети, припускаючи, що помилка була моєю справді тонкою дивною річчю, тільки щоб мій друг подивився через моє плече і пішов: "Ви помітили, що зайве крапка з комою? " Після багатьох років я спочатку переходжу до тривіальних низькорослих фруктів, коли дивлюся на код інших народів.
Знайте свої інструменти. Наприклад, налагоджувач Visual Studio має дивовижну функцію під назвою TracePoints, яка схожа на точки прориву , але замість того, щоб зупиняти код, замість цього вставляє оператор сліду у вихід налагодження.
Настійно рекомендується читати книги чи проводити заняття щодо використання налагоджувача. Я взяв пару занять і прочитав кілька книг Джона Роббінса, які великою мірою змінилися в моїй ефективності як налагоджувача.
Напишіть автоматизований блок-тест та інші типи інтеграційних та функціональних тестів.
Чим більше автоматизованих тестів, тим менше часу потрібно витратити на відладчик.
Також хороший дизайн - принципи SOLID. Якщо ви пишете невеликі, зосереджені класи та віддаєте перевагу композиції над успадкуванням, виключаючи дублювання тощо, ваш код завжди буде простішим налагодження.
Я вважаю, що добре розроблений код створює інший набір помилок, той код, який недостатньо розроблений. Взагалі, добре розроблений код створює помилки, які легше знайти, відтворити та виправити.
Виняток (і завжди є такий) - багатопотоковий код :-)
Якщо ви звузили його до невеликого регіону, але все ще не можете помітити помилку, спробуйте параметр "переглянути код + збірка" свого налагоджувача. Знаючи достатньо ASM, щоб сказати, "тут має бути гілка" або "чому це лише копіювання низького слова?" часто визначає помилку кодування.
Ознайомтеся з дуже цінною книгою « Чому програми провалюються: посібник із систематичної налагодження» Андреаса Зеллера. Він ознайомить вас із багатьма методиками, теоріями та інструментами, деякі з яких є передовими напрямками досліджень.
Слайди для книги доступні в Інтернеті, але я вважаю, що саму книгу читати простіше.
Книга допоможе розпочати роботу і змусить задуматися про налагодження, але це не замінить практику. Можливо, вам доведеться писати та налагоджувати протягом 10 років, перш ніж ви побачите на порядок покращення своєї продуктивності. Я все ще пам’ятаю, як у мене падіння щелепи в Sun бачило старших розробників, які програмують Unix протягом 30 років, за лічені хвилини знаходять незрозумілі багатопотокові або паралельні помилки. Досвід має значення!