Справжні програмісти використовують налагоджувачі? [зачинено]

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

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

Я часто використовую налагоджувач, тому що я працюю у великій системі, і тому я смоктаю. http://steve-yegge.blogspot.com/2007/06/rich-programmer-food.html

Незалежно від того, наскільки короткий і часто читається ваш код, завжди існує ймовірність, що у ньому будуть помилки. http://googleresearch.blogspot.com/2006/06/extra-extra-read-all-about-it-nearly.html

Помилятися - це людина, і ніколи не можна довести, що програма правильна, то чому б не використати такі інструменти, як налагодження / автоматичне тестування, щоб допомогти собі у цій непростій справі?

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

Отже, коли мені не потрібен налагоджувач?

Я не найрозумніший кодер, ні найдосвідченіший, але все ж, іноді мені не потрібно використовувати налагоджувач. Саме тоді:

• Код мій або добре написаний І
• Він написаний читаною мовою І
• Загальний проект невеликий.

Коли я сильно покладаюся на налагоджувача?

• Коротка відповідь: часто .
• Коли програма виходить з ладу. Особливо при його розгортанні. Встановлення VS2010 на цьому комп’ютері може змінити значення "Невідома помилка" та FileNotFoundException.
• Коли бібліотека сторонніх збоїв або погано поводиться.
• Коли код погано записаний. Особливо, якщо за той самий файл за останні 10 років торкнулися 10 різних людей, 7 з яких більше не є компанією.
• Коли проект великий
• Коли код досить монолітний.
• Коли задіяно кілька ярусів (GUI, SQL, BL).

Зауважте, що "налагоджувач" може стосуватися декількох інструментів. Я також використовую налагоджувач Visual Studio, налагоджувач SQL (в основному для збережених програм) і SQL-профайлер (щоб з'ясувати, які SP викликаються). Чи потрібні мені інструменти цього калібру, я писав швидкий сценарій Python-sysadmin-ish? Ні. Якщо я створив власний маленький інструмент на основі GUI? Залежить. Якщо це .Net WinForms - мабуть, ні. Якщо це WPF - так.

Що все-таки визначає "справжнього" програміста? Той, що швидко? обізнаний? Чи добре в алгоритмах? Пише гарну документацію? Тільки коли саме хтось закінчує цей новий титул? Коли перетинає магічну лінію?

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

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

...

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

"Я не люблю налагоджувачів. Ніколи не буду, мабуть, ніколи не буду". - Лінус Торвальдс

З іншого боку, у нього немає облікового запису Stack Overflow, тому я не впевнений, чи цікавитесь ви його думкою :)

Тож моє конкретне відповідне питання - за яких обставин ви, як досвідчений програміст, використовуєте відладчик?

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

Редагувати:

У мене було щастя / нещастя, що я не знав, як використовувати налагоджувач у моїй програмі. Таким чином, раніше я був змушений налагоджувати без налагоджувача. Однак, навчившись використовувати відладчик -> Я став на 100 разів більш продуктивним у пошуку помилок.

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

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

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

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

Ви вважаєте, що Скіти світу не помиляються або просто все знають? Усі, крім самих тривіальних програм, поводяться несподівано за певних обставин. Саме з огляду на те, що проблеми доведеться досліджувати. Тож для вибору використовуються оператори друку на одному кінці спектра, або дивіться, що сталося, post mortem, з іншого, або дивіться прямо посередині, як виконується код, і з'ясовуйте, що відбувається.

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

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

Рідко.

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

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

У Smalltalk я майже повністю розвиваюся в налагоджувачі:

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

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

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

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

Треба визнати, що я все менше використовую налагоджувачі. Я розвиваюся в Дельфі вже більше 10 років. Я також записую збережені процедури в PL / SQL. З двох місяців я теж PHP-розробник.

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

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

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

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

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

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

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

У мене є обоє - мені потрібна вся допомога, яку я можу отримати!

Я використовую налагоджувач лише тоді, коли ці кроки не виконані:

1. Отримати відтворювану помилку Подумайте. Це часто все, що потрібно.
2. Перевірте будь-який слід та журнал стека.
3. Додайте більше журналу навколо коду, який порушує порушення.

Ці кроки стосуються 95% усіх випадків. Це означає, що я рідко використовую налагоджувач, і коли це роблю, він, як правило, дає мені занадто багато інформації і я забиваюсь у незв'язані деталі. Особливо це стосується роботи над багатопотоковою системою в режимі реального часу.

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

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

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

Це питання особистого вибору.

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

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

Крім цих 2 функцій, я не думаю, що налагоджувач дійсно не потрібен; будь-яка складна програма, яку ви робите, повинна мати якийсь режим "багатослівної роботи", тобто розповідати все, що вона робить з printf або std :: cout, який вибір вона зробила, і безліч інших параметрів.

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

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

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

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