Вы в очередной раз решили озвучить любимую мантру всех 1С-офобов. На предложение аргументировать свою позицию слились и тут же попытались провести экзамен вашего оппонента по неизвестному предмету по правилам, которые вы сами тут же придумываете.
Нет уважаемый, так не пойдет. Более того, на приведенные вами аргументы (коии вдруг будут приведены, во что я не верю) я вам аргументированно возразить вряд-ли смогу по причине того, что не являюсь специалистом по каким-то прикладным продуктам, я являюсь специалистом по платформе. Но понимание уровня оппонента всегда полезно и познавательно, т.к. аргументированная критика очень интересна и полезна.
Предлагаю развернуто аргументировать данное заявление. К сожалению сейчас это выглядит слегка… поверхностно. Только просьба сразу разделить объективные факты от ваших субъективных оценок. Заодно хочется услышать названия продуктов, к которым применяется ваша аргументация. И просьба воздержаться от заявлений вида «всем известно, что в любой конфигурации 1С».
Был такой продукт 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 (про это и так понятно) :(
Речь про остальное. Оценивается свежая относительно версия документации, которая сейчас на ИТС.
Отсутствие нормальной документации существенно увеличивает затраты на поддержку. Кроме того, становится непонятно, откуда консультанты и интеграторы получат знания, на которых они будут зарабатывать деньги. Это ведь не тайные заклинания, которые передаются из уст в уста от отца сыну. Консультантов много, да и просто пользователей немало.