Философия «Error-Aware Design»

Чайник, который наказывает

У чайника мазохиста носик и ручка находятся с одной стороны:

Обязательно обожжётесь потому что с таким чайником ошибки становятся неизбежными.

Вот как выглядит эквивалент такого чайника в коде:

function formatName(user) {
  // Что если user undefined?
  // Что если firstName null?
  // Что если lastName пустая строка?
  return user.firstName + ' ' + user.lastName;
}

Он провоцирует ошибки. И как с чайником — проблема не в пользователе, а в дизайне.

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

Осознание ошибок ≠ Обработка ошибок

Обычно разработчики думают об ошибках так:

1. Пишут код
2. Добавляют обработку ошибок
3. Документируют крайние случаи

Дизайн с осознанием ошибок переворачивает этот процесс:

1. Исключаем предотвратимые ошибки
2. Делаем оставшиеся ошибки очевидными
3. Аккуратно обрабатываем то, что осталось

Цена плохого дизайна

Кажущийся безобидным API стоит нам:

1. Времени на отладку: “Почему это работало, а потом сломалось?”
2. Интеграционных проблем: “Но в документации сказано…”
3. Инцидентов в продакшене: “Мы не знали, что так может быть”

Основной принцип: Ошибки, которых никогда не было

Лучшая обработка ошибок — их полное предотвращение:

1. Сделайте опасные состояния непредставимыми. Как чайник, который физически не может обжечь.
2. Падайте быстро и громко. Как чайник, который кричит при переполнении.
3. Ведите пользователей API к успеху. Как чайник с чёткой линией наполнения.

// Это TypeScript вместо JavaScript
interface User {
  firstName: string;
  lastName: string;
}

function formatName(user: User): string {
  return `${user.firstName} ${user.lastName}`;
}

В следующей части: Инструментарий

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

Задание: Вспомни последний инцидент в продакшене. Можно ли было предотвратить его на уровне дизайна API?