Впрочем, чтобы избежать псевдоюридического флейма про «системы премирования» и обсуждения тонкостей ТК РФ в ущерб основной теме.
Все вышеописанное соотносится со здравым смыслом, естественным правом, а так же является следствием добровольного соглашения сторон.
Ни интереса, ни пиетета к бумаготворчеству богомерзкого РФ-чиновничества мы не испытываем. Равно как и не относимся к его юрисдикции.
Речь не о том, можно ли параллелить алгоритм, а в транзакциях. Приведенный пример отлично будет работать в MySQL без транзакций (точнее — никаких спецэффектов не появится). Его можно выполнить на MS и Oracle использованием распределенных транзакций, и его можно переписать так, что он будет выполнятся так же и без спецэффектов.
Ну какая разница отдельные или нет? Параметры передать можем, значит и на 1С переписать мое тоже можно.
А вот независимость данных штука очень мрачная — в приведенном примере ее не замечали месяц.
Я не знаю, что такое NOLOCK. Я знаю что такое транзакции :)
Речь не про конкретный пример, а про то, что при такой реализации есть подводные камни, про которые имеет смысл сказать. Привожу более конкретный пример (просто из головы).
Процесс заключается в том, что сразу после оприходования товара на складе его необходимо списать документами продажи.
Оригинальная обработка выглядит так (мне C# ближе):
...
// хеш товар-количество
var articles = income.getArticles();
//оприходовали товар
SaveIncome(income);
// так делать не надо, но сейчас не скорость важна
foreach(a in articles)
{
var outcome = FindOutComeByArticle(a);
// резервируем товар a
SaveOutcome(outcome, a);
}
...
Очевидное распараллеливание:
...
// хеш товар-количество
var articles = income.getArticles();
//оприходовали товар
SaveIncome(income);
// ускоряем в 1000 раз !
RunParallel(articles, (a) => var outcome = FindOutComeByArticle(a);
// резервируем товар a
SaveOutcome(outcome, a) );
...
Проблема в том, что такая реализация может великолепно отработать на тестах.
Оставлю интригу и напишу в чем проблема чуть позже :) Если меня не опередят конечно.
Я о другом. У Вас данные запрашиваются в 3-х разных транзакциях. Кроме того, время реального выполнения запроса неизвестно. Так что данные у вас могут быть рассогласованы, и консолидированный отчет будет содержать билиберду.
Просто стоить отметить, что такая реализация параллельной обработки имеет весьма опасные последствия.
Во-первых кажущаяся легкость распараллеливания. Однако, из-за того, что все задачи выполняются в разных транзакциях могут возникать ошибки подобные описанной выше. Во-вторых, такие ошибки крайне сложно искать — они недетерминированны и могут не воспроизводится под дебагером, да и вообще требовать весьма специфических условий для воспроизведения (например на одном серваке есть ошибка, на другом нет).
Кроме того, ошибка может проявлять себя не как исключение (exception), а как ошибка в рассчетах, тогда это совсем гиблый случай кто и когда заметит такое.
А что происходит с транзакциями при таких параллельных вычислениях в 1С?
Каждое задание в отдельной транзакции или все в одной? какой DTS используется тогда?
Отвечаю по пунктам:
1. заказчик может заказать доработку того, что или будет и так в новой версии, или то, что будет заменено другим функционалом.
Решение, работающее у заказчика — монолитное, и выход новой версии базовой конфигурации никак не влияет на решение у клиента. За подробностями позволю себе привести ссылки на мои предыдущие статьи Буриданов осел и композиция конфигурации и еще про модули. Коротко — функционал заказчику нужен потому, что есть бизнеспотребность. А она не привязана к новым версиям и тому подобному.
2. заказчик может из раза в раз одного и того же исполнителя аллокировать, это приведет к неравномерной загрузке всех исполнителей и невозможности планирования, например, отпуска.
Теоретически — да. Однако такого на практике не происходит. Тут я вижу 2 фактора:
— Разработчики отличаются не сильно (по крайней мере при сравнимых грейдах)
— Даже если такая звезда появляется, его личная ставка поднимается, и спрос на него падает по законам рынка.
3. Может сложиться ситуация, когда заявок много, ресурсов мало и кто-то должен волевым решением их переприоритезировать.
Это ошибка. Кто-то должен решить как найти ресурсы. Для переприоритизации есть только механизм приоритетов. Иначе начнется хаос, который продолжится и после пика нагрузки. Отучить заказчика от этого «удобного» механизма будет невозможно.
4.Указание квалификации разработчика фиксируется до оценки сложности задачи исполнителем.
Как указано в статье — заказчик может указать желаемую квалификацию. Может не указывать. Либо я не понял что-то.
С базовой конфигурации работает буквально несколько человек. С решениями у клиентов (суммарно) тысячи. Так что о баге нам сообщит партнер (как правило и со своим вариантом решения). Баг будет исправлен. Если баг может иметь место в других решениях то уведомляем партнеров о баге и рекомендуемом способе его исправления. Реально очень редкая ситуация, чтобы баг в базовой конфигурации всплыл после внедрения. Могу вспомнить буквально только 2 таких случая и оба они не баги даже, а проблемы производительности.
Первый посчитали слишком сложным в администрировании.
Он конечно много умеет из коробки, но почти все что надо мы написали примерно за то время, что админы его настраивали бы.
Второй — требует Java, а мы пишем на C#.
Все круто, но мой опыт работы со статическим анализатором (не PVS) был не такой радужный, как описано в начале статьи.
В коде (больше 10мб) на C# было найдено около 3000 ошибок. Просмотрели первые 100 — все false positives. Потом еще 300 через 3 — аналогично. В итоге не было найдено НИ ОДНОЙ реальной ошибки. Было найдено несколько ошибок, которые могли бы стать проблемой, но с исчезающей вероятностью. К сожалению, пришлось отказаться.
Интересно узнать мнение автора — C# менее подвержен ошибкам (более высокий уровень абстракции, сборщик мусора, функциональные расширения, поддержка await/async и прочих многопоточных примитивов на уровне языка), или просто анализаторы для него менее распространены. Есть ли планы по анализу C# кода?
В данном случае приходится выбирать некоторый баланс между производительностью системы, легкостью поддержки, скорости доставки изменений, стабильности и доступности данных.
Все изменения кода логируются, устраивать допрос не требуется.
Об этом я попытался рассказать в своей статье про систему версионирования.
Напомню, что каждый отдельный проект это заточенная под конкретного клиента система. Так что изменения у всех уникальные. Не возникало пока ситуаций что требуется зайти ко всем клиентам и сделать какие-либо одинаковые изменения.
1. Почти да.
Повторю наши требования — гарантированно отследить любые изменения. Любое изменение должно быть расследуемо. Я указал 2 аспекта которые препятствуют реализации требований. Первое — возможность работать с боевой базой кому-либо кроме сервера приложений. Второе — что есть операции, которые невозможно отследить. Поэтому мы лучше будем терпеть небольшой оверхед.
2. Вы неправильно поняли, эти запросы выполняются не по логу транзакций. Проблемы с ним я, по возможности, подробно описал в статье.
Если бы задача была снизить нагрузку на сервер БД мы бы выбрали не Oracle.
1. Да, нагрузка увеличивается, однако достоверность лога выше.
Кроме того, что данные могут быть изменены не только с сервера приложений (ну как минимум разработчик может подключится к базе напрямую), сами запросы могут быть специфическими, например — merge (sql оператор) с временной таблицей. Согласитесь, придется написать специальный код для логирования изменений и надеятся, что никто из разработчиков не поменяет код на какой-то другой. Следующий аспект — логирование только зафиксированных транзакций. Конечно, мы можем отслеживать выполнение операций commit в ORM сервера приложений (см. статью про управление транзакциями), однако оператор truncate или DDL операторы так же могут вызвать фиксацию транзакции. Рассчитывать, что разработчик НИКОГДА не ошибется подобным образом — верх безответсвенности.
2. Как сказанно у меня в статье — мы рассматривали другие хранилища. Однако, они либо страдают невероятной избыточностью логирования и не хранят полезной информации (Oracle Flashback Archive), либо не выдерживают логирования только зафиксированных изменений.
Не совсем. Общий код не копируется из проекта в проект. Он(код) существует в виде «базового решения», которое поддерживается соответствующей группой разработчиков в партнерском центре. На каждый новый проект внедряющий партнер берет это базовое решение и дополняет его кейсами или специфическими доработками. После внедрения получается монолитная система, не предусматривающая обновлений прикладной части (платформа инвариантна, и может обновляться). Нет такого процесса, как обновление «базового функционала». Если бизнесу требуется какая-либо функциональность, она всегда имеет какие-то бизнес-цели. Всегда требуется не только изменение программы, но и процессов предприятия. Если бизнесу нужна функция — она реализуется тем или иным способом.
По второй части. Внедряющий партнер имеет доступ ко всем исходным текстам прикладной части (в том числе и базового решения) и волен их менять по своему разумению. Так же, партнеры имеют доступ к части исходного кода платформы для ознакомительных целей. Собирать из исходников требуется только кастомные экранные формы.
Впрочем, мы думаем над тем, чтобы избавится и от этого.
Ух сколько!
Итак, по порядку.
Совершенно верно — ERP система (или более широко — система автоматизации предприятия) это система с частыми изменениями, очень длинным жизненным циклом и очень высокой стоимостью ошибки (система обрабатывает реальные деньги). Не могу назвать какие-ибо другие системы где указанные особенности присутствовали бы одновременно. В GameDev существуют системы с длинным циклом и высокой стоимостью ошибки, World of Warcraft или World of Tanks — они существуют уже долго, в них обрабатываются реальные деньги, но обновления — раз в год. В ERP системах изменения происходят ежедневно.
По Вашим вопросам.
1. Что есть для разработчика базового решения с точки зрения обновления системы
1.1. Разработка в боевой базе и использование редакций схемы БД. Как следствие:
— нет(и не надо) механизмов миграции данных
— запросы проверяются на реальных данных
1.2. Механизмы истории изменений решений и поиск авторов
1.3. Встроенные механизмы распределенной системы контроля версий
1.4. Модель с высоким уровнем абстракции
1.5. Отметка любых объектов решения тегами и поиск по ним
1.6. Тесты логики (и интеграция с TeamCity, возможна интеграция с подобными системами)
Насчет легкости их написания затрудняюсь ответить. Высокий уровень абстракции позволяет проверять правильность по нескольким параметрам (например после сохранения документа мне важно, чтобы он сгененрировал правильные проводки). Возможно, там пока еще есть непаханное поле.
2. Для аналитика. Благодаря встроенной системе контроля версий аналитик работает с «Тестовой» версией решения глядя на реальные данные.
Разработку «аналитиком» мы не приветствуем. Думаю в этом плане мы не отличаемся от других систем. Аналитик как разработчик может в рантайме менять все что угодно, за исключением кастомных экраных форм (требуется студия)
3. Для бизнеспользователя.
Повторюсь, мы проповедуем работу с реальным данными в разных версиях схемы БД. Поэтому нет таких операций, как мердж данных.
В приведенном Вами примере с новой колонкой, данные будут залиты в колонку разработчиком, и станут видны аналитикам (и потом пользователям) после переключения на версию, в метаданных которой эта колонка описана. Сама колонка физически с данными будет так же присутствовать. Для новых записей будет вычислятся значение по умолчанию (легко заметить, что это всегда возможно, когда возможен мердж пользовательских данных).
Вообще редакция схемы (точное название Schema edition) очень удобная функция. Фактически существует несколько версий View для просмотра данных и, соответственно, триггеров на Insert и Update. Схема определяется в момент подключения к БД.
Еще раз прочитал ответ, и понял, что в нем осталась двусмысленность. Попробую ее устранить.
1. C# как язык для описания бизнес-объектов, бизнеслогики и реализации всех прочих функций… Для рисования форм VisualStudio. Для описания бизнеслогики своя IDE с UI для описания бизнес-объектов (из которого генерятся соответствующие классы).
2. Система не модульная, а монолитная. Нет в ней модулей в виде отдельных файлов, программ или чего-либо еще. Кейс не модуль, это совокупность процессных, управленческих и технических решений. Да, в системе можно найти какие технические решения относятся к тому или иному кейсу, но это не модуль который можно перенести из одного проекта в другой копированием файлика или сходной операцией.
3. Обновления выходят для платформы и базового решения согласно графику.
В работающем решении можно обновить только платформу.
Обновления базового решения актуальны только для новых внедрений. Каждое решение для конкретного клиента — кастомизированный инструмент извлечения прибыли. Его изменения обусловлены не выходом новых версий базового решения, а только лишь изменением внешних или внутренних условий ведения бизнеса данного конкретного клиента.
Приведенный Вами пример — как раз ситуация не имеющая общего решения.
Еще добавлю пряму ссылку на описание архитектуры системы.
П. 4 вроде не может вызвать разночтений,
Все-таки попробую ответить на вопрос. Если я правильно понял, то его можно сформулировать как «Возможно ли совмещение функционала нескольких кейсов в рамках одного решения?».
Ответ на него — да. Функционал любого количества (необходимых) кейсов, пусть даже работающих в нескольких различных проектах переносится в новое решение у конкретного клиента.
Надо понимать, что система у нас монолитная, и переносимый функционал это не модуль в каком-либо виде. На всякий случай напомню, что кейс — это совокупность процессных, управленческих и технических решений.
Все вышеописанное соотносится со здравым смыслом, естественным правом, а так же является следствием добровольного соглашения сторон.
Ни интереса, ни пиетета к бумаготворчеству богомерзкого РФ-чиновничества мы не испытываем. Равно как и не относимся к его юрисдикции.
КЗОТ не предусматривает единственно возможным способ ежемесячного получения идентичной суммы.
А вот независимость данных штука очень мрачная — в приведенном примере ее не замечали месяц.
Речь не про конкретный пример, а про то, что при такой реализации есть подводные камни, про которые имеет смысл сказать. Привожу более конкретный пример (просто из головы).
Процесс заключается в том, что сразу после оприходования товара на складе его необходимо списать документами продажи.
Оригинальная обработка выглядит так (мне C# ближе):
Очевидное распараллеливание:
Проблема в том, что такая реализация может великолепно отработать на тестах.
Оставлю интригу и напишу в чем проблема чуть позже :) Если меня не опередят конечно.
Просто стоить отметить, что такая реализация параллельной обработки имеет весьма опасные последствия.
Во-первых кажущаяся легкость распараллеливания. Однако, из-за того, что все задачи выполняются в разных транзакциях могут возникать ошибки подобные описанной выше. Во-вторых, такие ошибки крайне сложно искать — они недетерминированны и могут не воспроизводится под дебагером, да и вообще требовать весьма специфических условий для воспроизведения (например на одном серваке есть ошибка, на другом нет).
Кроме того, ошибка может проявлять себя не как исключение (exception), а как ошибка в рассчетах, тогда это совсем гиблый случай кто и когда заметит такое.
Каждое задание в отдельной транзакции или все в одной? какой DTS используется тогда?
1. заказчик может заказать доработку того, что или будет и так в новой версии, или то, что будет заменено другим функционалом.
Решение, работающее у заказчика — монолитное, и выход новой версии базовой конфигурации никак не влияет на решение у клиента. За подробностями позволю себе привести ссылки на мои предыдущие статьи Буриданов осел и композиция конфигурации и еще про модули. Коротко — функционал заказчику нужен потому, что есть бизнеспотребность. А она не привязана к новым версиям и тому подобному.
2. заказчик может из раза в раз одного и того же исполнителя аллокировать, это приведет к неравномерной загрузке всех исполнителей и невозможности планирования, например, отпуска.
Теоретически — да. Однако такого на практике не происходит. Тут я вижу 2 фактора:
— Разработчики отличаются не сильно (по крайней мере при сравнимых грейдах)
— Даже если такая звезда появляется, его личная ставка поднимается, и спрос на него падает по законам рынка.
3. Может сложиться ситуация, когда заявок много, ресурсов мало и кто-то должен волевым решением их переприоритезировать.
Это ошибка. Кто-то должен решить как найти ресурсы. Для переприоритизации есть только механизм приоритетов. Иначе начнется хаос, который продолжится и после пика нагрузки. Отучить заказчика от этого «удобного» механизма будет невозможно.
4.Указание квалификации разработчика фиксируется до оценки сложности задачи исполнителем.
Как указано в статье — заказчик может указать желаемую квалификацию. Может не указывать. Либо я не понял что-то.
Он конечно много умеет из коробки, но почти все что надо мы написали примерно за то время, что админы его настраивали бы.
Второй — требует Java, а мы пишем на C#.
Они тоже показывали много примеров на С++, однако с C# какая-то пустота, вот и интересно, почему.
В коде (больше 10мб) на C# было найдено около 3000 ошибок. Просмотрели первые 100 — все false positives. Потом еще 300 через 3 — аналогично. В итоге не было найдено НИ ОДНОЙ реальной ошибки. Было найдено несколько ошибок, которые могли бы стать проблемой, но с исчезающей вероятностью. К сожалению, пришлось отказаться.
Интересно узнать мнение автора — C# менее подвержен ошибкам (более высокий уровень абстракции, сборщик мусора, функциональные расширения, поддержка await/async и прочих многопоточных примитивов на уровне языка), или просто анализаторы для него менее распространены. Есть ли планы по анализу C# кода?
Все изменения кода логируются, устраивать допрос не требуется.
Об этом я попытался рассказать в своей статье про систему версионирования.
Напомню, что каждый отдельный проект это заточенная под конкретного клиента система. Так что изменения у всех уникальные. Не возникало пока ситуаций что требуется зайти ко всем клиентам и сделать какие-либо одинаковые изменения.
Повторю наши требования — гарантированно отследить любые изменения. Любое изменение должно быть расследуемо. Я указал 2 аспекта которые препятствуют реализации требований. Первое — возможность работать с боевой базой кому-либо кроме сервера приложений. Второе — что есть операции, которые невозможно отследить. Поэтому мы лучше будем терпеть небольшой оверхед.
2. Вы неправильно поняли, эти запросы выполняются не по логу транзакций. Проблемы с ним я, по возможности, подробно описал в статье.
Если бы задача была снизить нагрузку на сервер БД мы бы выбрали не Oracle.
Кроме того, что данные могут быть изменены не только с сервера приложений (ну как минимум разработчик может подключится к базе напрямую), сами запросы могут быть специфическими, например — merge (sql оператор) с временной таблицей. Согласитесь, придется написать специальный код для логирования изменений и надеятся, что никто из разработчиков не поменяет код на какой-то другой. Следующий аспект — логирование только зафиксированных транзакций. Конечно, мы можем отслеживать выполнение операций commit в ORM сервера приложений (см. статью про управление транзакциями), однако оператор truncate или DDL операторы так же могут вызвать фиксацию транзакции. Рассчитывать, что разработчик НИКОГДА не ошибется подобным образом — верх безответсвенности.
2. Как сказанно у меня в статье — мы рассматривали другие хранилища. Однако, они либо страдают невероятной избыточностью логирования и не хранят полезной информации (Oracle Flashback Archive), либо не выдерживают логирования только зафиксированных изменений.
По второй части. Внедряющий партнер имеет доступ ко всем исходным текстам прикладной части (в том числе и базового решения) и волен их менять по своему разумению. Так же, партнеры имеют доступ к части исходного кода платформы для ознакомительных целей. Собирать из исходников требуется только кастомные экранные формы.
Впрочем, мы думаем над тем, чтобы избавится и от этого.
Итак, по порядку.
Совершенно верно — ERP система (или более широко — система автоматизации предприятия) это система с частыми изменениями, очень длинным жизненным циклом и очень высокой стоимостью ошибки (система обрабатывает реальные деньги). Не могу назвать какие-ибо другие системы где указанные особенности присутствовали бы одновременно. В GameDev существуют системы с длинным циклом и высокой стоимостью ошибки, World of Warcraft или World of Tanks — они существуют уже долго, в них обрабатываются реальные деньги, но обновления — раз в год. В ERP системах изменения происходят ежедневно.
По Вашим вопросам.
1. Что есть для разработчика базового решения с точки зрения обновления системы
1.1. Разработка в боевой базе и использование редакций схемы БД. Как следствие:
— нет(и не надо) механизмов миграции данных
— запросы проверяются на реальных данных
1.2. Механизмы истории изменений решений и поиск авторов
1.3. Встроенные механизмы распределенной системы контроля версий
1.4. Модель с высоким уровнем абстракции
1.5. Отметка любых объектов решения тегами и поиск по ним
1.6. Тесты логики (и интеграция с TeamCity, возможна интеграция с подобными системами)
Насчет легкости их написания затрудняюсь ответить. Высокий уровень абстракции позволяет проверять правильность по нескольким параметрам (например после сохранения документа мне важно, чтобы он сгененрировал правильные проводки). Возможно, там пока еще есть непаханное поле.
2. Для аналитика. Благодаря встроенной системе контроля версий аналитик работает с «Тестовой» версией решения глядя на реальные данные.
Разработку «аналитиком» мы не приветствуем. Думаю в этом плане мы не отличаемся от других систем. Аналитик как разработчик может в рантайме менять все что угодно, за исключением кастомных экраных форм (требуется студия)
3. Для бизнеспользователя.
Повторюсь, мы проповедуем работу с реальным данными в разных версиях схемы БД. Поэтому нет таких операций, как мердж данных.
В приведенном Вами примере с новой колонкой, данные будут залиты в колонку разработчиком, и станут видны аналитикам (и потом пользователям) после переключения на версию, в метаданных которой эта колонка описана. Сама колонка физически с данными будет так же присутствовать. Для новых записей будет вычислятся значение по умолчанию (легко заметить, что это всегда возможно, когда возможен мердж пользовательских данных).
Вообще редакция схемы (точное название Schema edition) очень удобная функция. Фактически существует несколько версий View для просмотра данных и, соответственно, триггеров на Insert и Update. Схема определяется в момент подключения к БД.
1. C# как язык для описания бизнес-объектов, бизнеслогики и реализации всех прочих функций… Для рисования форм VisualStudio. Для описания бизнеслогики своя IDE с UI для описания бизнес-объектов (из которого генерятся соответствующие классы).
2. Система не модульная, а монолитная. Нет в ней модулей в виде отдельных файлов, программ или чего-либо еще. Кейс не модуль, это совокупность процессных, управленческих и технических решений. Да, в системе можно найти какие технические решения относятся к тому или иному кейсу, но это не модуль который можно перенести из одного проекта в другой копированием файлика или сходной операцией.
3. Обновления выходят для платформы и базового решения согласно графику.
В работающем решении можно обновить только платформу.
Обновления базового решения актуальны только для новых внедрений. Каждое решение для конкретного клиента — кастомизированный инструмент извлечения прибыли. Его изменения обусловлены не выходом новых версий базового решения, а только лишь изменением внешних или внутренних условий ведения бизнеса данного конкретного клиента.
Приведенный Вами пример — как раз ситуация не имеющая общего решения.
Еще добавлю пряму ссылку на описание архитектуры системы.
П. 4 вроде не может вызвать разночтений,
Ответ на него — да. Функционал любого количества (необходимых) кейсов, пусть даже работающих в нескольких различных проектах переносится в новое решение у конкретного клиента.
Надо понимать, что система у нас монолитная, и переносимый функционал это не модуль в каком-либо виде. На всякий случай напомню, что кейс — это совокупность процессных, управленческих и технических решений.