Як ефективно програмувати, коли потрібно просто перевірити свій код?


16

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

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


Використовуєте IDE?
Woot4Moo

3
Ваша коренева проблема не в змозі ефективно кодувати, її тести потребують занадто довго. Ви ставите неправильне запитання.
Рейн Генріхс

Використовуйте мову, що має REPL.
Роберт Харві

Чи є у вас колеги, від яких можна попросити і навчитися?
користувач985366

Відповіді:


25

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

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

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

Крім того, самі об'єкти макету можна запрограмувати за допомогою тверджень, тож ви можете перевірити, чи перевірений компонент справді робив певний дзвінок.


12

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

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

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


2
+1. Немає жодної проблеми, яку неможливо вирішити достатньою кількістю сценарію оболонки.
Том Андерсон

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

@Tom За винятком занадто багато шарів abst - er, скриптів оболонки;)
Дарієн

Ні, ви просто пишете скрипт оболонки, який обгортає інший сценарій оболонки. Тоді є лише один сценарій оболонки. ДОВІРСЯ МЕНІ.
Том Андерсон

3
+1: Підвищення швидкості редагування -> компілювання -> завантаження -> запуск -> налагодження -> редагування - найкраща річ, яку ви можете зробити для швидкого створення коду. Коли я працював у Tymshare, у нас був хлопець, який стверджував (правильно), що його код працював правильно при першій спробі 87% часу. Я, з іншого боку, кодував, як мені передозували кофеїнову мавпу о 1 ранку (якою я був). Я зробив безліч помилок друку тощо, але я не хвилювався за них, бо знав, що компілятор їх вловить. Наприкінці дня я був, мабуть, від 3 до 5 разів більш продуктивним, ніж він.
Пітер Роуелл,

8

Автоматизовані тести не є заміною для огляду та розуміння.

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


5

Ви вже дали відповідь: I usually make a lot of syntax errors and logic errors

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

У мене те саме було, коли я перейшов з PHP на Java. Мені довелося навчитися налагоджувати, а не просто друкувати деякі змінні та натискати F5 у браузері ...


2
Всі ми час від часу робимо дурні помилки, вони лише менше трапляються з часом і досвідом.
maple_shaft

@maple_shaft це правда, але коли він каже, що make a lot ofце звучить так, ніби він повинен вкласти свою енергію для вдосконалення
WarrenFaith

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

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

@Anne Nonimus: Ви маєте на увазі логічні помилки? Помилки синтаксису повинні бути зібрані вашою IDE (в ідеалі - якщо ви працюєте з кодом, який динамічно генерується, ці синтаксичні помилки не збираються під час компіляції).
FrustratedWithFormsDesigner

4

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

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


2

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


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

@maple Ну, я більше цього не роблю. Але унікальний? Ні - кожен може написати кокетливий код, і більшість торгових кодів є глибоко, глибоко хитрими. Однак, подобається це чи ні, це основа для нашого суспільства.
Ніл Баттерворт

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

2

Тестування одиниць; Знущаються над програмами / тренажерами.

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

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

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

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


1

Я зазвичай роблю багато синтаксичних помилок та логічних помилок

Можливо, використання Linter може трохи допомогти вам тут.

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

Пізніше я з'ясував, що також можлива віддалена налагодження dev-сервера.

Отже, ось що я зробив для оптимізації свого процесу

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

  • Планування того, як і які зміни я внесу.

  • Внесення змін і порівняння різниць

  • Кешування помилок за допомогою підводки або шляхом складання.

  • Надання гарячого виправлення шляхом заміни .classфайлів та перезапуску.

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

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

Сподіваюсь, це допомагає.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.