Як витратити менше часу на налагодження? [зачинено]

Дотримуючись правила Парето, програміст витрачає лише 20% свого часу на дійсно корисні речі.

Я витрачаю 80% свого часу на налагодження, виправляючи дрібниці, щоб все працювало.

Чи є спосіб витратити менше часу на налагодження?

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

Але все-таки в більшості випадків ви будете набагато продуктивніше витрачати 20% свого часу на кодування та 80% на тестування та налагодження. 100% на тиждень - це набагато більше 20% години. Якщо налагодження - це те, що вам потрібно зробити, то налагодження - це не марна трата часу, і ви не повинні перейматися «покращенням» цієї пропорції.

Блок тестування.

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

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

• Тестування блоку, щоб ви дізналися, чи працює ваш код в першу чергу.
• Принаймні деяку кількість попереднього дизайну, щоб ви знали, що кодуєте.
• Код оглядів, тому що дві голови краще однієї, а чотири ока - краще, ніж дві. Не кажучи вже про те, що навіть спроба пояснити свій код комусь іншому виявляє багато проблем.
• Керування версіями, щоб ви могли швидко виділити, які зміни, можливо, спричинили помилку.
• Рефакторинг, щоб код не перетворився на жахливий незрозумілий безлад.
• Прочитайте «Чистий код» Роберта К. Мартіна і робіть те, що він вам каже. Ви будете вражені результатами.

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

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

1. використовуйте незмінні типи, де це можливо - якщо щось має неправильне значення, ви точно знатимете, де слід шукати негайно (де це будується).
2. примусово виконувати інваріанти в коді - якщо ви знаєте, що значення точно не дозволено, тоді перевірте його та киньте виняток у пунктах введення методам та конструкторам. Якщо поєднувати це з непорушними типами, то ви також можете почати робити певні припущення щодо того, що є дійсним чи ні.
3. переконайтеся, що у вас є адекватний журнал - розпочніть це на початку, і він дасть вам багато важливої ​​інформації про те, коли все піде не так. Тут дуже добре працює AOP. Ведення журналу як заздалегідь, як правило, трохи сміття - отримайте його на початку, як частина налаштування проекту.
4. якщо база вашого коду досить велика / складна, уникайте використання примітивів - наприклад, майте тип під назвою "Age", а не просто використання int. Спочатку це здасться трохи безглуздим, але можливість вистежувати всі потреби чогось за мить - це величезна виграш налагодження.

Мої 80% - це налагодження. Я виправляю прості помилки і намагаюся зробити так, щоб все працювало.

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

Зрештою, ви, швидше за все, витратите 80% на налагодження складних помилок.

Як витратити менше часу на налагодження? Напишіть менше коду.

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

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

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

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

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

  • Використання гілок допоможе вам відокремити області розвитку, і ви зможете побачити, у якій області розвитку є помилка, а в якій ні.
  • Дізнайтеся, як використовувати бісекцію у своєму VCS, Git має це вбудований. Якщо ви використовуєте інший VCS, який не має вбудованої бісекції, шукайте інструмент, який працює як git bisect, але для вашого VCS (я знаю, що це існує для SVN та не має бути занадто важким для створення для інших ДКС). Це допоможе вам звузити зміну коду, яка ввела помилку, що допоможе дізнатися, куди вказати ваш налагоджувач. Цей процес розбиття буде більш швидким, якщо у вас є тести на помилку, і знаючи, яка фіксація містить правопорушну зміну, буде корисніше, якщо ви практикуєте атомні коміти.

• Удосконалити розуміння мови програмування, якою ви користуєтесь.

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

• Будьте логічними

  • Не змінюйте відразу більше ніж одне, інакше, якщо поведінка зміниться, ви не знатимете, яка зміна викликала зміну поведінки.
  • Перевірте свої припущення.

Додавання до коментарів для Unit Testing, але це справді добре, лише якщо ваш код відокремлений для його підтримки (наприклад, MVC). Якщо ви не можете реалізувати MVC (або подібний) (застарілий проект), одиничні тести взагалі не працюють для вашого інтерфейсу. Тоді я б додав автоматичне тестування інтерфейсу користувача (Microsoft Coded UI Tests, WaitN), оскільки це зменшить помилки в тій частині вашого коду.

Я також дуже рекомендую запускати інструменти статичного аналізу (наприклад, FxCop / Microsoft Code Analysis, Resharper, JustCode для світу MS). Вони можуть знайти всілякі поширені проблеми кодування, які можуть зменшити нерозумні завдання налагодження та зосередити увагу на налагодженні бізнес-логіки.

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

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

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

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

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

- Використовуйте абстракцію, де це доречно. Короткочасна пам'ять слабка.

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

-Унікові тести. Вони насправді не запобігають помилкам настільки, що дають зрозуміти, де є помилки, та забезпечують розумність.

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

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

Хоча я повністю підтримую тестування модулів, запропоновані вище, TDD або BDD будуть мати велике значення, оскільки вам потрібно спочатку подумати про проблему та рішення.

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

Іноді швидка писанка на аркуші паперу допомагає побачити більші з'єднані частини головоломки.

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

PS. Я маю на увазі 5, може, десять хвилин, а не години написання величезної специфікації.

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

Вчитися на своїх помилках. Не продовжуйте робити одні і ті ж знову і знову.

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

Зверніть увагу на вимогу. Навіть якщо він працює, але не виконує вказану вимогу, це помилка.

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

Мої дві головні думки: 1) Напишіть кращий код, який вийде з ладу, коли ви зробите щось несподіване 2) Станьте кращим у налагодженні

Мій код завалений

if(value!=null) throw new NotImplementedException();
if(obj.v>0) throw new Exception(); //sometimes i dont write NotImplementedException
if(value=="thing") throw ...;

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

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