Форум: "Прочее";
Текущий архив: 2013.12.29;
Скачать: [xml.tar.bz2];
ВнизРеинжиниринг торговой системы Найти похожие ветки
← →
clippership (2013-05-31 11:01) [0]Добрый день!
Надо немного пофлудить вот на тему реинжиниринга, которая касается меня лично и с которой в жизни мне сталкиваться не приходилось. Итак, есть огромная торговая система написанная на Delphi, БД - FireBird 2.5
Программа писалась в свое время какой-то конторой, развалившейся в 2000 году и не оставившей после себя никакой документации. Комментариев в коде программы практически нет. С тех пор множество программистов приложили свои руки в "усовершенствование" программы. Естественно, все делалось бессистемно, в виде заплаток. Что имеем. Проект с кучей библиотек и форм. Количество форм в общей сложности (вместе с теми, что находятся в dll-ках) - около 500. Примерно, такая же БД. Огромное количество таблиц, триггеров, хранимых процедур. Причем, название таблиц, типа "ААА", "ВВВ" - вполне нормальное явление, и самое печальное, в подобных таблицах могут быть данные.
И вот, захотелось мне получить ясную картину того, что сейчас имеется в этой системе, чтобы, проанализировав, можно было понять - что здесь лишнее или где бизнес-процессы построены из рук вон плохо и их необходимо менять. Ибо глючит программа часто и "не по децки". Задача нетривиальная, здесь скорее нужен специалист, который имеет опыт по реинженирингу. Сразу скажу - переписать систему с нуля нельзя. Но, вот, начальство может не пойти на то, чтобы нанять специалиста, поэтому надо попробовать для начала самому.
Первая задача - получить картинку имеющегося бизнес - процесса торговой системы, а точнее - построить схему взаимодействия программы и БД такой, какая она есть сейчас. Но, если кто имеет представление, с чего начать, какие case-системы применить, в какой конфигурации (редакции) лучше всего их использовать для решения данной задачи - был бы благодарен.
В теме не возбраняется спорить, указывать в чем я не прав или в чем не понимаю совсем, ибо в споре рождается истина... :)
Заранее всем спасибо.
← →
turbouser © (2013-05-31 11:21) [1]для начала - в ibexpert-е можно построить диаграмму (там есть реверсинжиниринг) и посмотреть все связи визуально
ну и помониторить SQL запросы к серверу (FBScanner например http://www.ibaseforum.ru/viewtopic.php?f=32&t=4938)
← →
знайка (2013-05-31 11:42) [2]А зачем это всё делать?
← →
Jeer © (2013-05-31 11:56) [3]Делал я реверсинжиниринг одной система ( только БД ) и только для того, чтобы переписать всю систему.
Какое-то время совместно работали две системы, потом исходная была послана, а новая слегка подкорректирована для оптимальности.
Разбираться в исходниках и БД большой системы, да еще недокументированной, с целью понять бизнес-процессы - неверно.
← →
"Добрый Сок" (2013-05-31 12:15) [4]
> Разбираться в исходниках и БД большой системы, да еще недокументированной,
> с целью понять бизнес-процессы - неверно.
+999999999999999999
и с вероятностью 0.99999999999999999999 - бесполезно
← →
clippership (2013-05-31 12:45) [5]Jeer, ну а как же поступить? Выхода у меня нет, я описал задачу, которая передо мной стоит, имею то, что имею.
Система рабочая, писалась 20 лет, ни о каких новых решениях - речи нет. Начальство привыкло к ней и менять не собирается. Пока гром не ударит, мужик не перекрестится, как говорится. А гром ударит обязательно, через год или два, но это ж когда будет!!! :)
Но я свежим взглядом вижу, что система не просто в тупике - она сама себя "загоняет в угол". Все через одно место работает, глючит постоянно, причем глюки, как в каждой огромной и запутанной системе - загадочные и волшебные. В любом случае - мне бы увидеть - как всё взаимосвязано в программе сейчас. Изучать код, чтобы вывести эти зависимости - нереально.
Для начала я бы просто хотел увидеть картинку. Неужели нет какого-нибудь средства, которое облегчило бы эту задачу?
turbouser, спасибо за конкретное предложение по FB. Буду его изучать обязательно.
← →
Jeer © (2013-05-31 12:56) [6]Анриал.
Ну разве, что для практики в садомазохизме.
P.S.
Если система писалась 20 лет конторой, потом дописывалась отдельными умельцами, то с какого перепугу Вы решили, что можете один заменить их всех?
С таким же успехом Вы можете надеятся в одиночку написать подобную систему, что, кстати, и проще будет.
Или Вы считаете, что найдете два-три-*надцать узких мест и все волшебным образом рассосется?
Извините, я в чудеса не верю.
В общем, чудодейственного рецепта нет. Если так приспичило - сидеть и разбираться с БД, бизнес-процессы восстанавливать по методам работы персонала с этой системой.
Любой инструментарий - это не панацея и голову не заменит.
← →
clippership (2013-05-31 13:08) [7]Jeer © , так, кто спорит.
Но я надеюсь общей картинкой хотя бы представить, что в системе лишнее и отделаться от балласта. Говорить о том, чтобы сделать идеальную систему - не приходится. Думаю, хотя бы упростить и кое-где оптимизировать.. Это все, что возможно сделать по максимуму.
Правда, есть еще один способ: продолжать накладывать заплатки и вносить свою лепту в существующий бардак, а затем во-время уволится - до того момента, когда все начнет рушиться. Но как-то не по мне последний вариант.
Есть, правда, еще и профессионалы, которые занимаются именно подобными задачами, но их вердикт предугадываю, он будет таким же, как и у Вас. Поэтому я и не ставлю задачей полностью провести грамотный реинжениринг, моя задача - выкинуть мусор, как из базы, так и из программы, а так же улучшить кое-что в особо-критичных направлениях бизнес-процесса. Это всё...
Теоретически, это возможно, я так думаю.
← →
clippership (2013-05-31 13:08) [8]А как Rational Rose?
← →
"Добрый Сок" (2013-05-31 13:10) [9]
> как же поступить?
Вариантов 3.
1. Уйти оттуда.
2. Постоянно править, регулярно получая зп.
3. Уговорить перейти на готовое решение
4.
сесть с толковым конечным юзером, что бы он объяснил как работает система с его т.з., применимо к его направлению работы
Выяснить это у всех: Бухов, кладовщиков и т.п.
Купить обои и поклеить тыльной стороной наружу.
Перенести на них схему и наносить (параллельно, рядом) понятое от людей, пока не охватишь весь процесс.
Охватив процесс, начинать потихоньку править параллельную _свою, копию БД и программы, объединяя и разваливая процессы/структуры по мере надобности.
короче, на ближайшие год-два ничего существенно не планируй :)
← →
clippership (2013-05-31 13:21) [10]"Добрый Сок" , понимаю.
То есть, все руками. Тоже выход, конечно. Собственно, так я уже и поступаю. Но в данном случае получается картина бизнес-процесса предприятия, который связан с программой, а программа - черный ящик.
По предложенным тобой вариантам :) , тогда лучше уж пункт 2, плавно переходящий в пункт 1.
Пункт 3 - нереален: уже уговаривал. Приводятся аргументы, которые приводить не буду, но суть которых одна :"Мы привыкли и нам ничего не надо"
← →
clippership (2013-05-31 13:25) [11]Да здравствует садомазохизм, получается. То есть, дело дрянь.
← →
Компромисс1 © (2013-05-31 13:30) [12]
> моя задача - выкинуть мусор, как из базы, так и из программы
Для этого придется досконально разобраться в каждой строчке программы. А главное - зачем? Надежности это не прибавит (если действительно мусор), а новых ошибок добавить может (если будет выкинут не мусор)
← →
TUser © (2013-05-31 14:20) [13]Я бы еще предложил написать и зарегистрировать официальную служебную записку с описанием проблемы и негативного прогноза и своих вариантов решения (все переписать, наняв для этого профессиональную контору, и не на Delphi). Если удастся получить у начальства письменный отказ в полноценном обновлении - вообще прекрасно.
Потому что когда что-то не просто заглючит, а полноценно упадет, - виноват будет, угадай кто.
← →
картман © (2013-05-31 14:21) [14]
> Все через одно место работает, глючит постоянно, причем
> глюки, как в каждой огромной и запутанной системе - загадочные
> и волшебные
нельзя ли глюки классифицировать и через них найти где и что править?
← →
"Добрый Сок" (2013-05-31 14:25) [15]
> нельзя ли глюки классифицировать и через них найти где и
> что править?
причем, методом :
:Start
Подойти к
> толковым конечным юзером, что бы он объяснил как работает
> система с его т.з., применимо к его направлению работы
> Выяснить это у всех: Бухов, кладовщиков и т.п.
И у каждого спросить "если бы я мог прямо сейчас исправить одну твою бизнес-операцию, что бы ты хотел исправить?"
Получив от всех их первоочередную проблему - устранить.
goto Start;
← →
брат Птибурдукова (2013-05-31 14:38) [16]
> "Добрый Сок" (31.05.13 14:25) [15]
goto operator considered harmful :-D
← →
Inovet © (2013-05-31 14:54) [17]> [16] брат Птибурдукова (31.05.13 14:38)
> goto operator considered harmful :-D
Надо:
Пока платят зарплату или не упало
← →
картман © (2013-05-31 16:07) [18]
> Надо:
> Пока платят зарплату или не упало
собирать бумажные отмазки))
← →
sniknik © (2013-05-31 17:26) [19]> что, кстати, и проще будет.
однозначно проще.
как то давали подобное "задание" для более менее мелкой программы правда... оценил и выдал начальству - сделаю новую за две недели... ответ, не не не, нам новую не нужно, нам эту поправить чтобы не глючило... ок, тогда срок от 2-ух месяцев до полгода, и без гарантии, что уберу "глючность" полностью. задумались, и пока думали, и т.к. задача действительно была мелкая, но нужная написал новую без ТЗ (с саппортом поговорил, для чего, и кому нужно). но блин, начальство после раздумий все таки "выдало" - не нужно новую. эту поправь... а новая к тому времени у клиентов уже три дня как работала...
← →
Anatoly Podgoretsky © (2013-05-31 17:35) [20]clippership (31.05.13 11:01)
Начать с определения строков (не менее 2 лет) и стоимости - тоже много.
← →
Anatoly Podgoretsky © (2013-05-31 17:42) [21]
> "Добрый Сок" (31.05.13 14:25) [15]
Не смеши, в лучшем случае получишь - ты программист, делай все правильно, я в этом не разбираюсь. В худшем случае саботаж и подсиживание.
← →
Anatoly Podgoretsky © (2013-05-31 17:44) [22]Да и насколько хорошо ты сам разбираешься в бизнес процессах?
← →
Dennis I. Komarov © (2013-06-01 13:09) [23]Чет начальство с легкостью пересаживается с 20-летних ВАЗов с заплатками...
← →
Юрий Зотов © (2013-06-01 13:21) [24]> И вот, захотелось мне получить ясную картину того, что сейчас имеется в
> этой системе, чтобы, проанализировав, можно было понять - что здесь
> лишнее или где бизнес-процессы построены из рук вон плохо и их
> необходимо менять.
ИМХО, в данном случае это практически невозможно. По крайней мере, в разумные сроки - то есть, если каким-то чудом даже и удастся сделать, то затраты времени (и, соответственно, денег) будут несоразмерно огромными.
> Ибо глючит программа часто и "не по децки".
А вот это, пожалуй, не так уж и плохо (а возможно, что даже и хорошо). Получаем от юзера конкретный глюк - разбираемся с ним (только с ним, не трогая пока ничего другого) и устраняем. В итоге имеем реверс-инжиниринг как бы "по кускам", а через какое-то время получаем приличную программу.
Время это, конечно, тоже будет не малым. Но оно при таком подходе оправдывается тем, что программа все время продолжает работать, раз уж к ней привыкли.
← →
RDen © (2013-06-01 13:39) [25]Юрий Зотов © (01.06.13 13:21) [24]
Получаем от юзера конкретный глюк
получаем от юзера ответ: глюки возникают различные при различных обстоятельствах
← →
Юрий Зотов © (2013-06-01 13:41) [26]> RDen © (01.06.13 13:39) [25]
Вы слово "конкретный" не прочитали, вероятно.
← →
Dennis I. Komarov © (2013-06-01 13:42) [27]
> В итоге имеем реверс-инжиниринг как бы "по кускам", а через
> какое-то время получаем приличную программу.
Ой, не факт... :)
← →
Юрий Зотов © (2013-06-01 13:47) [28]
> Dennis I. Komarov © (01.06.13 13:42) [27]
По крайней мере, получаем программу:
а). которая работает все более устойчиво, чем исходная;
б). в которой мы уже частично разобрались.
← →
Dennis I. Komarov © (2013-06-01 13:49) [29]
> Приводятся аргументы, которые приводить не буду, но суть
> которых одна :"Мы привыкли и нам ничего не надо"
Не на том языке разговариваете...
← →
Dennis I. Komarov © (2013-06-01 13:52) [30]
> По крайней мере, получаем программу:а). которая работает
> все более устойчиво, чем исходная;б). в которой мы уже частично
> разобрались.
Вы этим будите заниматься, Юрий Сергеевич? Если да, то у меня нет сомнений...
← →
RDen © (2013-06-01 14:07) [31]Юрий Зотов © (01.06.13 13:41) [26]
> RDen © (01.06.13 13:39) [25]
Вы слово "конкретный" не прочитали, вероятно.
тогда это уже не юзер, а вeтатестер с опытом, ибо
>clippership (31.05.13 11:01)
>Ибо глючит программа часто и "не по децки"
← →
RDen © (2013-06-01 14:10) [32]пардон, бета тестер
← →
Юрий Зотов © (2013-06-01 14:27) [33]> Dennis I. Komarov © (01.06.13 13:52) [30]
> Вы этим будите заниматься
Если ничего другого не остается, то придется, деваться некуда. Но, конечно, разбираться в чужом глючном коде огромного размера - задача из серии "Боже упаси".
> RDen © (01.06.13 14:07) [31]
> тогда это уже не юзер, а вeтатестер с опытом
Дык... ведь каждый наш юзер - он ведь тоже тестер. А уж с опытом или без - это как повезет. По крайней мере, он умеет пользоваться программой и знает бизнес-логику - то есть, от него можно получить хоть какие-то сведения о том, что он делал, что получилось и что должно было получиться.
← →
RDen © (2013-06-01 14:58) [34]>Юрий Зотов © (01.06.13 14:27) [33]
ну >clippership (31.05.13 11:01) ничего не сообщает о контингенте юзеров, может там кучка бабушек-одуванчиков, и тогда ваще не получишь ничего внятного.
Попадал в подобную ситуацию- лет 10 без должного бюджета и постоянной сменой коллектива, сторонняя фирма-разработчик, занималась ....хм...
разработкой чего-то (ни мне, не для конторы - не нужным, что я и пытался объяснить руководству), в итоге контора разработчиков накрылась -
предложили продолжать проект мне - еле открестился. Сейчас с улыбкой соболезнования наблюдаю над нанятыми за копейки продолжателями разработки...))
зы. и Вы говорили в [24] - конкретный, а в [33] хоть какие-то сведения
← →
Юрий Зотов © (2013-06-01 15:20) [35]
> RDen © (01.06.13 14:58) [34]
> может там кучка бабушек-одуванчиков,
Видел я одну такую бабушку... дай бог каждому. В программу была встроена "маленькая Delphi" - так эта бабушка свои формы лепила. Разные они, бабушки-то.
Да и не нужно им в компьютерах шарить - вполне достаточно того, что они в своей работе шарят как надо. Причем обычно в своей работе шарят именно бабушки.
> [24] - конкретный, а в [33] хоть какие-то сведения
Так это же и есть конкретика - "что делал, что получилось и что должно было получиться".
← →
RDen © (2013-06-01 15:28) [36]Юрий Зотов © (01.06.13 15:20) [35]
Так это же и есть конкретика - "что делал, что получилось и что должно было получиться".
ну мож быть, просто по описанию ситуации у автора, ошибки возникают не подлежащие однозначной локализации, а это плохо...
← →
Юрий Зотов © (2013-06-01 15:40) [37]
> RDen © (01.06.13 15:28) [36]
> ну мож быть
Все мож быть. Однако, перед ТС стоит конкретная задача и есть конкретные условия, в которых ее надо решать. Выбора у него нет и он только советуется, как лучше это делать.
И не надо гадать на кофейной гуще - мож бабушки, мож дедушки, мож локализуется, мож нет... есть данность, вот и все.
А мож там сплошь одни гениальные девушки?
← →
RDen © (2013-06-01 15:50) [38]Юрий Зотов © (01.06.13 15:40) [37]
да, наверное ТС принял решение)
> "Добрый Сок" (31.05.13 13:10) [9]
> как же поступить?
>Вариантов 3.
>1. Уйти оттуда.
← →
Юрий Зотов © (2013-06-01 16:03) [39]> 1. Уйти оттуда.
Зачем? Лучшего шанса стать незаменимым просто не бывает. А это вкусно.
← →
RDen © (2013-06-01 18:29) [40]нет незаменимых, к сожалению
Страницы: 1 2 3 вся ветка
Форум: "Прочее";
Текущий архив: 2013.12.29;
Скачать: [xml.tar.bz2];
Память: 0.57 MB
Время: 0.003 c