|
17.12.2010, 11:05 | #1 |
Участник
|
позволю себе аргументированно вам возразить (очередное сравнение с 1С)
**** выделено отсюда Промежуточные итоги 1С ****
Цитата:
Цитата:
Цитата:
А по поводу ООП... Если вы адепт этого подхода, то вас наверняка уже задолбали фанаты хаскела, скалы и прочей функциональщины, разве нет? Если у вас есть минутка, ответьте мне, как специалист, какие принципы ООП наиболее часто применяются вами на практике? Какие при этом с помощью этих принципов проблемы решаются? Архитектура "клиент-сервер", взаимодействие с СУБД через ORM-слой, декларативный язык запросов, декларативная система описания отчетов (СКД) - разве это не примеры использования в 1С "методик, наработанных за десятиления в области инженерии ПО"? А встроенные открытые средства интеграции с другими приложениями, поддержка открытых протоколов XDTO, SOAP? Средства сериализации в XML? COM? Кросс-платформенный NativeAPI для разработки внешних компонент? Или я не правильно вас понял и вы имеете в виду что-то другое? Цитата:
Наводящий на понимание моей мысли вопрос (отвечать не обязательно): вы уверены, что тот же самый специалист, который наделал костылей в 1С, переориентировавшись внедрять Ax, вдруг изменит себе и начнет разбираться, как там все устроено, чтобы внедрить типовой функционал? Возможно, вы имели в виду то, что среди специалистов 1С такое можно чаще такую ситуацию встретить. Но, мне кажется, причина эта уже давно не в том, что 1С:Предприятие - платформа не уровня "enterprice", что решения на 1С - "не тянут", а в том, что платформа шагнула на следующий уровень, а толпа специалистов, внедряющих "доступно и всерьез" пока еще не сделала этот шаг. По крайней мере, большая ее составляющая, с которой мы все знакомы по mista.ru, infostart.ru и пр. Да, это показательно, и именно это, по моему мнению, главная проблема и фирмы 1С и профессионального сообщества 1С, а уж никак не технологическая отсталость платформы 1С:Предприятия 8.2 относительно других платформ.
__________________
С уважением, Александр Кунташов |
|
17.12.2010, 12:00 | #2 |
Участник
|
Цитата:
некорректно использовать, если число отличается на проценты. потому что: информацию хоть так, хоть эдак, но хранить где-то надо. число сущностей-хранилищ дает грубую оценку числа информации. Цитата:
Это феномен 1Сников. Из-за которого типичного 1Сника нужно обучать на полгода дольше. Люди, пришедшие из других систем, как правило начинают сначала разбираться. Цитата:
Сообщение от kuntashov
Но, мне кажется, причина эта уже давно не в том, что 1С:Предприятие - платформа не уровня "enterprice", что решения на 1С - "не тянут", а в том, что платформа шагнула на следующий уровень, а толпа специалистов, внедряющих "доступно и всерьез" пока еще не сделала этот шаг. По крайней мере, большая ее составляющая, с которой мы все знакомы по mista.ru, infostart.ru и пр.
люди смотрят как написаны типовые конфы. люди берут оттуда паттерны и используют их. чтобы изменить людей нужно изменить типовые конфы. то же самое относится и к аксапте с навижином, в которых некоторые места в коде (особенно в локализациях) являются антипаттернами. Цитата:
технологическая отсталось - врожденное качество платформы 1С. (точно такое же как врожденные характеристики франчайзинга) технологическая отсталось обусловлена ориентацией на "собственные силы", на подчеркнутую "самобытность" и несовместимость с общими ИТ-стандартами. свой data mining, свой olap, свой интерфейс, свой формат базы данных, свой sql, свой язык запросов, своя система отчетов, своя картографическая система, свой workflow, свой веб и т.п. Да, они увернулись от гонки http://russian.joelonsoftware.com/Ar...AndMotion.html да, сейчас 1С напряглась и рванула. но передовые технологии нужно поддерживать. изо дня в день. достаточно вспомнить тот же САП. они придумали свой интерфейс лет 15 назад. Тогда это казалось таким замечательным прорывом. Сейчас это выглядит так архаично. |
|
|
За это сообщение автора поблагодарили: kuntashov (1). |
17.12.2010, 12:37 | #3 |
Участник
|
Цитата:
Это феномен 1Сников. Из-за которого типичного 1Сника нужно обучать на полгода дольше. Люди, пришедшие из других систем, как правило начинают сначала разбираться.
Но я все же склонен считать, что дело не в системе, а в том, что низкий порог вхождения в "специальность" (программирование 1С) привело к этому "феномену". Цитата:
несовместимость с общими ИТ-стандартами
__________________
С уважением, Александр Кунташов |
|
17.12.2010, 13:07 | #4 |
Участник
|
Цитата:
Цитата:
Сообщение от mazzy
технологическая отсталось обусловлена ориентацией на "собственные силы", на подчеркнутую "самобытность" и несовместимость с общими ИТ-стандартами.
свой data mining, свой olap, свой интерфейс, свой формат базы данных, свой sql, свой язык запросов, своя система отчетов, своя картографическая система, свой workflow, свой веб и т.п. |
|
17.12.2010, 14:33 | #5 |
Administrator
|
Дык ж... приведены:
Цитата:
А смысл в том, что есть конкретный продукт (язык SQL в частности или OLAP-продукт), который принят де-факто за стандарт обработки данных в БД (это про язык SQL). Есть OLAP-продукты (и это совершенно не обязательно SQL Server Analysis Services). И если бы 1С не пыталась бы все это заменить на нечто свое, а пыталась бы использовать существующие технологии - она бы гораздо дальше шагнула бы вперед по технологиям. Та же MS не создавала Reporting Services, не создавала SQL Server, не создавала Dynamics AX, NAV. Она все это купила. Просто финансовые возможности 1С несравнимы с MS и она не может себе позволить купить технологии, поэтому нужно давать возможности для интеграции. Например, смогла же 1С использовать "движок" от Excel для своих отчетов. Это кстати - одно из сильных ее преимуществ. А если бы они писали бы что-то свое и сваяли бы что-то а-ля отчеты в АХ - то они бы не получили этого преимущества, как не получила АХ (из-за чего кстати и затеялась вся эта интеграция с Reporting Services и т.д.)
__________________
Возможно сделать все. Вопрос времени Последний раз редактировалось sukhanchik; 17.12.2010 в 14:37. |
|
17.12.2010, 15:26 | #6 |
Участник
|
Не очень понятно, в каком месте 1С использует "движок" Excel? Если речь идет о табличных документах 1С, т.е. "мокселях" (mxl), то это не так.
__________________
С уважением, Александр Кунташов |
|
17.12.2010, 15:38 | #7 |
Administrator
|
Цитата:
__________________
Возможно сделать все. Вопрос времени |
|
17.12.2010, 16:23 | #8 |
Участник
|
Я заметил, что хорошо бы привести корректные числа.
Цитата:
Сообщение от sukhanchik
Тут смысл не в том, что Dynamics смотрит на технологии своего же производителя и это есть хорошо, а в случае с 1С-ом, который смотрит на свои технологии - плохо.
А смысл в том, что есть конкретный продукт (язык SQL в частности или OLAP-продукт), который принят де-факто за стандарт обработки данных в БД (это про язык SQL). Есть OLAP-продукты (и это совершенно не обязательно SQL Server Analysis Services). И если бы 1С не пыталась бы все это заменить на нечто свое, а пыталась бы использовать существующие технологии - она бы гораздо дальше шагнула бы вперед по технологиям. Та же MS не создавала Reporting Services, не создавала SQL Server, не создавала Dynamics AX, NAV. Она все это купила. Просто финансовые возможности 1С несравнимы с MS и она не может себе позволить купить технологии, поэтому нужно давать возможности для интеграции. ReportService вместо CristalReport, Silvelight вместо Flash и HTML 5, свой сбственный стандарт офисных документов и так далее. Язык запросов в Axapta тоже отличается от стандарта. Цитата:
Сообщение от sukhanchik
Например, смогла же 1С использовать "движок" от Excel для своих отчетов. Это кстати - одно из сильных ее преимуществ. А если бы они писали бы что-то свое и сваяли бы что-то а-ля отчеты в АХ - то они бы не получили этого преимущества, как не получила АХ (из-за чего кстати и затеялась вся эта интеграция с Reporting Services и т.д.)
|
|
|
За это сообщение автора поблагодарили: kuntashov (1). |
17.12.2010, 16:41 | #9 |
Administrator
|
Скажем так. По 1С я не знаю корректных чисел. Но разница на порядок (если она существует) - роль играет. Как правильно заметил mazzy:
Цитата:
Т.е. когда написано нами - то а) нет широкой распространенности => тяжело претендовать на стандарт и б) высока вероятность частого изменения этих технологий нами (баги/совместимости/усовершенствования и пр.) и как следствие - отсутствие устоявшегося функционала Ну не совсем же с нуля его писали
__________________
Возможно сделать все. Вопрос времени |
|
17.12.2010, 19:30 | #10 |
Участник
|
|
|
17.12.2010, 19:46 | #11 |
Участник
|
|
|
17.12.2010, 18:05 | #12 |
Участник
|
Все относительно. Представьте картину - внезапно (по воле Бога, или еще какому-то чуду) собираются ведущие специалисты консалтинговых компаний и интеграторов для проектирования функционала прикладного решения, а потом коллектив специалистов уровня "1С: Эксперт по технологическим вопросам" проектируют и реализовывают прикладное решение. И вот, готова бомба. И что? Да ничего - маркетологов нанять забыли. ИМХО нет сейчас проблем с технологиями у 1С. Есть проблема в уровне коллективов разработчиков тиражных решений. А еще есть темные лошадки. Господа, проживая в провинции я таких зверей как "Инталев: корпоративные финансы" и "ИТРП:Процессное производство" даже не видел. Максимум - УПП. А кто-нибудь из вас на тендерах соперничал с ними, переходили с них на продукты MS? Есть хоть какие-то слухи об этих решениях в вашей среде?
|
|
17.12.2010, 19:25 | #13 |
Участник
|
Цитата:
Цитата:
Цитата:
Цитата:
Цитата:
Цитата:
Сообщение от kuntashov
Архитектура "клиент-сервер", взаимодействие с СУБД через ORM-слой, декларативный язык запросов, декларативная система описания отчетов (СКД) - разве это не примеры использования в 1С "методик, наработанных за десятиления в области инженерии ПО"?
А встроенные открытые средства интеграции с другими приложениями, поддержка открытых протоколов XDTO, SOAP? Средства сериализации в XML? COM? Кросс-платформенный NativeAPI для разработки внешних компонент? Или я не правильно вас понял и вы имеете в виду что-то другое? Цитата:
Тут есть такая замечательная вещь, как Best Practices для разработки. Солидный документик, в котором регламентирован каждый чих разработчика. Причем проверку следованию некоторым правилам Best Practices можно настроить на уровне компиляции. Вплоть до того, что запретить помещать в систему контроля версий элементы, не проходящие проверки Best Practices. Есть методология внедрения SureStep, которая требует проведения CodeReview старшим разработчиком по всем модификациями...так что такому нерадивому 1С-нику тут будет трудно развернуться . Культуру надо развивать...одной технологической платформы мало для написания качественных прикладных решений...А для этого нужна методология, правила, жесткая сертификация решений и т.д и т.п. |
|
|
За это сообщение автора поблагодарили: sukhanchik (2). |
19.12.2010, 03:59 | #14 |
Участник
|
Цитата:
Цитата:
Сообщение от SolNik
Под самобытностью я понимаю наличие в среде разработки 1С таких понятий, как Документ, Справочник, Регистр, План счетов и т.п.. И отсутствие таких понятий как класс, таблица, тип данных и т.п....За НАВ не скажу, но в Аксапте среда разработка гораздо более похожа на классические RAD-среды.
Это просто такая парадигма разработки. Ее назначение - сместить акценты от технологической составляющей к предметной области. Цитата:
Например, в Библиотеке Стандартных Подсистем реализована возможность вывода печатных форм в документ MS Word или в OpenOffice Writer. Работа с каждым типом документов (Word или Writer) представлена отдельным модулем УправлениеПечатьюMSWordКлиент и УправлениеПечатьюOOWriterКлиент соответственно. Но в месте с ними, реализован отдельный модуль - УправлениеПечатьюКлиент, который реализует унифицированный интерфейс и скрывает особенность реализации по работе с конкретным видом документов. Это пример применения паттерна Facade. Я могу привести еще кучу примеров из типовых конфигураций. Применение многих паттернов поддерживается уже на уровне технологической платформы, просто это надо понимать и видеть. Например, модули менеджеров объектов 1С - ни что иное, как реализация паттерна Singelton. Цитата:
Цитата:
Сообщение от SolNik
Понятно, что в семье не без урода . Но в DAX это будет сделать сложней .
Тут есть такая замечательная вещь, как Best Practices для разработки. Солидный документик, в котором регламентирован каждый чих разработчика. Причем проверку следованию некоторым правилам Best Practices можно настроить на уровне компиляции. Вплоть до того, что запретить помещать в систему контроля версий элементы, не проходящие проверки Best Practices. Есть методология внедрения SureStep, которая требует проведения CodeReview старшим разработчиком по всем модификациями...так что такому нерадивому 1С-нику тут будет трудно развернуться . Для разработки это Система стандартов и методик разработки конфигураций для платформы 1С:Предприятие 8. Соблюдение этих стандартов может быть автоматически проверено, для этого существует специальное типовое решение - Автоматизированная проверка конфигураций, есть аналогичные решения от партнеров, которые также позволяют свои правила проверки описывать. Есть база знаний ПрофКейс, которая содержит регламенты, методики управления проектами внедрения, шаблоны документов, кейсы. Не спорю, и отметил в своем исходном сообщении, что проблема сейчас ключевая не в платформе, а в специалистах.
__________________
С уважением, Александр Кунташов |
|
19.12.2010, 11:00 | #15 |
Administrator
|
Цитата:
Цитата:
Полиморфи́зм (в языках программирования) — возможность объектов с одинаковой спецификацией иметь различную реализацию.
... Полиморфизм позволяет писать более абстрактные программы и повысить коэффициент повторного использования кода. Цитата:
Насле́дование — позволяет описать новый класс на основе уже существующего (родительского), при этом свойства и функциональность родительского класса заимствуются новым классом.
У всех журналов есть общие свойства. Ну, к примеру, все журналы имеют по фильтр журналов Все/Открыто/Разнесено, который по умолчанию устанавливается в Открыто. Соответственно - этот код лежит в самом родительском классе. Для финансовых журналов есть "валютные поля" - валюта, курс и т.д. Функционал, обслуживающий эти поля - может быть вынесен в класс, управляющий всеми финансовыми журналами. Для складских журналов есть складская аналитика - соответственно обслуживание этих полей - также находится в классе, управляющем всеми складскими журналами. Ну и дальше - у каждого документа естественно есть свои нюансы, которые реализуются индивидуальным наследником. Другой пример. Работа с Excel. Для разных версий Excel (конкретно для 2000, XP и 2007) есть свои классы-наследники, про которых программист может и не знать, однако вызывает он методы общего родительского класса, а там уже на уровне конструирования класса - система сама, в зависимости от версии инициализирует нужного наследника. Без этого было бы неприятно узнать, что код, который работал в 2003-м офисе перестал работать в 2007-м (к примеру). Конечно - никто не говорит, что без этого нельзя обойтись. Всегда можно создать большой метод (процедуру в 1С) и внутри нее делать кучу if нв предмет - версии, на предмет типа журналов и т.д. Но речь-то идет и максимальном использовании уже написанного кода и (как следствие) уменьшение количества кода в котором нужно разбираться. Собственно для этого и нужны ООП-принципы
__________________
Возможно сделать все. Вопрос времени Последний раз редактировалось sukhanchik; 19.12.2010 в 11:06. |
|
|
За это сообщение автора поблагодарили: driller (2). |
21.12.2010, 18:12 | #16 |
Участник
|
В 1С, если речь идет о списках документов одного вида - они реализуются декларативно (формы списка конкретного вида документа).
Если речь идет о сводных списках журналов, то для этих целей есть специальный объекты метаданных - журналы документов. Значительная часть реализации самого списка, особенно в Управляемых формах, реализуется декларативно, путем настройки запроса на выборку данных. Все остальное (видимость, группировка колонок, группировка строк и оформление в Управляемых формах) настраивается универсальным образом (и при необходимости такая возможность может быть предоставлена пользователю). Приведенный пример не показывает преимущества подхода с наследованием. На практике глубокая иерархия наследования журналов документов (более 2 уровней иерархии) не сильно восстребована, и более того, конкретный журнал отражает специфику работы с конкретным перечнем видов документов, т.е. не универсален, а значит и наследовать от такого класса скорее всего не эффективно (обычно такие классы помечаются как sealed).
__________________
С уважением, Александр Кунташов |
|
|
За это сообщение автора поблагодарили: Lemming (5). |
21.12.2010, 20:39 | #17 |
Участник
|
Цитата:
А 1С я думаю намеренно не вводит ООП в свою платформу. Потому, как это увеличит порог входа для разработчиков на этой платформе. Уже на каждый ПТУ-ник сможет сваять простенькую конфу. Отсюда у вас будет вечная проблема: Цитата:
И вообще, имхо, невозможно одинаково эффективно использовать одну платформу для разработки бизнес-приложений для малого бизнеса и для корпораций. Посмотрите на SAP и его BO, на Dynamics и его NAV...1С как всегда идет своим путем...посмотрим на сколько его хватит... |
|
|
За это сообщение автора поблагодарили: konopello (1). |
21.12.2010, 21:56 | #18 |
Участник
|
Цитата:
Вы просто не поняли его подоплеки. Я не спорил. Кажется, я вопросы задал, разве нет? Я пытаюсь понять, в чем преимущество, скажем так, "пути Ax", в чем его недостатки, и соответственно, в чем преимущества "пути 1С", и в чем их недостатки. Для этого пытаюсь узнать, как те или иные задачи решаются средствами Ax, чтобы сравнить с тем, как решаются в 1С. Вы сказали, что для решения используются "полиморфизм, инкапсуляция, наследование" и что преимущества очевидны. Но в сравнении с 1С на конкретном примере про журналы - совсем не очень очевидны. Но это не значит, что нет других примеров, подтветржающих вашу правоту. Но в этому случае имеет смысл поговорить, как часто на практике с такими примерами мы сталкиваемся на внедрениях. Цитата:
Но, кажется, что оба пути (Ax и 1С) различаются в том, что Ax предоставляет более низкоуровневые средства разработки (таблицы вместо ORM, ООП со всеми его вкусностями вместо слоя с готовыми классами объектов, "заточенных" под решение учетных задач определенного класса и т.п.). Это просто другой подход к решению тех же самых задач. Да, очевидно, что более низкоуровневые средства Ax - гибче. Но да, очевидно, более высокоуровневые средства 1C позволяют быстрее вести разработку. В таком ключе я продолжать дискуссию готов. Язык 1С не является самодостаточным и неотделим от технологической платформы. Он императивен и его предназначение - манипуляция объектами технологической платформы. Поэтому, я считаю, некорректно проводить аналогию с самодостаточными языками программирования. Цитата:
Цитата:
А вот уже решения на этой платформе позиционировать в соответствующих сегментах. Но у 1С все так и есть: Управление небольшой фирмой и УПП, Бухгалтерия предприятия 8 и Бухгалтерия предприятия КОРП.
__________________
С уважением, Александр Кунташов |
|
25.12.2010, 01:23 | #19 |
Участник
|
Цитата:
Сообщение от kuntashov
Но, кажется, что оба пути (Ax и 1С) различаются в том, что Ax предоставляет более низкоуровневые средства разработки (таблицы вместо ORM, ООП со всеми его вкусностями вместо слоя с готовыми классами объектов, "заточенных" под решение учетных задач определенного класса и т.п.).
Кстати постоянное тотальное переписывание конфигураций с выходом каждой новой версии платформы, а также зоопарк типовых конфигураций, внешне похожих но кардинально различающихся внутри - это имхо все следствия ущербности среды разработки, не позволяющей элегантно, целостно реализовать сложную, взаимосвязанную бизнес-логику. В общем, как уже говорил, очень сложно на одной платформе реализовать одновременно простую, но в то же время гибкую, позволяющую строить большие сложные решения, систему... |
|
|
За это сообщение автора поблагодарили: pitersky (2). |
17.12.2010, 23:49 | #20 |
Участник
|
В УПП прримерно 3700 таблиц.
|
|