Эволюция игрового фреймворка. Введение 1. Постановка проблемы

Скорость разработки и качество кода — вот, пожалуй, одно из главнейших противоречий IT-индустрии. Можно долго продумывать архитектуру приложения, потом ее совершенствовать, улучшать, а в итоге так ничего и не сделать. А можно быстро что-то сварганить, а потом и зарелизить, но из-за ошибок проектирования завести весь проект в тупик. На каждые два часа разработки, шесть часов будет уходить на поиск и исправление багов, в результате чего вся последующая разработка фактически застопорится.Таким образом, вопрос: качество или скорость переходит в проблему: хороший, но вечно незаконченный проект или хоть как-то, но работающая программа. Любой менеджер как реалист, естественно, выберет второе.Так и получается, что куда ни ткнись, у всех код если не дрянной, то по меньшей мере неважный. То, что называется многозначительным словом legacy. Все всё понимают, плюются, но поделать ничего не могут. Код уже есть и с ним нужно работать. Все предложения по улучшению не приветствуются, а то и прямо запрещаются. Как тут быть, что поделать? Попробуем разобраться.