Был такой продукт Borland Deplhi (Borland C++, семейство Builder, Microsoft Quick C и т.д) — средство разработки (как и много других аналогичных продуктов). Если смотреть на «1С: Предприятие», то инструменты разработки входят в состав продуктов (прикладных решений) «Управление торговли», «Бухгалтерия» и т.д. и могут приобретаться отдельно (технологическая поставка). Если вам не нравятся типовые программные продукты фирмы «1С» (или партнеров) — вы можете разработать собственный продукт и продавать его, вместе со своей уникальной и совершенной методикой. Также вы можете разрабатывать тиражные расширения существующих типовых решений — это тоже возможно.
Это реальные факты. Вы можете воспринимать эту действительность как угодно, в том числе и так, как вы сейчас ее воспринимаете. Действительность от этого другой не станет.
Но все-таки в первую очередь я хочу понять, какую ключевую мысль вы пытаетесь донести до читателей? Пока эта мысль ускользает.
Это не стандартные слова, а фактическое состояние вещей. Более того, аналогичные слова можно сказать про любую систему автоматизации чего угодно. Особенно, если есть желание эту систему выставить в неприглядном для клиента виде.
Более того, я практически уверен, что вы можете привести развернутые и аргументированные тезисы в защиту своих слов, но это оффтопик (в данной теме) :)
Очевидно, что чудес не бывает и любой продукт любое прикладное решение на платформе «1С: Предприятие» не является идеальным, а также удовлетворяющим всем запросам всех пользователей. Что не мешает этим прикладным решениям развиваться, в том числе и по запросам пользователей этих продуктов.
Осталось только понять, как в этом виновата платформа :)
Есть платформа для разработки прикладных решений и есть программные продукты, написанные на этой платформе. Второе не может существовать без первого, но это, все-таки разные продукты, которые развиваются по своим планам и законам.
Люди покупают не платформу для разработки, а продукт, который им нужен. Что они с ним будут делать — это отдельный вопрос. Они могут сами (или с чьей-то помощью) доработать продукт под себя. Могут пользоваться таким, как он есть, доработать себя под продукт.
При этом клиент может понимать, что он хочет, а может — не понимать. Результат зависит от квалификации как клиента, так и франчайзи. Иногда клиент сам виноват в том, что годами изобретается велосипед, иногда не виноват, а такое изобретательство ему предлагается франчайзи или собственным отделом разработки, которому надо доказать свою нужность (например).
Адекватность моделей, заложенных в прикладные решения, реальной жизни, как мне кажется, для данной статьи является полным оффтопиком, т.к. статья не об этом. Да, у пользователей и внедренцев всегда есть «обида» на прикладное решение, которое не имеет реализации какого-то отличного механизма или процесса. Но «статью про 1С для людей, с 1С незнакомых, статью, которая показывает, какое место 1С занимает в ряду аналогичных программных продуктов.»
Начнем с конца :) Извините, получится много буков :)
Я, конечно, очень давно читал и Ричи и Страуструпа, но что-то не припомню, чтобы эти уважаемые господа описывали в своих книгах стандартную библиотеку языка Си. Описывался только язык и минимум «обвеса», чтобы показать, как язык функционирует. А вот описание используемой стандартной библиотеки (фреймворка) — это слегка отдельные мануалы.
Возвращаясь к платформе. Здесь есть достаточно четкое разделение документации на две части: это описание механизмов, их устройства, типовых применений и особенностей, и описание собственно фреймворка 1С: Предприятия. Первое — это то, что называется «Руководствами ...» и выходит отдельными книгами. Второе — это синтакс-помощник и живет «внутри» любого конфигуратора. При этом руководства не ставят своей целью исчерпывающе описать весь фреймворк, т.к. это не кажется нужным. Например не видно особого смысла описывать ТекстовыйДокумент в объеме, превышающем то, что есть в СП. Там нет каких-то «интимных» подробностей, которые нужны для понимания работы механизма. При этом очевидно, что программная работа с документами офисных пакетов не имеет вообще никакого отношения к собственно платформе «1С: Предприятие». Ведь вы же не считаете, что нам в документацию надо включить примеры работы с OpenXML (касаемо документов Ворда, например) в объеме, достаточном для понимания этого адского языка?
В тоже время, описания [относительно] сложных механизмов, начиная с каждого «класса» объектов и заканчивая такими монстрами, как разделение данных, приводится в документации именно в варианте, пригодном для изучения: для чего этот механизм, как он устроен, как его применять. Разные разделы имеют разную детальность, т.к. документация развивается примерно с версии платформы 8.0 (сейчас 8.3) и «старые» разделы могут существенно не модернизироваться (без существенной нужды). При этом при развитии тех или иных механизмов, документация к ним переписывается и развивается. Изменяется и сам подход к наполнению и формированию документации. Так, в прежних версиях платформы, документация была достаточно статичной, но «в помощь» к ней на ИТС публиковались различные методические статьи, которые, по сути, дополняли документацию. Начиная с 8.2 документация перестала быть статичной и стала развиваться вместе с платформой, изменяясь и совершенствуясь вместе с ней. Если к 8.2.19 руководство разработчика занимало примерно 1400 страниц (формат А5), в 8.3.5 это уже примерно 1800 страниц, а в 8.3.7 — это примерно 2100 страниц.
Все вышесказанное не означает, что объем, качество и стиль документации мы считаем абсолютно нормальным и не требующим доработки и совершенствования. Такая работа постоянно идет, причем она идет не только из-за того, что меняются механизмы платформы, но и потому, что партнеры, использующие платформу, сообщают о каких-то проблемах в документировании механизмов. К таким изменениями можно отнести и изменения файла со списком изменений (что можно считать третьей частью документации) и появление в документации новых разделов.
Теперь касаемо изначального вопроса про язык запросов. Пожалуйста: Глава 8. Работа с запросами (нужен логин/пароль на ИТС или можно открыть себе демо-доступ на 2 недели на самом сайте). Это именно гайд по запросам. С описанием языка, синтаксиса, примеров (не факт, что очень подробными, это да).
Подытожу в качестве резюме: документация — это не застывшая конструкция и она состоит из нескольких частей, дополняющих другу друга. Мы не считаем, что документация является идеальной и постоянно работаем над ее улучшением. Нам, безусловно, важно понимать, какие места в документации являются проблемными и понимать, как и куда их надо улучшать, однако, мы хотим (уж извините) видеть конкретные проблемы, а не общие слова «как все плохо».
Как-то так :)
Т.е. работу (например) с push-уведомлениями в мобильной платформе надо изучать полностью самостоятельно, по наитию? Описание планировщика (который новый объект для этой платформы) — оно тоже методом научного тыка осваивается?
Я уже задавал вопрос, повторю еще раз — можете привести конкретные примеры плохой документации к платформе (кроме СКД и XDTO) и того, чего вам в ней не хватает?
Я знаю, что и где у нас лежит :)
Но ведь эта ссылка противоречит утверждению о том, что мы стараемся не писать нормальных гайдов? Или речь о чем-то другом?
Хорошо. Давайте рассмотрим пример: выходит платформа 8.3.6 (всего там 153 изменения). Здесь и далее я говорю только о платформе, прикладные решения буду игнорировать, т.к. что-то знаю только о платформенной документации.
Откуда вы узнаете, что нового в этой платформе?
А подробности откуда узнаете? Т.е. вот все эти новости вы узнаете пытливо тыкаясь в разные места платформы и составляя персональный список отличий?
А вот теперь консультант, он откуда узнал про новые возможности? Для определенности — консультант консультирует по особенностям применения платформы, его клиент — компания с инхаусной разработкой (уровень неважен).
И еще — говоря о корпоративном рынке, мы говорим о чем? О внедрении [относительно] типового продукта (с подходящей и соответствующей функциональностью) или заказной разработке?
А что не хватает в текущей документации?
Не надо говорить про СКД и XDTO (про это и так понятно) :(
Речь про остальное. Оценивается свежая относительно версия документации, которая сейчас на ИТС.
Это достаточно распространенное заблуждение.
Отсутствие нормальной документации существенно увеличивает затраты на поддержку. Кроме того, становится непонятно, откуда консультанты и интеграторы получат знания, на которых они будут зарабатывать деньги. Это ведь не тайные заклинания, которые передаются из уст в уста от отца сыну. Консультантов много, да и просто пользователей немало.
Это реальные факты. Вы можете воспринимать эту действительность как угодно, в том числе и так, как вы сейчас ее воспринимаете. Действительность от этого другой не станет.
Но все-таки в первую очередь я хочу понять, какую ключевую мысль вы пытаетесь донести до читателей? Пока эта мысль ускользает.
Более того, я практически уверен, что вы можете привести развернутые и аргументированные тезисы в защиту своих слов, но это оффтопик (в данной теме) :)
Очевидно, что чудес не бывает и
любой продуктлюбое прикладное решение на платформе «1С: Предприятие» не является идеальным, а также удовлетворяющим всем запросам всех пользователей. Что не мешает этим прикладным решениям развиваться, в том числе и по запросам пользователей этих продуктов.Осталось только понять, как в этом виновата платформа :)
Люди покупают не платформу для разработки, а продукт, который им нужен. Что они с ним будут делать — это отдельный вопрос. Они могут сами (или с чьей-то помощью) доработать продукт под себя. Могут пользоваться таким, как он есть, доработать себя под продукт.
При этом клиент может понимать, что он хочет, а может — не понимать. Результат зависит от квалификации как клиента, так и франчайзи. Иногда клиент сам виноват в том, что годами изобретается велосипед, иногда не виноват, а такое изобретательство ему предлагается франчайзи или собственным отделом разработки, которому надо доказать свою нужность (например).
Адекватность моделей, заложенных в прикладные решения, реальной жизни, как мне кажется, для данной статьи является полным оффтопиком, т.к. статья не об этом. Да, у пользователей и внедренцев всегда есть «обида» на прикладное решение, которое не имеет реализации какого-то отличного механизма или процесса. Но «статью про 1С для людей, с 1С незнакомых, статью, которая показывает, какое место 1С занимает в ряду аналогичных программных продуктов.»
Я, конечно, очень давно читал и Ричи и Страуструпа, но что-то не припомню, чтобы эти уважаемые господа описывали в своих книгах стандартную библиотеку языка Си. Описывался только язык и минимум «обвеса», чтобы показать, как язык функционирует. А вот описание используемой стандартной библиотеки (фреймворка) — это слегка отдельные мануалы.
Возвращаясь к платформе. Здесь есть достаточно четкое разделение документации на две части: это описание механизмов, их устройства, типовых применений и особенностей, и описание собственно фреймворка 1С: Предприятия. Первое — это то, что называется «Руководствами ...» и выходит отдельными книгами. Второе — это синтакс-помощник и живет «внутри» любого конфигуратора. При этом руководства не ставят своей целью исчерпывающе описать весь фреймворк, т.к. это не кажется нужным. Например не видно особого смысла описывать ТекстовыйДокумент в объеме, превышающем то, что есть в СП. Там нет каких-то «интимных» подробностей, которые нужны для понимания работы механизма. При этом очевидно, что программная работа с документами офисных пакетов не имеет вообще никакого отношения к собственно платформе «1С: Предприятие». Ведь вы же не считаете, что нам в документацию надо включить примеры работы с OpenXML (касаемо документов Ворда, например) в объеме, достаточном для понимания этого адского языка?
В тоже время, описания [относительно] сложных механизмов, начиная с каждого «класса» объектов и заканчивая такими монстрами, как разделение данных, приводится в документации именно в варианте, пригодном для изучения: для чего этот механизм, как он устроен, как его применять. Разные разделы имеют разную детальность, т.к. документация развивается примерно с версии платформы 8.0 (сейчас 8.3) и «старые» разделы могут существенно не модернизироваться (без существенной нужды). При этом при развитии тех или иных механизмов, документация к ним переписывается и развивается. Изменяется и сам подход к наполнению и формированию документации. Так, в прежних версиях платформы, документация была достаточно статичной, но «в помощь» к ней на ИТС публиковались различные методические статьи, которые, по сути, дополняли документацию. Начиная с 8.2 документация перестала быть статичной и стала развиваться вместе с платформой, изменяясь и совершенствуясь вместе с ней. Если к 8.2.19 руководство разработчика занимало примерно 1400 страниц (формат А5), в 8.3.5 это уже примерно 1800 страниц, а в 8.3.7 — это примерно 2100 страниц.
Все вышесказанное не означает, что объем, качество и стиль документации мы считаем абсолютно нормальным и не требующим доработки и совершенствования. Такая работа постоянно идет, причем она идет не только из-за того, что меняются механизмы платформы, но и потому, что партнеры, использующие платформу, сообщают о каких-то проблемах в документировании механизмов. К таким изменениями можно отнести и изменения файла со списком изменений (что можно считать третьей частью документации) и появление в документации новых разделов.
Теперь касаемо изначального вопроса про язык запросов. Пожалуйста: Глава 8. Работа с запросами (нужен логин/пароль на ИТС или можно открыть себе демо-доступ на 2 недели на самом сайте). Это именно гайд по запросам. С описанием языка, синтаксиса, примеров (не факт, что очень подробными, это да).
Подытожу в качестве резюме: документация — это не застывшая конструкция и она состоит из нескольких частей, дополняющих другу друга. Мы не считаем, что документация является идеальной и постоянно работаем над ее улучшением. Нам, безусловно, важно понимать, какие места в документации являются проблемными и понимать, как и куда их надо улучшать, однако, мы хотим (уж извините) видеть конкретные проблемы, а не общие слова «как все плохо».
Как-то так :)
Лично знаю минимум двух людей, которые имеют вполне неплохие скиллы (на мой взгляд) и в 1С и в САПе :)
Это надо воспринимать именно как характеристику нормальной документированности?
Странно получается…
Я уже задавал вопрос, повторю еще раз — можете привести конкретные примеры плохой документации к платформе (кроме СКД и XDTO) и того, чего вам в ней не хватает?
Но ведь эта ссылка противоречит утверждению о том, что мы стараемся не писать нормальных гайдов? Или речь о чем-то другом?
Откуда вы узнаете, что нового в этой платформе?
А подробности откуда узнаете? Т.е. вот все эти новости вы узнаете пытливо тыкаясь в разные места платформы и составляя персональный список отличий?
А вот теперь консультант, он откуда узнал про новые возможности? Для определенности — консультант консультирует по особенностям применения платформы, его клиент — компания с инхаусной разработкой (уровень неважен).
И еще — говоря о корпоративном рынке, мы говорим о чем? О внедрении [относительно] типового продукта (с подходящей и соответствующей функциональностью) или заказной разработке?
Не надо говорить про СКД и XDTO (про это и так понятно) :(
Речь про остальное. Оценивается свежая относительно версия документации, которая сейчас на ИТС.
Отсутствие нормальной документации существенно увеличивает затраты на поддержку. Кроме того, становится непонятно, откуда консультанты и интеграторы получат знания, на которых они будут зарабатывать деньги. Это ведь не тайные заклинания, которые передаются из уст в уста от отца сыну. Консультантов много, да и просто пользователей немало.