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

Разработчики API решают эту проблему разными способами, хотя проще всего заблокировать свой API. Скажем, в Java весьма соблазнительной может стать идея навешивать на большинство классов и методов модификатор final. В C#, в свою очередь, классы и методы можно объявить как sealed. В любом языке можно попробовать представить API с помощью синглтона или воспользоваться фабрикой статических методов для защиты от тех, кто попытается переопределить поведение и использовать ваш код способами, которые ограничат ваши возможности в будущем. Все это кажется разумным, но так ли это в действительности?

За последние 10 лет мы постепенно пришли к пониманию того, что модульное тестирование — крайне важный элемент практики, но этот урок еще не везде усвоен в нашей отрасли. Свидетельств тому предостаточно, и они вокруг нас. Возьмите произвольный непротестированный класс, использующий API стороннего разработчика, и попробуйте написать для него модульные тесты. Скорее всего, у вас возникнут проблемы. Выяснится, что код, использующий API, приклеен к нему намертво. Невозможно эмулировать классы API так, чтобы можно было понять, как взаимодействует с ними ваш код, или обеспечить возврат значений для тестирования.

Положение со временем улучшится, но только если при проектировании API мы станем рассматривать тестирование как реальный сценарий использования. К сожалению, это несколько сложнее, чем просто тестировать наш код. Здесь уместно вспомнить золотое правило проектирования API: недостаточно написать тесты для разрабатываемого API; вы должны написать модульные тесты для кода, использующего ваш API. Следуя этому правилу, вы на собственном опыте узнаете, какие трудности ожидают ваших пользователей, когда они попытаются протестировать свой код самостоятельно.

Нет какого-то единого решения, облегчающего разработчикам тестирование кода на основе вашего API. Ключевые слова static, final и sealed по сути своей не являются плохими конструкциями. Иногда они бывают полезны. Но важно помнить о проблеме тестирования, а для этого вы должны испытать ее на себе. Как только это сделано, ее можно решать так же, как любую другую проблему проектирования.

Миф о гуру Райан Браш

Каждому, кто достаточно давно работает в компьютерной отрасли, приходилось слышать вопросы типа:

У меня генерируется исключение XYZ. Не знаете ли, в чем проблема?

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

Мы ожидаем подобных вопросов от людей, не знакомых с программным обеспечением, от тех, кому работа системы кажется практически волшебством. Меня беспокоит, что с этим мы сталкиваемся и в сообществе программистов. Аналогичные вопросы возникают при проектировании программ, например: «Я пишу приложение для управления складом. Следует ли мне использовать оптимистическую блокировку?». Ирония состоит в том, что, как правило, спрашивающий лучше подготовлен к тому, чтобы ответить на вопрос, чем тот, кому он задан. Вопрошающий, вероятнее всего, знает контекст, знает требования и способен прочесть материалы о преимуществах и недостатках тех или иных стратегий. И при этом от вас ждут разумного ответа безо всякого контекста. Они ждут чуда.

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

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