22 октября, понедельник 18:00
Bankir.Ru

Объявление

Свернуть
Пока нет объявлений.

Delphi+Java+что дальше и почему ?

Свернуть
X
  • Фильтр
  • Время
  • Показать
Очистить всё
новые сообщения

  • Delphi+Java+что дальше и почему ?

    Интересно, Диасофт пытался как-то публично высказаться о причинах выбора инструментов разработки системы ?
    То есть без надувания щек о модных архитектурах и т.п.
    Если взять историю, то что было раньше: Clarion+Btrieve (одна команда разработчиков), затем другая команда, которой был близок Delphi+SQLServer(MS и Sybase). Разрабатывалась клиентская часть и серверная. Когда клиентов у этой команды было мало, то логику работы успевали менять и для клиента, и для сервера.
    Сейчас наверное третья команда. Клиентов стало больше, разброс их требований стал шире. Серверную часть как меняли, так и меняют (присылают скрипты). А вот что делать с клиентской частью ? Бесконечные ошибки и связанные с этим перекомпиляции наверное достали самих разработчиков. Логику поведения клиенской части тоже захотелось сделать гибкой. Какой выход ? Да взять какой-нибудь интерперетатор и пусть внедренец (клиент) сам настраивает систему. Вот только выбор инструментария каков должен быть ? Я бы предложил лучше MS Access (рисовал бы и формы и таблицы и т.д.), а вы ?

  • #2
    Да, с такими темпами опустошающей деградации в Диасофте скоро будет команда разработчиков, которой близок MS Access...

    Комментарий


    • #3
      AlexanP
      Чегой-то я за мыслью не успеваю. Во-первых Диасофт, по краней мере мне объяснял выбор Delphi. Нужен был RAD, в который можно было бы встроить собственные компоненты. Если вы обращали внимание на GUI 5nt, он довольно специфичен. Чего столько стоит не соханение значений в поле при выходе "назад" по форме. Короче, была забота о поддержке стандартов на уровне среды разработки.
      Если взять историю, то сначала был чистый Clarion на файлах, потом Clarion+Btrieve с одновременной попыткой сделать С++ + Sybase. Потом был выбор - Clarion for Windows или Delphi.
      Логику клиентской части давно уже делали гибкой. И интерпретаторы там есть - JScript и VBScript. Вы видели т.н. "переносимые фин. операции"?
      В том то и беда, что когда есть выбор между т.н. настройкой и программированием он, как правило, делается в пользу настроек. Очень просто нарисовать отчет для конкретного случая. Но Диасофт никогда так не поступит и, мне, клиенту, будет всячески не советовать. А будет он накручивать какой-нибудь уже имеющийся отчет путем добавления безумных классификаторов до полной потери контроля. То есть до того момента, когда уже все перестают понимать, как это вообще может работать.
      Не понимаю, откуда это идет убеждение, что людям, работающим в банках, противопоказано программировать? Это чего, в Диасофте собрались сплошь гениальные программисты, а в банках одни уроды неграмотные?

      Комментарий


      • #4
        Сообщение от loo Посмотреть сообщение
        AlexanP
        Не понимаю, откуда это идет убеждение, что людям, работающим в банках, противопоказано программировать? Это чего, в Диасофте собрались сплошь гениальные программисты, а в банках одни уроды неграмотные?
        Разговаривал не так давно с одним из представителей Диасофта (небезактивный участник полемик данного форума по поводу своей компании, кстати). Он так и говорит - в банках ИТ-отделы "должны менять катриджы", а все остальное должны делать профессиональные РАЗРАБОТЧИКИ (мол, мы все сделаем). Бред – согласитесь (как на счет «сделаем», так и на счет «профессиональные&#187. Но такой подход в данной компании, по всей видимости, имеет быть место.

        На счет Access – это конечно уже слишком )) Хотя как один из крайних вариантов ) Современные тенденции развития программного обеспечения уже отвечают на поставленные вопросы (имеется ввиду «Кто виноват?» и «Что делать?&#187. Только, чтобы дошло до дела, нужно приложить уйму усилий. На данный момент, ни один разработчик (или скорее это уже задача интеграторов) в Россее на подобные свершения неспособен (кроме как «популистических» и «рекламный» высказываний вроде – Интеграция, FA#, SOA, бла-бла-бла).
        С удовольствием делаю только то, что относится на счета доходов... либо на счета 613

        Комментарий


        • #5
          публично высказаться о причинах выбора инструментов разработки системы
          Вот если бы Диасофт где-то приводил свои рассуждения, обоснования своего выбора, то можно было хоть как-то понять.
          Вот есть у нас РКО с интерфейсом Delphi и Retail с интерфейсом Java. В РКО пользователь при вводе платежки нажимает клавиши и система в течении 0.5 сек отвечает, а вот в Retail нажатие клавиш, связанные с новым вкладом или операцией сопровождается задумчивостью в 5-10 сек. Попытки в Profiler-е увидеть задержки ни к чему не привели. Поле Duration там около 1 сек (в совокупности всех запросов). Вот так и работают пользователи с физиками, нажали клавишу и смотрят в окно, а клиенты-физики стоят, нервничают. Так если Java такой медленный, то зачем его выбирать ?
          Посмотрите вакансии в Диасофт
          Программист J2EE senior
          Программист J2EE в новый проект!
          Программист Java Swing
          Посмотрите на форумах о производительности Java Swing. Где то может эта сонность Java и не бросается в глаза, а где-то это критично. В Сбербанке приятно в очереди с коммунальными платежами стоять ?
          А ведь все это работает еще и в удаленном доступе через терминальный режим ...

          Комментарий


          • #6
            Prince, в чистой теории ("Флуктуации сферического коня в вакууме (С)") он прав. В реалиях мы имеем... продукт.
            Access, отличный вещь, быстрая и легкая, ДЛЯ СВОЕЙ ОБЛАСТИ ПРИМЕНЕНИЯ. На Porsche не возят уголь по котельным.
            Согласен, что "На данный момент, ни один разработчик (или скорее это уже задача интеграторов) в Россее на подобные свершения неспособен". Не спроектировать сейчас модель Российского Банка со всеми видами бизнеса целиком. Путь "построить коробку, перестроить его в в дом, потом в гостиницу надстраивая номера, рестораны, бассейны...." приведет к тому, что на рынке Российского Банковского ПО в подавляющем случае предлагается - системы, в которых сами разработчики не разбираются. Поинтересуйтесь в Диасофте насчет схемы реляций, хотя бы основных таблиц
            Выход видится один - относительно небольшие, слабосвязанные функционально-законченные модули со стандартизованным обменом (именно так сейчас строится подавляющее большинство цифровых систем. Включая PC).

            AlexanP, по секрету скажу, что кроме Qtrl+Alt+Q есть еще не менее "волшебная" комбинация Ctrl+Alt+B. Вдумчиво протрассируйте. Мы находили код, где серверной процедурой сурово высчитывается некий параметр, после чего ему тупо присваивается константа - явный ляп внедренцев, подогнавших smf под нужды Банка. 99,(9)% что найдете и ускорите много чего. Настройки сервера терминального посмотрите.
            Java, конечно не ассемблер по скорости, но ПРАВИЛЬНО написанный код выполняется очень даже быстро при удовлетвороении минимальных требований по железу/памяти.
            На форумах много религиозных мнений фанатов, читайте мануалы, по крайней мере с точки зрения составления мнения о технологиях.

            Комментарий


            • #7
              Выход видится один - относительно небольшие, слабосвязанные функционально-законченные модули со стандартизованным обменом
              А ведь проект 5NT строился прежде всего как тесно интегрированная система, потому что все операции банка сильно взаимосвязанны. Ушел руководитель проекта - и что, концепция уже стала с точностью до наоборот ? Результат этого "слабосвязанные функционально-законченные" подхода мы пожинаем на примере раздельно существующих баз с выделенем в Ритэйл кассового модуля, вкладов, потребкредитов, пластик.карт. Далее в Ритэйле производится свертка (свод), так вот эта новая операция, занимает половину безнес времени у сотрудников банка, которые только и выверяют соответствующие данные. Ну нет ничего слабо-взаимосвязанного в работе банка !!!
              А моя фраза по поводу Access такая же безответственная как и у Диасофта. Я что какие-то доводы или сравнения привел ? Где у Диасофта какие-то аналитческие статьи по выбору архитектуры, инструментария ?

              Комментарий


              • #8
                AlexanP, сдается мне, что Вы не очень давно работаете в банке. Либо работаете в не очень крупном банке.
                Какая связь обслуживания, скажем в кредитном модуле физика и сделками на бирже? Да, в конце дня (утром следующего) они ОБЯЗАНЫ попасть в ОД. Но кастоди можно и нужно изолировать от ретейла. Иначе Вы не сможете обрабатывать сколь ни-будь стабильно тех и других.
                Не понятно, зачем Вам статьи о выборе Диасофта? Вас интересует из какого металла по какому техпроцессу изготовлен трактор "Беларусь", который пашет землю в колхозе "Сорок лет без урожая", из зерна которого сделали муку для хлеба, который Вы ели на завтрак? Думаю врядли. Вас интересуют вкусоваые качества этого хлеба, его полезность для организма...

                Сверка/сводка действительно может составлять серьезную проблему.
                В том случае, если изменения двусторонние, а связь односторонняя.
                (Чего выверять, если изменения идут ТОЛЬКО в РЕТЕЙЛЕ? Не бреете же Вы утром зеркало, побрив лицо ) Отрегулируйте бизнес-процесс... либо вводите обратную связь. Не скажу, что будет счастье, но станет терпимо. За это Вы платите независимостью Ретейла от ОД (думается, что в случае Вашего Банка это не насущная необходимость, а ошибка в определении архитектуры).
                Последний раз редактировалось IgorL; 12.02.2008, 14:48. Причина: Дополнение

                Комментарий


                • #9
                  AlexanP
                  А ведь проект 5NT строился прежде всего как тесно интегрированная система,
                  Проект 5nt строился, прежде всего, как отдельно стоящая система автоматизации операций на Фин. рынках при живой 4-ке. И появился этот проект году так примерно в 95-м именно вследствие понимания невозможности развивать систему как сильно интегрированную. А потом кое у кого случился приступ жадности.
                  Конечно, наличие слабосвязанных модулей, как и любое структурирование создает массу проблем. Давайте рассмотрим простую аналогию: команда из 5-ти человек нормально работает безо всякой структуры. Но если у Вас компания из 500 человек вы создаете отделы, пишете регламенты, назначаете начальников, заместителей, устраиваете совещания. Все это, безусловно, накладные расходы. В конце концов этот процесс может завести Вас куда угодно. Ну Вы знаете - проектный офис, процессный офис, 3 часа на пару - включаешь не работает.
                  Но это не означает, что структура не нужна и компания в 500 человек может работать по принципу команды.
                  Далее в Ритэйле производится свертка (свод), так вот эта новая операция, занимает половину безнес времени у сотрудников банка, которые только и выверяют соответствующие данные.
                  Но это же ерунда. Это ж, на мой взгляд, элементарный отчет по оборотам за день, или я чего-то не понимаю?

                  Комментарий


                  • #10
                    Сообщение от AlexanP Посмотреть сообщение
                    А вот что делать с клиентской частью ? Бесконечные ошибки и связанные с этим перекомпиляции наверное достали самих разработчиков. Логику поведения клиенской части тоже захотелось сделать гибкой. Какой выход ? Да взять какой-нибудь интерперетатор и пусть внедренец (клиент) сам настраивает систему. Вот только выбор инструментария каков должен быть ? Я бы предложил лучше MS Access (рисовал бы и формы и таблицы и т.д.), а вы ?
                    Хороший выход. А в чём тогда вообще будет функция "диасофта"? Серверные скрипты с ошибками рисовать и деньги собирать?
                    Ошибки фиксят и так в основном на местах.
                    Настраивают на местах.
                    Отчеты, реально помогающие бизнесу делают на местах.
                    Осталось только "избавиться" от клиентского кода - и вообще наступит счастливая жизнь.
                    Насчет Аccess - хорошая шутка :-)
                    Access изначально создавался как инструмент быстрой разработки домашних БД - пару формочек, несколько кнопочек и пр. (и всегда такой средой будет, хоть кое-где на нем написаны приложения для серьезных задач с изрядным объемом кода) Использовать его в качестве средства разработки для производства тиражируемой промышленной системы - верх идиотизма.

                    Комментарий


                    • #11
                      А в чём тогда вообще будет функция "диасофта"?
                      собирать пофиксенные баги с одних мест, и направлять другим ))
                      и за это получать $$$

                      Комментарий


                      • #12
                        Вас интересует из какого металла по какому техпроцессу изготовлен трактор "Беларусь",...интересуют вкусоваые качества этого хлеба, его полезность для организма...
                        Про аналогии. Если вы покупаете себе автомобиль, то наверное хотите, чтобы он через полгода не проржавел. Да и пациент у врача может конечно и не спрашивать, зачем ему руку отрезают при порезе пальца. Да и вы наверное говорите врачу, ну мне же стало хуже, что за лекарства вы мне даете ? Или вам абсолютно наплевать, что вам вкололи, лишь бы организм запрыгал от радости ? А нашем случае происходит именно так: "доктор, нам стало хуже (медленнее)", может другое лекарство (технологию, архитектуру, инструмент) надо было применить ? И тут что важно, если равнодушно ко всему этому относится, то можно даже и не успеть поменять врача.
                        А в этой теме хотелось бы услышать мнение банков с установленным Ритэйлом. Может и нет у них таких проблем.

                        Комментарий


                        • #13
                          AlexanP, Ваши аналогии в корне не верны. Они оказывают непосредственное влияние на объект (прямая связь). Инструмент программирования Диасофта не имеет даже косвенной связи (как и моя аналогия с металлом из которого изготовлен трактор к хлебу) к качеству продукта.

                          Ваше вопрошение о банках на ретейле (ну наш банк использует и ретейл и не ретейл в разных комбинациях, с раздельными базами и "все в одном" ) никак не коррелирует с Вашей темой о выборе инструмента, к тому же в ретейл не используется именно Java.

                          На сим раскланиваюсь.

                          Комментарий


                          • #14
                            А что конкретно вас интересует в ретейле?
                            С уважением.
                            (данное сообщение является ЛИЧНЫМ мнением, а никакак не мнением моего работодателя).

                            Комментарий

                            Пользователи, просматривающие эту тему

                            Свернуть

                            Присутствует 1. Участников: 0, гостей: 1.

                            Обработка...
                            X