AX2009 has been Released

[fed]

Цитата:

Сообщение от mazzy

Можешь объяснишь, почему считаешь, что классическая модель не очень подходит?

Потому что в классической модели, разработчик (не конкретный человек, а организация) является владельцем исходных кодов. А в ERP постоянно возникает ситуация, когда в новой версии/обновлении, какие-то совершенно незнакомые тебе люди принципиально переписали кусок, за который ты отвечаешь. И тебе либо надо как-то отмигрировать свои доработки на этот кусок, либо по крайней мере быстро обнаружить что твои доработки с ним принципиально не совместимы и их надо перепроектировать. На самом деле, конечно, механизм патчей тоже не универсален. Ситуации изменения семантики функций он не отлавливает. В идеале было бы хорошо сделать механизм патчей+опубликованные юнит-тесты. Но это уже совсем идеальная ситуация

Кстати - как ни странно, аналогичная ситуация есть в Linux. Там тоже существует некоторое количество независимых веток (патчей) к ядру, которые поддерживаются каким-то энтузиастами. Периодически, если некий патч востребован сообществом, он включается в базовый комплект ядра (или не включается по принципиальным соображениям и отмирает). Но в Linux, как я понимаю, проблему удается, во многом, снять из за использования системы управления версиями исходных текстов (запамятовал как там она называется). Но подобные системы хорошо работают в системах, в которых программы разрабатываются ТОЛЬКО из исходных текстов, без использования ресурсов. Учитывая, как много семантики в Аксапте имеют как раз ресурсы (описания форм, описания типов, таблиц и тп), которые не очень пригодны для текстового представления, хорошая система управления исходными текстами не спасает...

Да и кстати поставлять заказчику библиотеку в виде diffа к xpo-файлам было бы странно

[mazzy]

Цитата:

Сообщение от fed

Потому что в классической модели, разработчик (не конкретный человек, а организация) является владельцем исходных кодов.

Почему то вспоминаются славные времена фортрана и библиотек к нему...
Думаю, что это не особенность ERPшного подхода

Цитата:

Сообщение от fed

А в ERP постоянно возникает ситуация, когда в новой версии/обновлении, какие-то совершенно незнакомые тебе люди принципиально переписали кусок, за который ты отвечаешь.

Угу. Особенно в той же версии и даже не в сервис-паке, а в каком-нибудь хот-фиксе, который посвящен совсем другой тематике...
По рогам и по мозгам им за это...
Но только по-моему это тоже не особенность ERPшного подхода

Цитата:

Сообщение от fed

Кстати - как ни странно, аналогичная ситуация есть в Linux.

И не только там. Есть еще масса платных и бесплатных библиотек, построителей отчетов, графиков, картинок, доступа к чему-нибудь...

В общем, просто надо повышать культуру разработки.
А для этого на мой взгляд надо в полной мере использовать то, что давно наработано в классическом девелопменте... А не изобретать велосипеды...

[fed]

Хотел mazzy процитировать но запутался в наших с ним взаимных квотах

Это как раз типичная ERPшная ситуация. Вендору, по каким-то причинам, нужно изменить функционал. Возможно, изменение этого функционала приведет к несовместимости с доработками партнеров и клиентов. При этом, вендор, в общем случае, ничего не знает об этих партнерских и клиентских доработках и оценить масштабы бедствия просто не может.
Если не изобретать велосипед - то что надо было бы, по твоему мнению, делать в подобной ситуации ? Вариант ответа "Правильно программировать", "Думать головой когда программируешь" и т.п. не подходит. Во первых люди вообще склонны ошибатся, во вторых никакие методики не позволяют гарантированно программировать с учетом будущих событий Невозможно разрабатывать программу так, чтобы она гарантирована легко адаптировалась под неизвестные в данный момент будущие изменения функциональности. То есть - конечно мне тоже время от времени попадаются куски кода, за которые их авторам хочется оторвать руки. Но я понимаю, что вполне возможно, что в тот момент когда этот код писался - он не был таким уж кривым...

Ну и кстати - ситуация с библиотеками не очень подходит в качестве примера. Библиотеки - это некий внешний механизм, который я интегрирую в систему через опубликованные интерфейсы. При интеграции я не изменяю исходных текстов этих библиотек, я работаю с ними через интерфейсы. (Конечно бывает, что без изменения интерфейсов, владелец библиотеки как-то неявно меняет ее внутренности и моя программа перестает работать, но это нештатная ситуация).
При разработке в ERP мне постоянно, штатным образом, приходится модифицировать исходные тексты, владельцем которых я не являюсь.

Соответственно - на мой взгляд самый правильный вектор развития систем разработки в ERP, это какое-то развитие механизма слоев в сторону механизма патчей.

[mazzy]

Цитата:

Сообщение от fed

Это как раз типичная ERPшная ситуация. Вендору, по каким-то причинам, нужно изменить функционал. Возможно, изменение этого функционала приведет к несовместимости с доработками партнеров и клиентов. При этом, вендор, в общем случае, ничего не знает об этих партнерских и клиентских доработках и оценить масштабы бедствия просто не может.

Ну, почему же ERPшная? Ты почитай хотя бы Страустрапа, как они C++ меняли, что с библиотеками делают. Винда ведь тоже не с нуля пишется. Тоже содержит кучу библиотек, многие из которых используется в доработках другими.

И ничего, более-менее выход найден.

Цитата:

Сообщение от fed

Если не изобретать велосипед - то что надо было бы, по твоему мнению, делать в подобной ситуации ?

Сохранят совместимость со старыми. Если возникает что-то новое, то писать рядом стоящую библиотеку, а старую объявлять устаревшей и рекомендовать не использовать... В общем, это уже давно проработанный вопрос, по-моему.

Цитата:

Сообщение от fed

Ну и кстати - ситуация с библиотеками не очень подходит в качестве примера.

Хорошо, офис с его функциями и макроязыком, всевозможные шелы от vbscript до javascript...

Цитата:

Сообщение от fed

Библиотеки - это некий внешний механизм, который я интегрирую в систему через опубликованные интерфейсы. При интеграции я не изменяю исходных текстов этих библиотек, я работаю с ними через интерфейсы. (Конечно бывает, что без изменения интерфейсов, владелец библиотеки как-то неявно меняет ее внутренности и моя программа перестает работать, но это нештатная ситуация).

Ну, почему же, есть библиотеки и в исходных кодах.
На моей памяти это были всякие TurboVision и OWL. Думаю, что и сейчас такие есть.

Цитата:

Сообщение от fed

При разработке в ERP мне постоянно, штатным образом, приходится модифицировать исходные тексты, владельцем которых я не являюсь.

Я просто хочу сказать, что это не особенность для ERP-разработки.

Цитата:

Сообщение от fed

Соответственно - на мой взгляд самый правильный вектор развития систем разработки в ERP, это какое-то развитие механизма слоев в сторону механизма патчей.

Ок. Но сначала лучше посмотреть как решают аналогичную проблему другие

[gl00mie]

Цитата:

Сообщение от mazzy

Ну, почему же ERPшная? Винда ведь тоже не с нуля пишется. Тоже содержит кучу библиотек, многие из которых используется в доработках другими. И ничего, более-менее выход найден.

Помнится, «винда» в свое время породила такое понятие как DLL Hell, связанное с тем, что разным приложениям были нужны разные версии одних и тех же библиотек, и при установке одного приложения запросто могли отвалиться другие, уже установленные. В XP это решили кардинально - сделали для изоляции приложений механизм размещения библиотек side-by-side и возможность взаимодействовать с COM-серверами без их регистрации. Однако, ключевое отличие ситуации в Windows и в ERP заключается в том, что под Windows работает множетсво приложений, в то время как в случае той же Аксапты, как правило, в отдельно взятой компании в каждый момент времени рабочее приложение одно. И тут уже трюки с множеством версий одной библиотеки не прокатят...