Часто возникает неприятная ситуация: некий сценер начинает писать код и в определенный момент впадает в панику от того, что код ведет себя не так, как ожидается. Код не из простых, слёту указать на проблему невозможно, а ничего внятного, кроме «нихера не работает!!1» кодер сказать не может. Помочь в этой ситуации удручающе сложно. Все смотрят с сожалением, испытывая тяжкие угрызения совести. Наконец самый ответственный профессионал просит сорец, понимая, что сейчас ему придется разгрести тонну интуитивно понятного, хорошо прокомментированного кода на асме. (В этот момент очень хочется, чтоб кто-нибудь написал плагин для редактора, который будет подсвечивать все баги в сорце красным цветом.)

Как же кодеру не докатиться до жизни такой? Просто. Использовать принцип: проще не дать баге появиться, чем потом ее разыскивать.

Для этого надо писать код отдельными модулями, каждый из которых имеет ограниченный законченный функционал. Этот модуль проверять на работоспособность и совместимость с общим дизайном. И только после того, как убедился, что функционал исправен, и по ресурсам не конфликтует — включать модуль в общий сорец или наращивать его функционал.

Приведу два примера того, как надо и как не надо делать.

Пример 1. Пишем фреймовый эффект, использующий стек. Приход прерывания во время работы этого эффекта фатален, потому что что-нибудь испортит (например таблицы, которые читаются стеком). Поэтому эффект должен уложиться в такты фрейма. Прерывания включены, на прерываниях висит плеер.

Неправильно:
1. Проверяем плеер (без эффекта) — играет.
2. Делаем эффект (без плеера) — работает.
3. Добавляем одно к другому — падает на третьей секунде.
4. Впадаем в ярость/депрессию.

Правильно:
1. Делаем замерялку тактов с фиксацией максимального значения.
2. Запускаем плеер, проигрываем весь музон, смотрим, что там намерялось.
3. Делаем аналогичное измерение эффекту без плеера. Если эффект использует поведение, основанное на генераторе случайных чисел, пишем тест, который гоняет его долго с разнообразными значениями стартового сида (благо эмулятор умеет «намлок», а РС у нас быстрый).
4. Складываем пики потребления тактов для обоих случаев и видим, что их сумма больше, чем тактов во фрейме. Неважно, насколько больше — важно, что эффект грохнется с гарантией и возвратом денег.
5. Фиксим. Повторяем итерацию.

Пример 2. Есть пресловутая ТС-Конфа, которая традиционно плохо задокументирована и содержит новые неожиданные концепции. Кодер хочет вывести спрайтовую синусную бегучку.

Неправильно:
1. Наскоряк спрашиваем как там чо программится в этих ваших спрайтах.
2. Пишем рассчет синуса. Прикручиваем спрайты к синусу.
3. На экране нифига/мусор/глюки.
4. Идем за пигом.

Правильно:
1. Пишем тест для вывода одного спрайта.
2. Усложняем его функционалом изменения координаты по всему диапазону. Добиваемся, чтоб спрайт двигался.
3. Пишем тест для изменения палитры, добавляем второй спрайт и т.д.
4. Прикручиваем синус.
5. Если все-таки не работает, пишем значения спрайтовых дескрипторов в отладочный массив и вдумчиво анализируем то, что записалось, сравнивая с тем, что ожидалось.

Надеюсь, мессадж прошел. Удачного системного программрования.

P.S.
Все события и персонажи данного литературного произведения выдуманы. Любые совпадения с реально живущими или умершими для сцены лицами случайны.