Вход | Регистрация

Форумы на Кубань.Ру


1С:Предприятие ::

Метки:

Ретроспективная теория (Секрет Бориса Нуралиева)

Ø
Я
   Mazzy
08.10.00 - 16:59
Введем условных действующих лиц: Постановщик задачи, Программист движка, Программист типовой. Вполне возможно, что в физическом мире эти роли выполняли много людей. Вполне возможно, что некоторые люди выступали в нескольких ролях.
.
Начать ретроспективный анализ хотелось бы с перечисления того, чего не было в начале развития v7:
группа А
= модульности (в смысле OBJ, TPU, DPU, LIB, и сейчас нет)
= не было понятия времени (и сейчас нет)
= у периодических реквизитов не было метки времени
= не было встроенного универсального отчета по регистрам
= не было полей, которые сейчас называются "реквизиты" регистров
= крайне бедный язык запросов (да и сейчас язык запросов сильно проигрывает SQL)
группа Б
= не было границы последовательности
= не было событийного управления (были основные события ВводНового, ПриПроведенииДокумента, но без них действительно нельзя. Но не было и нет события похожих на GetFocus, LostFocus и т.п)
= слабый механизм управления формами (Методы Видимость, Доступность появились позже)
= не было механизма косвенного обращения к данным (впоследствии extender, объект Метаданные)
= не было прямого обращения к DBF
.
Теперь попробую перечислить то, что есть но так и не используется в v7 (или остается непонятным зачем это изобрели)
группа А
= язык запросов (когда есть прямые методы доступа к итогам)
= многоуровневые секции в таблице и суффиксы "",">" в названиях секций таблицы
= связь запросов и модуля обработки запроса. Я имею в виду свойство позиционирования на итогах запроса, когда перед началом цикла и после цикла запрос указывает на сумму по данному циклу. Такая фича наверняка отняла немало сил у программиста движка.
= кубическое представление регистра в итогах
группа Б
= ТА
= обработка нажатия ячейки (это при отсутствии остальных событий!)
.
Все мои дальнейшие рассуждения носят спекуляционный характер. Я НЕ ЗНАЮ как происходили события на самом. Этот текст - попытка воссоздать исходные спецификации на v7, попытка понять что задумывалось и как реализовано. Надеюсь, что это поможет понять настоящее и будущее v7.
 
  Рекламное место пустует
   Mazzy
1 - 08.10.00 - 17:00
Прежде всего v7 задумывалась и создавалась на гребне успеха 6.0. 1С уже была известной торговой маркой. Существовало большое количество клиентов 1С, которые успешно пользовались шестеркой. В шестерке были недостатки, но реально изменений в идеологии не требовалось. Кроме того, известны продукты сторонних разработчиков, которые показали, что шестерка вполне масштабируема и могла быть развита. Не думаю, что Постановщик задумывал нечто революционное, скорее задумывалось развитие/дополнение шестерки, новый виток эволюции.
.
Думаю, что вместо того, что сейчас называется "оперативный учет" задумывался инструмент ФИНАНСОВОГО АНАЛИЗА (по типу сегодняшних OLAP-клиентов) с АВТОМАТИЧЕСКОЙ ГЕНЕРАЦИЕЙ ОТЧЕТОВ по запросу пользователя.
.
Доводы со стороны Проектировщика:
.
При финансовом анализе время не является необходимым, оно избыточно, если бы проектировался оперативный учет, то оно было бы необходимо.
.
Инструмент финансового анализа являлся бы прекрасным маркетинговым дополнением к системе бухгалтерского учета. такую связку было бы легко продавать.
.
Доводы со стороны программиста движка:
.
Регистры должны были быть простыми и генерироваться пользователем или администратором. Сейчас в олап-клиентах это кубы.
.
Думаю, что отчеты по регистрам в задумке должны были строится автоматически мастером-генератором-отчетов. Этот мастер пользовался бы запросами и использовал тот факт, что по запросам легко строятся алгоритмы печати, и запрос позиционируется на итоги перед циклом и после цикла. Мастер-генератор-отчетов делает ненужным встроенный отчет по регистрам.
.
Думаю, что задумывался полноценный генератор отчетов с секциями. Это объясняет присутствие префиксов "", ">". В ручных отчетах эти префиксы недостаточны. Попробуйте сделать две внутренние секции :-). Но если отчет генерируется автоматически, то система может контролировать, чтобы секции были правильно вложены.
.
Запросы задумывались как упрощение SQL - select'ов. Действительно, по кубу, который не имеет ссылок на другие кубы, достаточно SELECT'а без JOIN.
.
Событие обработки нажатия ячейки позволяет реализовать DrillDown анализ. Бухгалтерия и ее самодетализирующиеся отчеты - частный случай DrillDown.
.
И т.д. и т.д. Пока все происходящее только убеждает меня в том, что задумывался инструмент анализа.
.
Что же произошло? Почему произошло изменение замысла и мы видим некрасиво скоренную 1С:Торговлю с непонятным предназначением? Почему 1С:Торговля настолько дублирует 1С:Бухгалтерию, что вопрос о том "что" и "как" выбрать входит во все FAQ'и?
.
Думаю, что дело в цепочке "Проектировщик"-"Программист движка"-"Программист типовой". Произошла классическая потеря замысла в проекте. Известно, что 7.0 1С решила сначала обкатать у себя.
.
Для того, чтобы обкатать инструмент анализа, его надо наполнить данными. Как наполнить данными 7.0? Импортировать из 6.0? Почему то было принято решение реализовать систему ввода данных также на 7.0 (это, пожалуй, единственный момент который теория не может объяснить). Но 7.0 не задумывалась как платформа для регистрации проводок/действий/транзацкий, ей не хватало многих механизмов. Прежде всего ей не хватало запроса по нескольким регистрам.
.
Предполагаю, что тогда запрос выглядел следующим образом
РЕГИСТР=Остатки;
// секции переменных не было поскольку объявление регистра вводило переменные
// в частности, регистр Остатки содержит ресурс Кол
УСЛОВИЕ (...);
ФУНКЦИЯ (Ост = Сумма(Кол));
ФУНКЦИЯ (МинОст = Мин(Кол));
.
Просто? ДА
Доступно? ДА
Такой запрос легко генерируется автоматически? ДА
И задумано красиво.
Но для ведения оперативного учета не хватает JOIN секции
.
Видимо тогда и было принято программистами движка катастрофическое решение о секции переменных, в которых определения могли бы идти через запятую. Теперь запрос мог содержать
Товар=регистр.Остатки.Товар,регистр.резервы.Товар;
Кол=регистр.Остатки.Кол,регистр.резервы.Кол;
Кол1=регистр.Остатки.Кол;
Кол2=регистр.резервы.Кол;
ФУНКЦИЯ (Ост = Сумма(Кол));
ФУНКЦИЯ (МинОст = Мин(Кол));
.
Просто? Уже не очень. Что должна была означать эта запись? Что будет если остаток по товару есть, но этот товар ни разу не резервировался? Что будет если товар есть в резерве, но нет в остатках? Что будет в переменных Кол1, Кол2?
МинОст = мин(мин(все Остатки.Кол),мин(все Резервы.Кол))?
МинОст = мин(все Остатки.Кол,все Резервы.Кол)?
МинОст = мин(все (Остатки.Кол+Резервы.Кол))?
Что будет если рекивзиты выбираются не только из регистра, но и из документа, бухгалтерских итогов, справочника? И каков смысл полученных данных?
.
Самое интересное, что сами программисты движка тоже не знали четкого ответа на этот вопрос. От релиза к релизу поведение запроса менялось.
.
Как такой запрос отображается в SQL или xBase запрос? Особенно для поля Кол? Вы могли бы представить блок-схему такого запроса к данным? Думаете программисты движка могут дать блок-схему преобразования запроса 1С в запросы к данным? Мне хотелось бы надеятся, что могут.
   Mazzy
2 - 08.10.00 - 17:01
Следующее понятие, которое сильно повлияло на развитие 1С - это понятие точки актуальности (ТА). Сколько я ни старался, я не могу воссоздать рассуждения человека, который придумал и реализовал настолько бредовое понятие. С одной стороны, финансовому анализу такое понятие не нужно. С другой стороны, такое понятие вносит крайнюю путаницу, если делать систему оперативного учета.
.
ТА - момент времени, на который актуальны итоги! Но ведь задумывалась сетевая система. Программист обязан был понимать, что проведение - это процесс. И пока идет проведение одного документа второй может начать и закончить свое проведение. В этом случае что такое ТОЧКА актуальности? Или программисты как только ввели это понятие, так и решили сделать проведение МОНОПОЛЬНЫМ? Тогда они должны были понимать, что на момент проведения им придется блокировать ВСЕ связанные с проведение данные? Тогда какая же это сетевая система?
.
Далее возникает вопрос о проведении документа до ТА.
Док1 - проводится в t1, время документа t1
Док2 - проводится в t2, время документа t0
t0 < t1 < t2
С момента t1 ТА находится в t1. Но до момента t2 не все документы проведены. Значит ли это, что с момента t1 до t2 данные в ТА не актуальны? Должна ли ТА установится на t2?
.
ТА позиционируется с точностью до долей секунды. НО в 1С нет понятия времени. Как будет устанавливаться ТА программистом?
.
Все эти вопросы возникают стоит только немного подумать о сути ТА. Более запутанного и непродуманного понятия - в жизни не видел.
.
Как следствия этого понятия появилась последовательность и граница последовательности... Они мало проясняют исходное понятие, сами являются крайне запутанными и бредовыми, но хоть делают использовние ТА чуть более легким. 1Су пришлось мужественно и храбро решать проблему с ТА. Они почти это сделали. Осталось решить проблемы с последовательностями.
.
Надо сказать, что западные программы обходятся без понятия ТА. Но там они решают эту проблему запретом редактирования уже введенных документов. 1С решили не запрещать. Молодцы! Но претензия к ним одна - почему ж не подумали о последствиях?
.
Следующий очень спорный шаг, сделанный программистами движка - включение трехбуквенного ID базы в ID объекта. Такое изменение появилось для УРБД. В результате они получили НЕНОРМАЛИЗОВАННУЮ реляционную таблицу. Причем нет нормализации даже первого уровня. Но это еще не все, ненормализованным сделано поле, по которому строится ключевой индекс. Также как и с запросами, я не могу объяснить логику этого шага. Для 6.0 хоть как-то могу объяснить потерю нормализации, для v7 - нет.
.
В 1С есть на тот момент передовая технология - поддержка OLE automation. Насколько я знаю, 1С было сделано впервые среди российских коммерческих программ. По крайней мере, наверняка они были одними из первых. И вроде все хорошо. НО передача перечислений через ОЛЕ была невозможна пока не появился объект метаданные. А он появился только в 7.7. Спрашивается когда вводилась эта фича программисты движка могли подумать об этом? Почему не подумали?
.
Примеры и обоснования можно приводить бесконечно. Но хотелось бы закончить этот анализ. На мой взгляд, то что мы сейчас назывем "1С:Оперативный учет" должно было бы быть инструментом анализа с мощным генератором отчетов по типу Cristal Report и сводных отчетов (Pivot Table) по типу Brio, может быть Excel. Со временем, на платформе v7 должна была появится Бухгалтерия и Расчет.
.
Сейчас мы имеем одну платформу. НО компоненты Бухгалтерия и Оперативный учет во многом дублируют друг друга. Все три компоненты настолько не интегрированы друг, что выпуск комплексной вызывает трудности дажу у самой 1С.
.
Разработка 1С является классическим примером того, как НЕ НАДО вести разработку. (все помнят картинку с качелями на дереве - задумано, запроектировано, реализовано, отлажено?) Продажи 1С являются классическим примером того, как НАДО вести маркетинг.
.
В заключение, хотелось бы пожелать успехов и 1Су, и тому, кто будет в будущем конкурировать с ней. Надеюсь, что программисты 1С смогут смогут найти решение своих проблем. Тем более что задачи и методы, которые провозглашаются 1Сом мне нравятся. Реализация вот убогая.
.
Будем надеятся на лучшее. И сами не плошать. :-)
Мазуркин Сергей
   Игорь
3 - 09.10.00 - 08:03
Интересно знать , как много информации можно
получить от сотрудников Раруса
под пытками. Добровольно они колются редко, но интересно.



Список тем форума

Форум Территория 1С

Рекламное место пустует  
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.
Ветка сдана в архив. Добавление сообщений невозможно.
Но вы можете создать новую ветку и вам обязательно ответят!
Каждый час на Волшебном форуме бывает более 2000 человек.
Рекламное место пустует