A-tit indd

часть кода программы. Вы должны не только приложить 
усилия для изначально правильной организации кода, 
но и поддерживать ее по мере того, как вносите измене-
ния на протяжении всего цикла разработки.
Вы должны продумать, какие части программы следу-
ет отвязать друг от друга, и добавить уровень абстракции 
в нужных местах. Аналогичным образом, определите места, 
где собираетесь добавлять новую функциональность, и тем 
самым заранее упростите процесс внесения изменений.
Людям очень нравится эта идея. Они считают, что 
будущие разработчики (или просто их будущие «я») 
Второй этап — поддер-
жание кода в порядке —
заслуживает особого 
внимания. Я видел, как 
красиво начинают свою 
жизнь многие про-
граммы, а затем умирают 
от тысячи незначитель-
ных правок, «мелких ко-
стылей», которые про-
граммисты вносят снова 
и снова.
В садоводстве ведь 
тоже недостаточно про-
сто сажать новые расте-
ния. Необходимо также 
ухаживать за уже имею-
щимися.

---

Паттерны программирования игр
— Введение
23
откроют код и обнаружат там логичный, мощный и про-
сто жаждущий изменений код. Они представляют Еди-
ный Игровой Движок, который управляет всем.
Но именно здесь начинаются трудности. Всякий раз, 
когда вы добавляете уровень абстракции или место для 
возможного расширения функциональности, вы пред-
полагаете, что эта гибкость вам понадобится. По мере 
внесения изменений код становится сложнее, а значит, 
требует больше времени на разработку, отладку и под-
держку.
Усилия оправданны, если вы все предположили пра-
вильно и в итоге позже возвращаетесь к работе с этим 
кодом. Но предсказать будущее 
сложно
, и, если такая 
модульность не окажется полезной, она может даже на-
чать мешать. Потому что как минимум сделает код, с ко-
торым вам приходится работать, более громоздким.
Если переусердствовать с этой концепцией, можно 
получить код, чья архитектура полностью вышла из-под 
контроля. Всюду интерфейсы и абстракции. Система 
плагинов, абстрактные базовые классы, изобилие вир-
туальных методов и всевозможные точки расширения.
Когда вы захотите найти код, который выполняет 
определенную функцию, вам придется изрядно поко-
паться в нем. Конечно, если вам нужно внести измене-
ние, то скорее всего существует некий интерфейс, но… 
в общем, удачи вам в поисках. Теоретически уменьше-
ния связанности означают, что вам нужно разбирать-
ся в работе меньшего объема кода, прежде чем вносить 
правки, но сами слои абстракции сильно грузят ваш 
и без того исцарапанный ментальный диск.
Код, подобный такому, заставляет людей отказаться 
от проектирования архитектуры программного обеспе-
чения и, в частности, паттернов проектирования. Очень 
легко закопаться в самом коде и упустить из виду тот 
факт, что вы разрабатываете 
игру
. Это как песня сирены 
о расширяемости, в результате чего многие разработчи-
ки проводят годы, работая над «движком», забывая, 
для 
чего
он нужен.
Коллеги придумали 
принцип YAGNI 
*
. Это
мантра, которую стоит 
повторять во время раз-
мышлений о том, что мо-
жет понадобиться в бу-
дущем.
*
«You aren’t gonna need 
it» (Вам это не понадо-
бится). — 
Прим. ред.

---