A-tit indd

Паттерны программирования игр
— Введение
19
говорить о том, 
как
организовать код. Как мы можем от-
личить хорошую архитектуру от плохой?
Я обдумывал ответ на этот вопрос около пяти лет. 
Конечно, и вы, и я можем интуитивно почувствовать 
хорошо спроектированную программу. Нам всем при-
ходилось иметь дело с настолько плохим кодом, что 
лучшее, что можно было для него сделать, это выбро-
сить его и избавить всех от мучений.
Хотя кому-то повезло чуть больше, им посчастливи-
лось работать с хорошо спроектированным кодом. Та-
ким кодом, с которым каждый чувствует себя словно 
в прекрасно оборудованном роскошном отеле, с кон-
сьержами, готовыми выполнить любую прихоть. Так 
в чем же разница?
Что такое 
хорошая
 архитектура программы?
Для меня хороший дизайн означает следующее: когда 
я вношу изменения, я должен почувствовать, будто про-
грамма с момента своего создания словно ожидала это-
го изменения. Значит, я могу решить задачу с помощью 
внесения всего лишь нескольких функций, которые от-
лично вписываются в старый код.
Звучит довольно красиво, но не всегда удается сде-
лать все именно так. «Просто вставьте новый код так, 
чтобы изменения не создали проблем в уже работающем 
коде». Ага (сарказм).
Позвольте мне слегка разрушить эту идиллию. Пер-
вая и основная мысль такова: 
архитектура связана 
с изменением
. Кто-то должен модифицировать код. Если 
никто не прикасается к коду — не важно, из-за его со-
вершенства и полноты или, наоборот, его отвратитель-
ности до такой степени, что никто не захочет марать им 
свой текстовый редактор, — его архитектура не имеет 
значения. Мера хорошо спроектированного кода — то, 
насколько легко в него вносить изменения. Код без из-
менений — это бегун, который никогда не покидает ли-
нию старта.
Признаемся, большин-
ство из нас хоть раз 
в жизни писали такой 
плохой код.

---