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