От джуна до сеньора

Тезисы

■ Паттерны проектирования – благо и проклятие.

■ Не используйте паттерны проектирования для решения всех на свете проблем.

■ Подходите к выбору решения прагматично, хладнокровно и осознанно.

Задание

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

История из жизни

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

Переабстракции

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

Идентичность языка определяется, помимо прочего, его подходом к предоставлению свободы разработчику. Некоторые языки программирования дадут вам десяток способов по-разному совершить одно и то же действие (C++, как здорово, что ты зашел). От других вы дождетесь в лучшем случае двух (Go, заходи, присаживайся). Какой подход предпочтительнее, покажет опыт, но если вы уже работаете с проектом на конкретном языке программирования, то вам остается одно: следовать принятым соглашениям о способах использования возможностей языка. В худшем случае ваши коллеги никак не обсуждают этот вопрос и каждый из них пишет код так, как считает правильным (о, эта дивная кроличья нора!).

Однако у вас есть возможность помочь себе и коллегам: абстрагируйте код ровно до той степени, пока он не начнет делать то, что указано в требованиях к нему. Ваша работа – не соревнование «кто напишет самый абстрактный, гибкий (и неподдерживаемый) кусок кода на всем проекте». Этот код будут поддерживать ваши коллеги – пожалейте их, не всем нравится продираться через хрустальные замки интерфейсов и дюжины классов с множественным наследованием.

Если вы ожидаете, что ваш код будет часто и значительно меняться в ближайшем будущем, дайте себе чуть больше свободы в абстракциях, но не бросайтесь в омут с головой. В случае необходимости будет проще переписать этот код с нуля, чем тратить время и нервы на попытки понять, как же он должен работать. Во всех остальных случаях – keep it simple[2]! Если вы чувствуете непреодолимую жажду сотворить нечто невероятно сложное из всех конструкций языка, до которых сможете дотянуться, – создайте свой самый запутанный и понятный только вам pet project, он точно вас не разочарует.