D>А как добавить репликации в уже существующий код без костылей вы знаете?
Разрабатывать с нуля ничего не надо. Надо просто брать компоненты, которые делают что-то одно, но делают это хорошо. И делать так, что бы эти компоненты было легко переписать или заменить в случае чего.
Затем, надо выделять вещи очень важные и критичные — такие как работа с базой и коннекциями, которые влияют на вообще все, и сессии, которые при их наличии влияют масштабирование (есть сессии — нет масштабирования, гы-гы. шучу.)
Есть вещи менее важные — шаблонный движок, например, или middleware (хотя конкретно флуп тоже таит много открытий чудных)
Есть совсем маловажные — например, компонент, который отвечает за валидацию значений форм и возврат ошибочных значений ( хотя этого добра в питоне совсем немного, и нам пришлось написать свой, т.к. HtmlForms или как там его дюже мерзок)
Каждый компонент рассматривается отдельно, тестируется, оборачивается таким образом, что бы от него избавиться, не переделывая всей системы в целом.
Можно взять все оптом в виде джанги. Ну и получить то, что получили.
И не надо говорить, что можно или взять что-то от джанги, или там поменять в джанге ORM на что нибудь другое.
Никто этого в реальной жизни не делает, а как только начинает — то теряет то самое "гипер-короткое" время разработки напрочь совсем.
D>И сколько ресурсов потребовалось бы на разработку всей системы с нуля?
Ну это примерно известно. Был случай переписывания одной системы с web.py на TurboGears и с TG на набор компонентов с собственным glue. В общем-то очень немного по сравнению со временем написания системы, благодаря наличию выделенного слоя бизнес-логики, этот самый слой почти не пострадал. Хуже пришлось при выкидывании ORM, потому что он пускает свои метастазы между слоями...
Если бы писали сразу с нуля, то было бы вообще отлично. С нуля ведь это очень условно. Фактически, с нуля написан только валидатор форм и сериализаторы в xml и json, потому что те, которые есть не нравятся. Остальное все стандартное. Только обернутое. На всякий случай.
dmz>>Итого — гимора много. С какого то момента мы не получаем бонусы от фреймворка, а боремся с ним. Касается и джанги, и ORMа.
D>Бонус от фреймворка уже получен — время разработки гипер короткое.
Полгода, ага. И потом еще какое-то время, что бы работало. Собственно, данная история показывает именно этот сценарий, да? Возможно эти не все эти полгода ушли на программирование. Но тогда это "гипер" как-то теряет часть смысла.
И еще учтите, что "гипер" короткое оно у тех, кто хорошо знает. А чем сложнее фреймворк и чем больше связей — тем сложнее разбираться и больше на это надо времени.
D>Далее уже идут "хачу!", со всеми вытекающими. Решение получилось, не трогающее код фреймворка, и абсолютно стороннее — это хорошо.
Какие такие "хачу"? Мы говорим о базовых вещах, о нужности которых было известно заранее. Масштабирование там. Подразумевающее известно что.
D>Тем более что Иван сразу знал, что начинает использовать инструмент где нет репликаций, а значит сделал этот осознано.
Нет не "репликации". Нет управления соединениями.
Давайте мы абстрагируемся от личностей уже, ага? То, что получилось, это хороший и показательный кейс, и спасибо, что он рассказан честно. Выводы все заинтересованные сделают самостоятельно. Тут еще есть занятный пласт, связанный с навязанными джангой решениями (верстка, поддержка, etc), но это уже специфика конторы.
