Мартин Хайдеггер (Martin Heidegger) внимательно изучал пути познания человеком инструментов через опыт их применения. Программисты создают и используют инструменты, мы думаем об инструментах, создаем инструменты, модифицируем и переделываем их. Инструменты — это объекты нашего интереса. Но для их пользователей, как показывает Хайдеггер в своей книге «Being and Time»[25] (Harper Perennial), инструмент — невидимая сущность, постижение которой происходит только во время ее применения. Для пользователей инструменты становятся объектами интереса только тогда, когда они не работают. Об этой разнице стоит помнить, когда разговор идет об удобстве работы.

Элеонора Рош (Eleanor Rosch) опровергла модель категоризации Аристотеля, упорядочивающую наше понимание мира. Когда мы, программисты, спрашиваем пользователей, чего они хотят от системы, мы обычно стараемся получить определения, основывающиеся на предикатах. Нам это очень удобно. Термы в предикатах легко превращаются в атрибуты класса или колонки таблицы. Подобные категории являются точными, непересекающимися и логически верными. Но, к сожалению, как показывает Рош в «Natural Categories»[26] (Естественные категории) и более поздних своих работах, люди представляют себе мир иными способами. Представление людьми мира основано на примерах. Некоторые из таких примеров, так называемые прототипы, лучше других, и поэтому основанные на них категории размыты, пересекаются одна с другой, могут обладать насыщенной внутренней структурой. Пока мы не перестанем настаивать на ответах в духе системы категорий Аристотеля, мы не сможем задать пользователям правильные вопросы об их мире, и нам будет трудно добиться необходимого общего понимания.

Почаще изобретайте колесо

Джейсон П. Сэйдж

Пользуйтесь готовыми решениями — глупо снова изобретать колесо…

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

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

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

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

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

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

Не поддавайтесь очарованию шаблона Singleton

Сэм Сааристе

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

Если подумать, то весьма многое. Как ни соблазнительно применение синглтонов, они, как показывает опыт, приносят больше вреда, чем пользы. Они затрудняют тестирование и усложняют сопровождение. К сожалению, это понимание не столь распространено, как хотелось бы, и синглтоны сохраняют свое обаяние для множества программистов. Хотя есть основания задуматься, так ли они хороши:

• Ограничение на число экземпляров класса часто иллюзорно. Во многих случаях утверждение, что в будущем не понадобятся дополнительные экземпляры, ничем не подкреплено. Домыслы в основе архитектуры приложения обязательно приведут к неприятностям в будущем. Технические требования меняются. Хорошая архитектура это учитывает. Синглтоны — нет.

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

• Синглтоны неявно хранят состояние, что опять-таки препятствует модульному тестированию. Модульное тестирование предполагает, что тесты независимы друг от друга, благодаря чему их можно выполнять в любом порядке, а программу можно возвращать в известное состояние перед выполнением каждого модульного теста. Как только появляются синглтоны с изменяемым (mutable) состоянием, обеспечить такие условия может оказаться затруднительно. Кроме того, такое глобально доступное долгоживущее состояние затрудняет интерпретацию кода человеком, особенно в многопоточной среде.

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

Избавление от синглтонов может стать в окончательном итоге сложной задачей:

• Явное уничтожение объектов синглтонов не поддерживается. В отдельных контекстах это может оказаться проблемой, например в архитектуре с подключаемыми