Если рассматривать описанные события с этой стороны, то возникает вопрос почему команда Александра ушла не оставив описания архитектуры системы с обоснованием принятых решений. И если правильным направлением развития системы (в том числе повышение производительности в критичных сценариях) предполагалась доработка запросов и хранимок, почему наняли спеца без компетенций Oracle.
А так получилось что получилось: новый разраб стал решать проблему используя знакомые ему подходы и технологии. И сделал это с неплохим результатом, хотя, возможно, не так как это видел менеджмент, особенно учитывая его решение вернуть старую команду, которая возможно согласилась допиливать свою старую систему, но ожидаемо не имеет желания вникать в кардинально новую (значительно обновленную).
Обычно движки работают с некимactor, смесью Monster и подконтрольного игроку Hero.
В оригинале: Most of the engine just deals with “actors”, the superclass of both Monster and the player-controlled, gender-nonspecific Hero. (Основная часть (моего) движка работает с actor, надкласса как Monster так и управляемого игроком бесполого Hero.)
Текущая версия Dart [15 июля 2014] полностью основана на ASCII, хотя, что забавно, использует canvas API.
В оригинале: The current Dart version is all ASCII-based right now, ironically rendered using the canvas API. (Текущая версия (игры) на (языке) Dart работает только с ASCII визуализацией, хотя, что забавно, используя canvas API) - там дальше он упоминает о версии игры на C#.
Зачем привязываться к смещениям для вызова реализации из наследника? Можно объявить нужные "абстрактные" методы в базовом объекте, с реализацией по умолчанию (на всякий случай).
И, как выше упоминали, у вас получаются жирные объекты за счет того что они несут все функции в себе. Это прототипное ООП (как в JS), иногда имеет смысл конечно, но при более сложной модели стоит выделить такие функции в мета-объекты (классы) и держать единственную ссылку на класс в каждом объекте.
Раздувание ПО трогает только тех кто привык контролировать внутреннюю работу своих железок, знать что сколько ресурсов занимает, и скрупулезно следить за файлами и процессами.
Типичный современный пользователь об этом может вообще не знать, и когда сталкивается с отсутствием свободного места, проблема решается просто и относительно дешево - стереть лишнее или прикупить диск побольше. И то что новая железка (в купе с новой версией ПО) делает примерно тоже самое и примерно с той-же скоростью, для него не так важно. Зато это новая железка (в рекламе которой производитель показал лучшие цифры чем в прошлой) и новая программа (покрасивее, больше анимации и т. д.).
А с точки зрения бизнеса, все вообще хорошо, продажи растут, и надо продолжать в том же духе.
Если рассматривать описанные события с этой стороны, то возникает вопрос почему команда Александра ушла не оставив описания архитектуры системы с обоснованием принятых решений. И если правильным направлением развития системы (в том числе повышение производительности в критичных сценариях) предполагалась доработка запросов и хранимок, почему наняли спеца без компетенций Oracle.
А так получилось что получилось: новый разраб стал решать проблему используя знакомые ему подходы и технологии. И сделал это с неплохим результатом, хотя, возможно, не так как это видел менеджмент, особенно учитывая его решение вернуть старую команду, которая возможно согласилась допиливать свою старую систему, но ожидаемо не имеет желания вникать в кардинально новую (значительно обновленную).
В переводе местами смысл теряется. Например:
В оригинале: Most of the engine just deals with “actors”, the superclass of both Monster and the player-controlled, gender-nonspecific Hero. (Основная часть (моего) движка работает с actor, надкласса как Monster так и управляемого игроком бесполого Hero.)
В оригинале: The current Dart version is all ASCII-based right now, ironically rendered using the canvas API. (Текущая версия (игры) на (языке) Dart работает только с ASCII визуализацией, хотя, что забавно, используя canvas API) - там дальше он упоминает о версии игры на C#.
Зачем привязываться к смещениям для вызова реализации из наследника? Можно объявить нужные "абстрактные" методы в базовом объекте, с реализацией по умолчанию (на всякий случай).
И, как выше упоминали, у вас получаются жирные объекты за счет того что они несут все функции в себе. Это прототипное ООП (как в JS), иногда имеет смысл конечно, но при более сложной модели стоит выделить такие функции в мета-объекты (классы) и держать единственную ссылку на класс в каждом объекте.
Раздувание ПО трогает только тех кто привык контролировать внутреннюю работу своих железок, знать что сколько ресурсов занимает, и скрупулезно следить за файлами и процессами.
Типичный современный пользователь об этом может вообще не знать, и когда сталкивается с отсутствием свободного места, проблема решается просто и относительно дешево - стереть лишнее или прикупить диск побольше. И то что новая железка (в купе с новой версией ПО) делает примерно тоже самое и примерно с той-же скоростью, для него не так важно. Зато это новая железка (в рекламе которой производитель показал лучшие цифры чем в прошлой) и новая программа (покрасивее, больше анимации и т. д.).
А с точки зрения бизнеса, все вообще хорошо, продажи растут, и надо продолжать в том же духе.