Меньше ветвлений!

Одно из правил Таранцова гласит: в программе не должно быть большого редко исполняющегося куска кода.

Пример. Вы пишете библиотеку, которая отправляет данные об исключениях на сервер. Чаще всего, как только исключение возникло, можно сразу обратиться к серверу, передать ему нужные данные и забыть о них. Иногда, тем не менее, Интернет или сервер оказывается недоступен.

Тут есть две альтернативы. Вариант А: попытаться отправить исключение, если не удалось, записать его в файл, минут через десять считать и попробовать заново. Вариант Б: записать исключение в файл, попробовать его отправить через пару секунд; если не удалось, повторить снова еще позже.

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

1. Увеличиваются затраты на автоматизированные тесты и на QA.

2. Рано или поздно вкрадется бага, не отловленная тестами и не пойманная вашим QA-процессом. (Например, всё рушится только под Windows Vista x64, установленной на FAT32-раздел.)

3. Продукт с этой багой вы можете поставить заказчикам и не узнаете о ней, пока заказчик с ноутбуком под Windows Vista x64 на FAT32 не запустит ваш продукт вдали от Интернета.

Сравним с вариантом Б. Исключение всегда сначала записывается, потом устанавливается таймер, он срабатывает, исключение считывается и отправляется. Нормальную (частую) и ненормальную (редкую) ситуации обрабатывает один и тот же код; если он не работает, пользователи закричат об этом сразу же.

Иногда такая «унификация» кода подсказывает дополнительные возможности. Скажем, если программа начнет генерировать тысячи исключений в секунду, отложенная на пару секунд отправка поможет реже обращаться к серверу.

Из нашего правила следуют два важных практических соображения.

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

Второе. Когда вы пишете обработку ошибок или каких-то других особых ситуаций, всегда пытайтесь превратить эти особые ситуации в нечто, что исполняется каждый день. Вместо операций «начать» и «продолжить» делайте операцию «начатьИлиПродолжить», вместо событий «завершилось» и «прервано из-за ошибки» делайте событие «остановилось» и т. д.