Замечания аудитор записывает в СППР. Сюда загружается отчет о сравнении, который при загрузке парсится, по нему заполняется список измененных тех. проектом объектов. Сам отчет аудитор просматривает тоже из СППР в контексте измененных объектов. "Проглядел список измененных объектов — посмотрел что именно изменилось каждом объекте — записал замечания" — все это не выходя из СППР. Замечания регистрируются в ошибками и попадают в общий контроль сроков исправления ошибок.
Формируется отчет о сравнении ветки разработки и основного хранилища. Аудитор просматривает изменения, если нужно посмотреть более внимательно, то открывает в Конфигураторе конфигурацию ветки.
Также проверки кода делаются автоматически с помощью продукта "Автоматическая проверка конфигураций", куда в поставку заложены формальные проверки целого рядов стандартов разработки.
Непонятно разделение на "методическую проработку" и "разработку". Это неразделимые понятия при работе над таким сложным и многовариативным проектом, как "ERP". В ходе разработки ведется методическая проработка вопросов тим-лидами, ответственными за проекты, руководителем разработки. Если это необходимо, то привлекаются сторонние специалисты: проводятся консультации с представителями клиентов (логистами, фин. директорами, производственниками и т.д..), партнеров, юристами, аудиторами, специалистами по юзабилити, производительности и т.д… Это делается на протяжении всей работы над проектом: при выработке начальной концепции, при доработке концепции, при обсуждении сценариев работы пользователей, оценке интерфейсов и т.д… Будут привлекаться другие специалисты или нет, насколько будут привлекаться, на каких этапах — решается индивидуально при работе над каждым проектом.
Разработку мы ведем в хранилищах разработки, которые стоят на поддержке от основного хранилища. Это и есть наши бранчи. Создание бранчей автоматизировано и происходит с помощью СППР. При этом использует пакетный режим запуска "Конфигуратора", т.е. в принципе мы пользуемся штатными возможностями платформы. В одном бранче редко бывает необходимо нескольким разработчикам захватывать один объект.
В основном хранилище происходят заливки проектов и исправления ошибок, поэтому ситуации когда двум разработчикам нужен один объект опять-таки минимизированы, и тем более очень редко бывает, когда объект нужен надолго. В "горячую пору", когда много проектов нужно залить в основное хранилище — это после снятия моратория, связанного с выпуском версии, когда за период моратория накапливается какое-то количество проектов на заливку — мы решаем организационно, выстраивая очередь заливок. Но это не часто бывает.
С быстродействием примерно та же история — в основном хранилище разработка не ведется, поэтому фатальна скорость работы не основного хранилища, а бранчей. В бранчах же история небольшая, поэтому бранчи достаточно шустро работают.
ИМХО незаслуженно забыта отечественная разработка — мобильная платформа 1С.
Поддержка Android, iOS, Windows Phone. Краткий обзор (несколько устаревший — делался до реализации поддержки Windows).
Google Test модифицировался:
1. Из-за особенностей STL, который использует платформа
2. Для возможности тестирования dll и so компонентов из отдельного исполняемого файла — плеера тестов.
Очень интересна внутренняя база тестирования (т.н. «интеграционные» тесты на языке 1С: Предприятия)
ИМХО подобная ИБ была бы интересна многим разработчикам
Вопрос — нет ли планов вывода этой ИБ в общую доступность?
Пока не могу ничего сказать.
Тут, как у любой палки — два конца. Ценность такой ИБ для внешних разработчиков понятна.
Но, делая ИБ общедоступной, мы должны будем поддерживать стандартный цикл жизни продукта — релизы, багфиксы и т.п., т.е. расходовать на это ресурсы.
Ничего не увидел о т.н. «сценарном» тестировании, добавленном в 8.3
Статья больше про тестирование платформы. 1С: Сценарное Тестирование — продукт для тестирования прикладных решений. Понятно, что тестируя прикладные решения, мы заодно тестируем и платформу, но первичной целью продукта это все же не является.
Да, мы широко используем 1С: Сценарное Тестирование для тестов типовых конфигураций. Планируем написать об этом в одной из следующих статей.
Внутри 1С мы (несколько сотен пользователей) используем 1С: Документооборот (в том числе и мобильного клиента Документооборота) для работы с почтой (внешней и внутренней), календарем, задачами, для коллективной работы с файлами и т.п.
Согласен, коррелирующие подзапросы непосредственно в тексте запроса были бы удобны. Сейчас такие задачи приходится решать через временные таблицы. Но тут мы приходим к стандартной задаче в жизненном цикле большого софтверного продукта. Есть запрос на новую функциональность (коррелирующие подзапросы). При этом задача, для решения которой требуется эта новая функциональность, уже решается существующей функциональностью (временными таблицами), пусть и не так изящно. А еще у нас есть список других запросов на новую функциональность, в том числе и ту, которая решает задачи, до сих пор решения в рамках системы решения не имеющие.
Этим абзацем я иллюстрировал методику расставления приоритетов (новая функциональность, позволяющая решать НОВЫЕ задачи vs. новая функциональность, позволяющая решать задачи, уже имеющие решения в рамках существующей функциональности). Иногда первый тип новой функциональности получает более высокий приоритет, т.к. расширяет функциональность системы в целом; иногда — наоборот.
У вашего руководителя есть новые бизнес-идеи (работа в облаке, интерфейс Такси и т.п.). Именно их запросы вы и реализуете.
Коллега, есть идеи стратегические (работа в облаке, веб-клиент, мобильная платформа и т.п.). Без их реализации через некоторое время фирма будет обойдена конкурентами, лишится прибыли, снизит как следствие затраты на разработку, и в итоге станет хуже всем — и фирме, и партнерам/внедренцам, и клиентам. Не реализовывать стратегические идеи мы не имеем права.
Есть идеи тактические (импорт содержимого файлов в форматах Microsoft Excel 97-2010 и OpenDocument в табличный документ, использование логических выражений в описании поля выборки и в выражениях фильтрации результатов запроса (предложение ГДЕ), использование функций и временных таблиц при работе с внешними источниками данных и т.д. и т.п) — их мы тоже реализуем. Я сожалею, честно, без дураков, что та функциональность, которая необходима лично вам, до сих пор не реализована.
И партнерский семинар и ваш выход на площадку habrahabr это чистый пиар, без желания получить обратную связь
Не скажите. Несмотря на что, что на Хабре мы недавно, уже от нескольких пользователей получили в личную переписку полезный фидбэк, который планируем использовать в работе. Про семинар даже и не говорю.
поэтому я и написал, что разработчикам платформы нельзя отмежеваться от разработчиков флагманской типовой конфигурации, что вы пытались сделать несколько постов назад
Где я такое писал? Дайте пожалуйста ссылку или цитату.
Как например ваши расширения помогут, если для реализации требований клиента необходимо внести изменения в типовой функционал (модули), который потом будет обновляться?
Повторюсь, на проектах внедрения (не только 1С) всегда есть этап Performance Tuning, то есть тонкая настройка системы для конкретного клиента. Ваша платформа таких возможностей не предоставляет
Конфигурация предоставляется в исходных кодах. Есть «Замер производительности» в Конфигураторе, есть КИП — можно выявить узкие места, поменять исходный код и свойства объектов конфигурации.
Проверять нужно на клиент-серверной базе SQL Server УПП 1.2-1.3.
Спасибо, теперь понял, о чем речь.
Да, такое поведение платформы исправили в 8.2 (если не ошибаюсь — 8.2.14, «Запрос, содержащий оператор В с множественными операндами, в подзапросе которого есть упорядочивание, может быть исполнен, если из подзапроса нет обращений к полям внешнего запроса.», есть в V8Update.htm). Исправление было сделано в рамках унификации работы с СУБД, т.к. предыдущее поведение не работало на всех СУБД.
Ваш запрос можно модифицировать так, чтобы он заработал на 8.2:
ВЫБРАТЬ
Товары.Ссылка,
ЦеныТоваров.Цена
ИЗ Справочник.Номенклатура КАК Товары
ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.ЦеныНоменклатуры КАК ЦеныТоваров
ПО
(ЦеныТоваров.ТипЦен) В (
ВЫБРАТЬ ПЕРВЫЕ 1
Подчиненные.ТипЦен
ИЗ РегистрСведений.ЦеныНоменклатуры КАК Подчиненные
ГДЕ
Подчиненные.Номенклатура = Товары.Ссылка
УПОРЯДОЧИТЬ ПО
Период)
Сделайте поиск — «опрос по средствам разработки». Оказывается опрос был в начале 2013 года, то есть почти три года прошло.
Сделал, посмотрел. Все 10 страниц читать не стал, пробежал первые три. Часть пожеланий реализована в Enterprise Development Tools (но тут придется подождать его готовности). Были пожелания ускорить работу с хранилищем конфигураций — работаем в этом направлении, почти каждую версию платформы есть доработки в этом направлении.
Надеюсь, не будете обвинять нас в том, что мы не реализовали ВСЕ пожелания из опроса?
Назовите разработанную с 0 конфигурацию по сложности и функциональности сопоставимую с ERP 2 или хотя бы УПП.
А есть потребность в конфигурациях такого масштаба? Можете привести пример? Я серьезно, вопрос не праздный.
Давайте посмотрим шире — в мире вообще мало случаев, когда на аналогичных платформах партнерами (а не самими производителями платформы) создавались решения масштабов ERP. И не потому что платформы плохи, а потому что это а) долго и дорого, может себе позволить только крупная компания и б) как правило такое/похожее по функциональности решение уже сделал производитель платформы, и проще доработать его, чем писать своё.
Уж расширения точно сделаны не для внедренцев. Это механизм, необходимый для полноценной работы другой вашей мечты — работе в облаке. Для проектов внедрения — никак не пригодится.
Почему так считаете? Мы переносим в расширения все больше и больше объектов. Уже видел случаи переноса внедренцами части модификаций на местах в расширения с целью облегчить переход на новые версии. Что может помешать использовать расширения внедренцам? Пока — малое количество объектов, поддерживаемых расширениями. Но их будет все больше. Так что проблем не вижу. Если их видите вы — опишите пожалуйста.
Один из вариантов — не давать сертификат 1С: Совместимо для конфигураций, которые используют такие конструкции. Это хоть какой то выход.
У меня есть некоторый опыт написания платформ для нескольких ERP (не связанный с 1С). Могу сказать по своему опыту — введение такой «полуподдерживаемой» функциональности в платформу через пару версий их активного использования прикладными разработчиками приводит к проблемам в поддержке и развитии платформы, которые сводят на ноль все преимущества этой функциональности. Это даже если платформа не публичная и ее используют только прикладные программисты внутри компании. Если же платформа публичная, как у 1С — количество неприятностей можно смело возводить в квадрат (а то и в куб).
Попробуйте использовать в () поля из присоединяемой таблицы, а в подзапросе тоже выбирать данные из присоединяемой таблицы, а не из основной и все встанет на свои места
Можете написать такой запрос для демо-базы, который работает на 8.1 и не работает на 8.3?
Мне действительно интересен этот вопрос — «отваливают» функциональность довольно редко, хотелось бы разобраться.
Таких топиков полно, только без участия разработчиков платформы и конфигураций. Смысл?
В прошлом году подняли вопрос о том, чего не хватает в платформе. Не хотите обсудить, что из этого сделали?
О каком вопросе речь, напомните пожалуйста. Возможно я не в курсе.
Ну и надо помнить что год — не то чтобы очень большой срок для софтверного проекта в миллионы строк кода.
А почему вы считаете, что это плохо?
В основном хранилище происходят заливки проектов и исправления ошибок, поэтому ситуации когда двум разработчикам нужен один объект опять-таки минимизированы, и тем более очень редко бывает, когда объект нужен надолго. В "горячую пору", когда много проектов нужно залить в основное хранилище — это после снятия моратория, связанного с выпуском версии, когда за период моратория накапливается какое-то количество проектов на заливку — мы решаем организационно, выстраивая очередь заливок. Но это не часто бывает.
С быстродействием примерно та же история — в основном хранилище разработка не ведется, поэтому фатальна скорость работы не основного хранилища, а бранчей. В бранчах же история небольшая, поэтому бранчи достаточно шустро работают.
Вы у каждого явления видите только одну сторону?
Ну и не устану повторять — ненависть лучше, чем равнодушие)
Для непубличных коммуникаций у тебя есть моя почта)
Поддержка Android, iOS, Windows Phone.
Краткий обзор (несколько устаревший — делался до реализации поддержки Windows).
Если есть заинтересованность — присылайте мне резюме на grip@1c.ru, я переправлю нашим кадровикам.
1. Из-за особенностей STL, который использует платформа
2. Для возможности тестирования dll и so компонентов из отдельного исполняемого файла — плеера тестов.
Пока не могу ничего сказать.
Тут, как у любой палки — два конца. Ценность такой ИБ для внешних разработчиков понятна.
Но, делая ИБ общедоступной, мы должны будем поддерживать стандартный цикл жизни продукта — релизы, багфиксы и т.п., т.е. расходовать на это ресурсы.
Статья больше про тестирование платформы.
1С: Сценарное Тестирование — продукт для тестирования прикладных решений. Понятно, что тестируя прикладные решения, мы заодно тестируем и платформу, но первичной целью продукта это все же не является.
Да, мы широко используем 1С: Сценарное Тестирование для тестов типовых конфигураций. Планируем написать об этом в одной из следующих статей.
Этим абзацем я иллюстрировал методику расставления приоритетов (новая функциональность, позволяющая решать НОВЫЕ задачи vs. новая функциональность, позволяющая решать задачи, уже имеющие решения в рамках существующей функциональности). Иногда первый тип новой функциональности получает более высокий приоритет, т.к. расширяет функциональность системы в целом; иногда — наоборот.
Коллега, есть идеи стратегические (работа в облаке, веб-клиент, мобильная платформа и т.п.). Без их реализации через некоторое время фирма будет обойдена конкурентами, лишится прибыли, снизит как следствие затраты на разработку, и в итоге станет хуже всем — и фирме, и партнерам/внедренцам, и клиентам. Не реализовывать стратегические идеи мы не имеем права.
Есть идеи тактические (импорт содержимого файлов в форматах Microsoft Excel 97-2010 и OpenDocument в табличный документ, использование логических выражений в описании поля выборки и в выражениях фильтрации результатов запроса (предложение ГДЕ), использование функций и временных таблиц при работе с внешними источниками данных и т.д. и т.п) — их мы тоже реализуем. Я сожалею, честно, без дураков, что та функциональность, которая необходима лично вам, до сих пор не реализована.
Не скажите. Несмотря на что, что на Хабре мы недавно, уже от нескольких пользователей получили в личную переписку полезный фидбэк, который планируем использовать в работе. Про семинар даже и не говорю.
Дайте пожалуйста ссылку или цитату. Не припоминаю, что я писал подобное.
Как мне кажется, вы еще не знаете, о чем идет речь, но уже выносите суждение.
Где я такое писал? Дайте пожалуйста ссылку или цитату.
Про это рассказывали на октябрьском семинаре.
Конфигурация предоставляется в исходных кодах. Есть «Замер производительности» в Конфигураторе, есть КИП — можно выявить узкие места, поменять исходный код и свойства объектов конфигурации.
Спасибо, теперь понял, о чем речь.
Да, такое поведение платформы исправили в 8.2 (если не ошибаюсь — 8.2.14, «Запрос, содержащий оператор В с множественными операндами, в подзапросе которого есть упорядочивание, может быть исполнен, если из подзапроса нет обращений к полям внешнего запроса.», есть в V8Update.htm). Исправление было сделано в рамках унификации работы с СУБД, т.к. предыдущее поведение не работало на всех СУБД.
Ваш запрос можно модифицировать так, чтобы он заработал на 8.2:
Сделал, посмотрел. Все 10 страниц читать не стал, пробежал первые три. Часть пожеланий реализована в Enterprise Development Tools (но тут придется подождать его готовности). Были пожелания ускорить работу с хранилищем конфигураций — работаем в этом направлении, почти каждую версию платформы есть доработки в этом направлении.
Надеюсь, не будете обвинять нас в том, что мы не реализовали ВСЕ пожелания из опроса?
А есть потребность в конфигурациях такого масштаба? Можете привести пример? Я серьезно, вопрос не праздный.
Давайте посмотрим шире — в мире вообще мало случаев, когда на аналогичных платформах партнерами (а не самими производителями платформы) создавались решения масштабов ERP. И не потому что платформы плохи, а потому что это а) долго и дорого, может себе позволить только крупная компания и б) как правило такое/похожее по функциональности решение уже сделал производитель платформы, и проще доработать его, чем писать своё.
Почему так считаете? Мы переносим в расширения все больше и больше объектов. Уже видел случаи переноса внедренцами части модификаций на местах в расширения с целью облегчить переход на новые версии. Что может помешать использовать расширения внедренцам? Пока — малое количество объектов, поддерживаемых расширениями. Но их будет все больше. Так что проблем не вижу. Если их видите вы — опишите пожалуйста.
У меня есть некоторый опыт написания платформ для нескольких ERP (не связанный с 1С). Могу сказать по своему опыту — введение такой «полуподдерживаемой» функциональности в платформу через пару версий их активного использования прикладными разработчиками приводит к проблемам в поддержке и развитии платформы, которые сводят на ноль все преимущества этой функциональности. Это даже если платформа не публичная и ее используют только прикладные программисты внутри компании. Если же платформа публичная, как у 1С — количество неприятностей можно смело возводить в квадрат (а то и в куб).
Можете написать такой запрос для демо-базы, который работает на 8.1 и не работает на 8.3?
Мне действительно интересен этот вопрос — «отваливают» функциональность довольно редко, хотелось бы разобраться.
О каком вопросе речь, напомните пожалуйста. Возможно я не в курсе.
Ну и надо помнить что год — не то чтобы очень большой срок для софтверного проекта в миллионы строк кода.