Абстракциями тебе по голове
Стараться спроектировать систему максимально гибкой и универсальной — хорошее желание. Но мы имеем тенденцию увлекаться. Не все можно учесть и обобщить, да и нужно ли?
Архитектура — это действительно важно, но писать код ради кода бессмысленно. Он должен решать реальную проблему, а не ту, которая будет когда-нибудь потом.
Увлекаясь, мы городим все новые и новые слои абстракции, стараясь предусмотреть все возможные случаи использования. В итоге, сложность решения превышает разумные пределы.
Как измерить эти пределы?
Когда в системе слишком много сущностей и уровней абстракции, непросто докопаться до истины. Вместо того, чтобы сразу заняться делом, мы выстраиваем в голове все связи между этими сущностями. Закапываемся в интерфейсах, абстрактных классах, виртуальных функциях. И вот там, где то на дне, лежит код, который и делает всю работу.
Выстраивание модели системы в голове создает когнитивную нагрузку. Чем выше эта нагрузка, тем ниже наша эффективность. Именно поэтому “overengineering”, то есть переусложнение, считается плохой практикой.
Кстати, высокая когнитивная нагрузка — это одна из главных причин, по которой мы не хотим разбираться в чужом коде.
Что забавно, тенденеция к этому никак не зависит от опыта. Этим грешат как новички, создающие классы на каждый пук, так и опытные разработчики, усложняя систему другими “более умными” способами =). Что греха таить, я и сам себя ловлю на мысли, что слишком увлекся.
Ну и что же с этим делать?
Во-первых, если вы почувствовали, что зашли слишком далеко — остановитесь. Доведите систему до рабочего состояния, а затем взгляните на все свежим взглядом. Попробуйте выстроить все снова в голове, и прислушайтесь к себе. Легко ли вам это все понять? Попробуйте убрать все излишние части, усложняющие понимание. Сделал хорошо? Теперь сделай просто :)
Во-вторых, покажите код коллеге. Если система слишком сложна, он обязательно об этом вам скажет. Ну или просто завалит вас вопросами. Уже не в первый раз говорю о великой пользе код-ревью.
Имейте смелость признаться в ошибке и все исправить
Ну и напоследок, хотелось бы сказать, что независимо от того сколько времени вы потратили на ваше детище, если оно не работает как надо, или является слшком сложным, вы должны быть смелым и признать этот факт.
После признания и принятия этого факта сердцем, придут мысли о том как можно исправить ситуацию. Это же вас может привести к совершенно свежим решениям, новым открытиям и интересному опыту.
Я всегда руководствуюсь правилом, что идеальный тот код, которого нет. Удалять все лишнее, неипользуемое, неправильное — это как лечение больного от недугов. Если та “масштабируемость”, которая была заложена в систему, не понадобилась или не окупилась, то ее нужно вырезать.
Абстракции не только бьют по нашему сознанию, но и привносят накладные расходы: тратят память, ухудшают производительность и т.д.
Ну и в конце, хочу сказать, что программирование — это искусство поиска равновесия. Между красотой и производительностью, качеством и временем, функциональностью и простотой.
Если статья вам понравилась, не забудьте похлопать и подписаться :).
Еще больше статей и заметок вы можете найти на Telegram канале GameDev Architecture.
