97 этюдов для программистов. Опыт ведущих экспертов

Ошибка программирования может породить неразрешимую техническую проблему. Например, если пытаться получить 83-й элемент массива размером 17 элементов, программа сойдет с рельс и сгенерирует исключение. Более тонкий вариант — вызов кода библиотеки с недопустимыми аргументами, приводящий к тому же результату, но внутри библиотеки.

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

Вариант этой ситуации встречается при обращении к вашей библиотеке, когда вызывающий нарушил контракт метода, например, передав совершенно неприемлемый аргумент или не настроив должным образом связанный объект. Это ситуация того же типа, что с обращением к 83-му элементу из 17: вызывающий должен был проверить, и это ошибка программиста на стороне клиентского кода. Правильная реакция — генерировать техническое исключение.

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

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

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

Больше осознанной практики Джон Джаггер

Осознанная практика — это не просто выполнение задания. Если на вопрос «Зачем я выполняю задание?» вы отвечаете: «Чтобы выполнить это задание», это не осознанная практика.

Осознанная практика нужна для того, чтобы улучшить ваши способности к выполнению задачи. Цель — повышение мастерства и техники. Осознанная практика — это повторение. Осознанная практика — это решение задачи с целью повышения мастерства в одном или нескольких аспектах задачи. Осознанная практика — это повторы повторений. Вы продвигаетесь медленно, выполняя задачу снова и снова, пока не достигнете желаемого уровня мастерства. Осознанная практика выполняется, чтобы овладеть способами решения задания, а не для того, чтобы его выполнить.

Главная цель коммерческой разработки — конечный продукт, а главная цель осознанной практики — повышение эффективности труда. Это разные вещи. Прикиньте, сколько времени вы тратите на работу над чужим проектом? А сколько времени на работу над собой?

Сколько осознанной тренировки необходимо для приобретения мастерства?

• Питер Норвиг (Peter Norvig) пишет,[9] что «возможно, 10000 часов… — это и есть то самое магическое число».

• В книге «Leading Lean Software Development: Results Are not the Point» (Addison-Wesley Professional, 2009) Мэри Поппендик (Mary Poppendieck) пишет, что «разработчикам, достигшим высшего уровня производительности, требуется не менее 10000 часов целенаправленной тренировки, чтобы стать экспертами».

Мастерство растет постепенно, а не возникает скачком после 10-тысячного часа! Однако 10000 часов — это серьезно: примерно 20 часов в неделю в течение 10 лет. Требуется такое упорство, что вы можете усомниться, получится ли из вас эксперт.