Як часто ви запускаєте і тестуєте код під час програмування? [зачинено]

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

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

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

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

Це дійсно залежить від аспекту проекту, над яким ви працюєте.

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

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

• Для UX-дизайну я використовую якийсь візуальний дизайнер, який завжди виглядає так, як він буде працювати (або близько до нього). Він по суті завжди складається з дизайнерського коду.

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

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

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

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

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

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

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

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

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

Я складаю і тестую, чи виконується одна з наступних умов:

• Останнє складання було 15 хвилин тому
• Остання компіляція була 25 рядків тому
• Нова функція / підпрограма реалізована
• Основні зміни
• Нова функція (або помилка, замаскована під функцію)
• Виправлення помилки (видалено "функцію")
• Мені нудно

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

З іншого боку, якщо я кодую в Lisp, я спробую кожну функцію після введення її.

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

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

Тричі на годину, потрібна вона чи ні.

Ми робимо тестування першого програмування і робимо тільки робочий код на VCS. Колірник відправляється і перевіряє репо кожних 20 хвилин і запускає тестовий набір. Будь-які збої негайно надсилаються всій команді програмування для негайного виправлення.

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

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

Для мене; -
Коротка хронологія (не так багато часу на роздуми) - написати код, скласти, перевірити. налагодження
Достатній час - поки (зроблено) {написати невеликий код, компілювати}, тест, налагодження

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

Я намагаюся писати тести перед кодом. Я запускаю свої тести щонайменше двічі перед фіксацією. Потім він знову запускається з сервером Continous Integration.