Оригинал статьи нам показался интересным, поскольку отражает актуальные тренды, в том числе и на глобальном уровне. Всех принципов мы не придерживаемся и не призываем к этому) Оставили свое мнение после трех звездочек
На период эксперимента мы совмещали кубики с обычной критикой) Ни о какой замене речи не было. Кубики стали элементом геймификации, который дополнительно стимулировал коллег.
В статье нигде не сказано, что кубики заменили обычную обратную связь. В нашей компании достаточно демократичная атмосфера, и коллеги не стесняются вести честные диалоги. В этом эксперименте мы просто попробовали использовать элемент геймификации, некий фан, чтобы как-то дополнительно мотивировать коллег :)
Eyeadmin спасибо за вопросы! Ответил на похожий комментарий выше.
Правда, пожалуй, стоит уточнить, что у нас действительно несколько команд разработки, но они не изолированы друг от друга и работают как одно целое.
Подход на наш взгляд себя оправдывает, но впереди нам предстоит еще много интересной и увлекательной работы!
Насчет инвестирования — надеюсь вы нас простите — прокомментировать не можем :)
fsukharev спасибо за вопросы! Отвечу по пунктам.
1. Размер команды в данный момент: 20 разработчиков, несколько аналитиков, несколько тестировщиков, Devops-инженер. Но не всегда было так. Начинали гораздо меньшим составом;
2. На данный момент разработка ведется примерно 1.5 года и не останавливается;
3. На сегодняшний день внедрено/внедряется 6 систем на базе нашего решения, и это только начало;
4. Эффект несомненно есть, но не только экономический. Многие вещи, которые делали ранее в рамках других проектов (интеграции, настройка бизнес-процессов, доставка приложения и т.д.), были переосмыслены и усовершенствованы. Появилась возможность настраивать более сложные кейсы. Да и специалисты стали работать с самыми современными технологиями и инструментами, что, как нам кажется, тоже большой плюс.
vagon333 добрый день! Спасибо за отличные вопросы!
Ответим по пунктам:
1. С точки зрения развертывания и поддержки — этот процесс мы автоматизируем. Поднимаются сервисы оркестратором и в последствии система мониторинга отслеживает состояние всех сервисов. Отличные от .NET платформы, на которых сделаны некоторые из используемых нами инструментов, в принципе не смущают, тем более что взаимодействие с ними происходит в основном через Rest Api;
2. Частично ответил в предыдущем пункте и в самой статье. У нас развертывание автоматизировано и мы не хотели ограничивать себя монолитом, так как заранее не знаем нагрузку;
3. Также в первой части статьи постарались обозначить наши мотивы разработки своего продукта. У нас есть свои нерешенные вопросы, которые мы постарались решить этим новым продуктом. Да, это конструктор в первую очередь, но который умеет решать и некоторые специфические задачи.
По примечаниям:
1. Действительно dbms используется только как хранилище данных и это одно из важных требований — никакой логики на стороне БД;
2. Вопрос с тегами решили :);
3. Здесь мы выбрали вариативность. Некоторые клиенты настаивает на использовании конкретных dbms по разным причинам (импортозамещение например). SQL Server Express 2019 хоть и бесплатный, но его нет в реестре отечественного ПО (это бывает важно). Да и в нем есть ограничения, к которым не хочется привязываться. Но как один из вариантов он вполне может подойти.
SOLON7 отличные вопросы!
Мы храним описание полей объекта — то есть метаданные, необходимые для отображения поля на форме и поиска по нему (если поиск необходим — это тоже настраивается).
Генерацией кода (с последующей перекомпиляцией) и БД мы не занимаемся, хотя знаем, что при разработке некоторых похожих систем пошли именно таким путем.
Отвечая на Ваш вопрос — типизация в результате динамическая.
Миграции сделали настраиваемыми из конфига. Есть фабрика, которая возвращает те или иные Options в зависимости от настроек. Для каждой СУБД мы поддерживаем одновременно свои миграции. Когда исследовали этот вопрос была попытка использовать одни и те же миграции — просто добавляли аннотации для разных провайдеров, но сразу обнаружили, что миграции генерятся разными провайдерами со своими особенностями, которые не очень совпадают (даже для простейших структур).
SOLON7 пока исходников в открытом доступе нет. Видим, что есть интерес в комментариях — обещаем подумать над этим. Но интересующие Вас аспекты и особенности реализации мы с удовольствием можем рассказать здесь. ORM используем EF Core.
SOLON7, есть уверенность и надежда, что сообщество разработчиков на .NET Core еще наверстает упущенное, если это потребуется. Тем более, что тесты производительности .NET Core выглядят всё более впечатляющими. Говоря о нашем продукте — использованные нами инструменты лишь выполняют свою конкретную задачу. Это лишь малая часть системы. Но это скорее позитивно, что такие замечательные инструменты можно использовать и на других платформах!
Добрый день! Спасибо за Ваше мнение. Open source в тексте и тегах считаем закономерным употреблять потому, что мы используем open source технологии и инструменты. Это не значит, что наш продукт является открытым (поэтому нет линков на git и docker), но и мы не считаем, что указание на open source кого-то должно было обмануть. Еще раз спасибо за комментарий. Возможно для других читателей информация из статьи будет всё же полезной. Хорошего Вам дня!
Qt имеет достаточно серьёзный набор кроcсплатформенных библиотек.
1. Большой набор библиотек для работы с устройствами.
2. Библиотеки для работы с БД и дрйвер SQLite из коробки.
3. Контейнеры. Спорный вопрос. По идее Qt-шные более удобные и быстрые в копировании нежели STL-ные, по причине наличия в них COW. Хотя в современных стандартах COW не рекомендуется. Пропагандируется move семантика.
4. Ну и, конечно, механизм сигнал-слот. Есть конечно аналоги в boost библиотеке. Но в Qt (субъективно) они более дружелюбные
Ну а сама среда дело привычки. При переходе с Visual Studio поначалу путались в хоткеях)
Да, изначально не следовали. Еще Дональд Кнут сказал «premature optimization is the root of all evil». Ну и как водится, сроки горели, поэтому сначала функциональность, а уже потом оптимизацией занялись ;-)
к сожалению, формат статьи и NDA не позволяют написать много о каких-то интересных находках и преодоленных трудностях, так что немного технических вставок это скорее для полноты картины. Основная цель статьи — поделиться опытом успешной разработки нашей компанией большого приложения, работающего на широкой сети устройств по всей стране. Корпоративных приложений на SF не так много и пионерство заключается в этом, а не в том как подружить телефон с кассой по Bluetooth на Qt. Тем более что приложение было выведено на рынок еще в 2017 году.
Правда, пожалуй, стоит уточнить, что у нас действительно несколько команд разработки, но они не изолированы друг от друга и работают как одно целое.
Подход на наш взгляд себя оправдывает, но впереди нам предстоит еще много интересной и увлекательной работы!
Насчет инвестирования — надеюсь вы нас простите — прокомментировать не можем :)
1. Размер команды в данный момент: 20 разработчиков, несколько аналитиков, несколько тестировщиков, Devops-инженер. Но не всегда было так. Начинали гораздо меньшим составом;
2. На данный момент разработка ведется примерно 1.5 года и не останавливается;
3. На сегодняшний день внедрено/внедряется 6 систем на базе нашего решения, и это только начало;
4. Эффект несомненно есть, но не только экономический. Многие вещи, которые делали ранее в рамках других проектов (интеграции, настройка бизнес-процессов, доставка приложения и т.д.), были переосмыслены и усовершенствованы. Появилась возможность настраивать более сложные кейсы. Да и специалисты стали работать с самыми современными технологиями и инструментами, что, как нам кажется, тоже большой плюс.
Ответим по пунктам:
1. С точки зрения развертывания и поддержки — этот процесс мы автоматизируем. Поднимаются сервисы оркестратором и в последствии система мониторинга отслеживает состояние всех сервисов. Отличные от .NET платформы, на которых сделаны некоторые из используемых нами инструментов, в принципе не смущают, тем более что взаимодействие с ними происходит в основном через Rest Api;
2. Частично ответил в предыдущем пункте и в самой статье. У нас развертывание автоматизировано и мы не хотели ограничивать себя монолитом, так как заранее не знаем нагрузку;
3. Также в первой части статьи постарались обозначить наши мотивы разработки своего продукта. У нас есть свои нерешенные вопросы, которые мы постарались решить этим новым продуктом. Да, это конструктор в первую очередь, но который умеет решать и некоторые специфические задачи.
По примечаниям:
1. Действительно dbms используется только как хранилище данных и это одно из важных требований — никакой логики на стороне БД;
2. Вопрос с тегами решили :);
3. Здесь мы выбрали вариативность. Некоторые клиенты настаивает на использовании конкретных dbms по разным причинам (импортозамещение например). SQL Server Express 2019 хоть и бесплатный, но его нет в реестре отечественного ПО (это бывает важно). Да и в нем есть ограничения, к которым не хочется привязываться. Но как один из вариантов он вполне может подойти.
Мы храним описание полей объекта — то есть метаданные, необходимые для отображения поля на форме и поиска по нему (если поиск необходим — это тоже настраивается).
Генерацией кода (с последующей перекомпиляцией) и БД мы не занимаемся, хотя знаем, что при разработке некоторых похожих систем пошли именно таким путем.
Отвечая на Ваш вопрос — типизация в результате динамическая.
Миграции сделали настраиваемыми из конфига. Есть фабрика, которая возвращает те или иные Options в зависимости от настроек. Для каждой СУБД мы поддерживаем одновременно свои миграции. Когда исследовали этот вопрос была попытка использовать одни и те же миграции — просто добавляли аннотации для разных провайдеров, но сразу обнаружили, что миграции генерятся разными провайдерами со своими особенностями, которые не очень совпадают (даже для простейших структур).
1. Большой набор библиотек для работы с устройствами.
2. Библиотеки для работы с БД и дрйвер SQLite из коробки.
3. Контейнеры. Спорный вопрос. По идее Qt-шные более удобные и быстрые в копировании нежели STL-ные, по причине наличия в них COW. Хотя в современных стандартах COW не рекомендуется. Пропагандируется move семантика.
4. Ну и, конечно, механизм сигнал-слот. Есть конечно аналоги в boost библиотеке. Но в Qt (субъективно) они более дружелюбные
Ну а сама среда дело привычки. При переходе с Visual Studio поначалу путались в хоткеях)