Яка користь уникнути використання налагоджувача?

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

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

Чи можливо керувати комплексом без налагоджувача? Це доцільно? Які переваги можна отримати, використовуючи " психічну налагодження ?"

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

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

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

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

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

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

Вони можуть бути не поганими програмістами, але вони, мабуть, жахливо неефективні.

Я схильний дотримуватися порад від налагодження: 9 неодмінних правил пошуку навіть найбільш невловимих проблем із програмним та апаратним забезпеченням (Девід Аґанс), і ця річ прямо підпадає під керівництвом "Киньте думати і дивіться".

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

Я працював з розробниками, які відмовляються використовувати налагоджувачі, тому що вони знали краще. Класична відповідь, яку я отримав одного разу: "Збою не спричинено мною. Я весь день перевіряв код [там, де він зазнав аварії], і нічого поганого немає". (А як щодо того нульового значення, яке було прочитане з db?) Бос, здавалося, вважав це чудовою відповіддю, але клієнт цього не зробив.

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

Ваш найкращий посібник щодо налагодження - книга Кодексу Стіва Макконнеля . У розділі 23 докладно розглянуто налагодження, і я перекреслити кілька пунктів з нього.

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

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

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

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

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

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

1. Після написання фрагмента коду, щоб переконатися, що він працював і
2. Коли я отримав повідомлення про помилку, щоб спробувати діагностувати проблему

Що я виявив після 10 років тестового розвитку, це те, що я набагато продуктивніший як програміст, якщо:

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

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

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

Особисто я намагаюся мінімізувати використання налагоджувача шляхом:

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

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

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

Налагодження - це дуже корисний інструмент для перевірки стану об’єктів та змінних у вашому коді під час виконання.

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

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

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

На відміну від корисності налагоджувачів у вищезгаданих прикладах, мені здається, що важко і дещо не корисно використовувати, коли задіяно багатоструменеве (тобто одночасність, асинхронна обробка). Це може допомогти, але легко втратити свою орієнтацію в багатопотоковому тумані, коли точки відключення відбивача потрапляють в одну нитку в точці A і зовсім окрему нитку в точці B. Розробник змушений натиснути на нову точку розриву " Мисленнєвий процес "на вершині" стека "мозку і зорієнтується на код у точці нової точки розриву. Після зменшення релевантності точки розриву B потім розробник переходить на першу точку розриву і повинен згадати, на що він / вона шукав перед спусковим механізмом точки межі B. Я знаю, що це може бути заплутаним поясненням,

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

На закінчення, на мою чесну думку:

• Налагодження при використанні одночасності = підвищена тенденція до втрати уваги "налагоджувальної думки"

і

• у будь-який інший час = підвищення продуктивності налагодження з / п вашу увагу не переривають несподівані точки прориву (несподівані через перегони).

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

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

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

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

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

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

Ем, це залежить від людини. Особисто я настільки не використовую налагоджувачі. Коли я програмую мікроконтролери, я в основному використовую світлодіоди або записую дані в EEPROM, щоб "налагодити" код на ньому. Я не використовую JTAG.

Коли я програмую програмне забезпечення для ПК або серверів, я, як правило, використовую журнал і багато консольного виводу. Для мов стилю C я використовую директиви препроцесора, а в Java я використовую рівні журналів.

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

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

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

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

Багато відповідей, але не згадка про Heisenbug ?!?!

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

Я використовую налагоджувач, тільки в гіршому випадку (для важко знайдених помилок). Крім того, згідно з найкращими методами, про які говорили багато відомих розробників / тестерів, добре перевірити код ретельно. Таким чином, ви можете покрити більшість проблем, а значить, не буде потреби використовувати налагоджувач.

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

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

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

З хорошими тестами на одиниці та винятками, які надають вам зворотній шлях, вам рідко доводиться використовувати налагоджувач.

Останній раз, коли я використовував налагодження, коли я отримав основний файл у якомусь застарілому додатку.

Я є "служником-дебюгером" чи ці хлопці "занадто жорсткі"?

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

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

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

У динамічно набраних мовах без налагодження (навіть якщо це просто скидання значень на консоль) здогадка іноді стає неможливою.

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

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

Проблему в цій програмі (на С) було перезапис пам'яті. Відладчик з точкою розриву пам’яті виявив рядовий рядок коду, як тільки з’явилася помилка. Але в цьому випадку немає жодного способу, коли хтось міг би прочитати та зберегти всі 4,5 мільйона рядків коду, щоб визначити одне місце, яке хтось написав повз свій масив (плюс вони повинні були знати компонування пам’яті виконання для стану програми програми ggantuan приблизно 10 хвилин у тривалий проміжок введення, щоб дістати його до цієї точки).

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

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

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

Також врахуйте, що не кожен, хто має завдання налагодження коду, знайомий з цим кодом. Багато разів підрядники потрапляють у середовище, де вони мають лише загальний ідеал того, що відбувається. Вони можуть навіть дати докладний опис оточуючого середовища - або 20-річну схему схеми та посібник до умовних правил іменування (спробуйте зрозуміти різницю між таблицею X1234 та таблицею X4312 з полями F1, F2 та F3 [так, сміття подібне до цього існує], коли ви новачок), але багато разів цей опис неправильний; інакше, чому виникає помилка "таємниці".

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