Реинжиниринг торговой системы

← →
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]

нет незаменимых, к сожалению

← →
Юрий Зотов © (2013-06-01 18:32) [41]

> RDen © (01.06.13 18:29) [40]
> нет незаменимых, к сожалению

Когда есть, кем заменить.
:o)

← →
RDen © (2013-06-01 18:56) [42]

Юрий Зотов © (01.06.13 18:32) [41]

> RDen © (01.06.13 18:29) [40]
> нет незаменимых, к сожалению

Когда есть, кем заменить.
:o)

это приятно. Но придётся обучать наработкам

← →
Юрий Зотов © (2013-06-01 20:20) [43]

> RDen © (01.06.13 18:56) [42]

Вот в том-то и дело.

Кто будет обучать? Другой сотрудник, который и сам не все знает?

Сколько времени уйдет на обучение? Какая это потеря времени (и денег, соответственно)?

Могу привести не один пример, когда судьба проекта (если не всей конторы) зависела от одного-двоих человек. И полагаю, что такие примеры могут привести многие из здешних старожилов.

← →
RDen © (2013-06-01 20:27) [44]

Юрий Зотов © (01.06.13 20:20) [43]

Кто будет обучать? Другой сотрудник, который и сам не все знает?

Сколько времени уйдет на обучение? Какая это потеря времени (и денег, соответственно)?

Могу привести не один пример,

да, наверное многие могут привести подобные примеры, но раз уж "схлестнулись", чем закончилось в твоих (Ваших) примерах?

← →
boriskb © (2013-06-01 20:57) [45]

> Так это же и есть конкретика - "что делал, что получилось
> и что должно было получиться".

"Что получилось, то мы и хотели " (с)

← →
Юрий Зотов © (2013-06-01 21:19) [46]

> RDen © (01.06.13 20:27) [44]

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

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

← →
alexdn © (2013-06-02 09:12) [47]

> Юрий Зотов © (01.06.13 21:19) [46]
То что проект может быть привязан только к одному человеку это просто ужасно..

← →
RDen © (2013-06-02 09:37) [48]

alexdn © (02.06.13 09:12) [47]

> Юрий Зотов © (01.06.13 21:19) [46]
То что проект может быть привязан только к одному человеку это просто ужасно..

аха, но зачастую, просто нет вариантов..

← →
Kerk © (2013-06-02 14:27) [49]

> alexdn © (02.06.13 09:12) [47]
>
> > Юрий Зотов © (01.06.13 21:19) [46]
> То что проект может быть привязан только к одному человеку
> это просто ужасно..

иным программистам хочется верить, что можно впрыгнуть в кресло "незаменимости". что это такое, товарищи? это мелкобуржуазное желание стать монополистом своего дела. прав был Маркс, когда писал что мелкая буржуазия мечтает стать буржуазией, капиталистами. вот и здесь мы видим, как иные программисты пытаются нащупать почву для своего мелкого частного монополизма. а ведь мы знаем, товарищи, зачем иным програмистам так нужна монополия - для сверхприбыли! но и не только. как всякий человек, программист стареет, и испытывает страх перед будущим, которое он знает, в капиталистическом мире при утрате способностей к заработку совсем не радужное. но что такие программисты означают для общества? каков вклад таких частных монополий в общественное производство? выгоден ли прогресс общественных производительных сил такому, с позволения сказать, интеллектуалу? нет, товарищи, ему не выгоден прогресс производительных сил. поможет ли такой программист своему коллеге разобраться в своем коде? нет, товарищи, не поможет. а значит для общества такой программист и его знания потеряны. как можно охарактеризовать таких мелкобуржуазных программистов, не вкладывающих свой труд в развитие производительных сил и общественного хозяйства? перефразируя известное изречение товарища Ленина, можно сказать что они не мозг нации, и не сердце, и уж тем более не душа.

← →
Юрий Зотов © (2013-06-02 15:28) [50]

> alexdn © (02.06.13 09:12) [47]
> То что проект может быть привязан только к одному человеку это просто
> ужасно.

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

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

Вот, допустим, ТС с сабжем разобрался, понял, как что работает, поправил глюки. Кто будет поддерживать программу далее? Очевидно, он. Кем его можно будет заменить? Очевидно, без потери времени и денег - некем. Вот и получается, что он стал практически незаменимым, хотя к этому вовсе и не стремился.

Еще один реальный пример - кем можно заменить Диму Тимохова (aka Суслик), если свой совсем немаленький проект он делал практически в одиночку и никто, кроме него, досконально этот проект не знает?

← →
clippership (2013-06-03 12:08) [51]

Ого, сколько сообщение за выходные!
В конторе работают разные люди - и девушки, и бабушки, и юноши, и дедушки. :)
Это магазин и поэтому есть специфика. В зале может находится юная девушка с начальным образованием. Ее научили нажимать на 4 кнопки - и она уже овладела искусством продажи через компьютер. Так что - такие дела. При этом любое самое малое нештатное поведение программы - приводит ее в панику. Спрашивать по телефону: "В чем ошибка?" - не имеет смысла, ответ всегда один: "Ничего не работает."
Сегодня позвонил в одну организацию (СПб), которая занимается решением подобных проблем, за работу только по трассировке БД они берут 5 - 6 млн. рублей (и это только предварительно). Думаю, что смысл теряется, начальство не вложит таких денег, да оно и не надо.
Похоже, идеальный вариант таков:
1. Построить подробный бизнес-процесс всего предприятия в какой-нибудь нотификации
2. Выявить те точки бизнес-процесса, где он пересекается с работой программы
3.Построить отдельные бизнес-процессы тех подразделений, которые работают с программой
4.Проанализировать код и бд, в свете полученных результатов. Можно для помощи использовать какой-нибудь RWin, например.
5.Ну и дальше - оптимизация, как таковая.. Что получится, то получится..

Других способов не вижу пока что, а рассуждения в этой ветке меня в этом просто убеждают.

6. Ну, об этом я говорил уже начальству: необходим тестер. Надо искать кого-нибудь на эту роль. Контора богатая - не разорятся.. :)
А то здесь тестированием разработки занимаются сами разработчики, а это для такой запутанной системы неправильно: в одном месте изменишь - в другом аукнется. Принцип действия закона Ломоносова - Лавуазье очень хорошо демонстрируется на примере этой программы.

← →
clippership (2013-06-03 12:17) [52]

Kerk © (02.06.13 14:27) [49] , в свое время я работал в СПб филиале одного очень-очень-очень крупного банка. Так там был один незаменимый человек, который страдал ярко-выраженной звездной болезнью. Он один знал все пароли от многих ключевых служб и даже серверов... Вот так вот.. И это не какой-нибудь, даже самый крупный, магазин - а один из ведущих банков коммерческих страны... А Вы говорите!!! :D
Cейчас, правда, я знаю, что ситуация в том филиале банка нормализировалась. А то, о чем я написал - происходило в первой пятилетке 2000-х годов...

← →
Inovet © (2013-06-03 12:23) [53]

> [52] clippership (03.06.13 12:17)
> Он один знал все пароли от многих ключевых служб и даже серверов...

Ключник

← →
Jeer © (2013-06-03 12:29) [54]

>за работу только по трассировке БД они берут 5 - 6 млн. рублей

Вот я дурак был..., за месяц составил ER-модель OLAP базы за свои несчастные месячные сребренники :)
Потом за полгода свое приложение нарисовал.

С другой стороны, обеспечил себя работой уже как 7 лет и еще два протянем, а потом на пенсию и в прерии велопутешествовать :)

← →
Юрий Зотов © (2013-06-03 15:15) [55]

> clippership (03.06.13 12:17) [52]
> Он один знал все пароли

Дык...разве это незаменимость? Начальство дает команду, пароли передаются другому сотруднику - и за 10 минут от незаменимости не осталось ничего.

← →
clippership (2013-06-03 15:29) [56]

Юрий Зотов © (03.06.13 15:15) [55] , с одной стороны - да, незаменимых нет.
Не вдаваясь в подробности, скажу, что обстановка там была нездоровая и ближайший начальник боялся этого человека.. Боялся, в смысле том, что если бы он ("незаменимый") ушел, то наступил бы полный крах в работе отдела, а потом и филиала. Парень то был, действительно, талантливый, но зазвездившийся: всех поставил в зависимость от себя.
Как добился этого не знаю, я проработал там всего 11 месяцев и ушел, не в последнюю очередь из-за "теплых" отношений царивших внутри коллектива.

← →
clippership (2013-06-03 15:40) [57]

> TUser © (31.05.13 14:20) [13]
> Я бы еще предложил написать и зарегистрировать официальную
> служебную записку с описанием проблемы и негативного прогноза
> и своих вариантов решения (все переписать, наняв для этого
> профессиональную контору, и не на Delphi).

Прототип подобной записки я уже писал начальству, но Вы правы - стОит написать о всех грядущих бедах. Единственно, что думаю - разницы нет - Delphi или не Delphi. Собственно, как корпоративное клиент-серверное приложение - инструмент разработки Delphi является оптимальным.
Будем надеяться на Embarcadero, авось они вытянут Дельфи из того места, где она сейчас находится.
Писать торговую клиент-серверную систему на C# или Java, по сравнению с Delphi - это, конечно, круче, но попахивает садомазохизмом. Это мое мнение. Каждая средство разработки - хорошо для своих нужд. :)
Только не хотелось бы развивать набившую оскомину тему, которая длиться еще с 90-х годов : сначала - "Что круче Дельфи или С++", теперь чаще спорят о крутизне "С# и Дельфи".
А на самом деле все зависит от прокладки между сидением и монитором компьютера, где средство разработки остается всего лишь средством разработки. Главное выбрать, чтобы средство было оптимальным для решения конкретной задачи.
Каждый остается при своем мнении.

← →
Юрий Зотов © (2013-06-03 16:02) [58]

> clippership (03.06.13 15:29) [56]

> если бы он ("незаменимый") ушел, то наступил бы полный крах в работе
> отдела, а потом и филиала.

Значит, на тот момен он действительно был незаменимым, от факта никуда не денешься.

> Парень то был, действительно, талантливый, но зазвездившийся: всех
> поставил в зависимость от себя.

А это уже от человека зависит. Вот Вы тоже, вполне возможно, станете незаменимым - как Вы себя поведете?
:o)

← →
"Добрый Сок" (2013-06-03 16:23) [59]

> Вот Вы тоже, вполне возможно, станете незаменимым - как
> Вы себя поведете?

С ноги заходить во все кабинеты? :o)
Пока не попадется кабинет, где дверь наружу открывается :)

← →
clippership (2013-06-03 18:32) [60]

"Добрый Сок" (03.06.13 16:23) [59] , :))))))))))))))))))))))))))))))))))

← →
clippership (2013-06-03 18:34) [61]

> Юрий Зотов © (03.06.13 16:02) [58]
> Вот Вы тоже, вполне возможно, станете незаменимым - как
> Вы себя поведете?

Честно говоря, не хотелось бы быть незаменимым. Скромная должность технического директора меня бы устроила :))))))))))))))))))))))))))))))

> clippership (03.06.13 18:34) [61]
> Честно говоря, не хотелось бы быть незаменимым.

А куда Вы денетесь? Вот разберетесь с сабжем - и готово, само собой.

> Прототип подобной записки я уже писал начальству, но Вы
> правы - стОит написать о всех грядущих бедах.

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

А за

> Это магазин и поэтому есть специфика. В зале может находится
> юная девушка с начальным образованием. Ее научили нажимать
> на 4 кнопки - и она уже овладела искусством продажи через
> компьютер. Так что - такие дела. При этом любое самое малое
> нештатное поведение программы - приводит ее в панику. Спрашивать
> по телефону: "В чем ошибка?" - не имеет смысла, ответ всегда
> один: "Ничего не работает. "Сегодня позвонил в одну организацию
> (СПб), которая занимается решением подобных проблем, за
> работу только по трассировке БД они берут 5 - 6 млн. рублей
> (и это только предварительно).

начальство Вас отправит куда подальше и правильно сделает
P.S. "Мы привыкли" - это не аргумент.

← →
знайка (2013-06-03 19:10) [64]

> Стоит провести анализ состояния системы, вычислить вероятности
> и стоимость ошибок, затраты на устранение, вероятность наступления
> события и т.д. и т.п.
и тут же, не начав читать, спросят: нафик все это делал, кто просил? и впарят куда и сколько надо, и правы будут.. :)

← →
clippership (2013-06-03 19:11) [65]

Почему-то мне кажется, что для этого

> анализ состояния системы, вычислить вероятности
> > и стоимость ошибок, затраты на устранение, вероятность
> наступления
> > события

придется досконально изучить программу. Тогда уже легче будет ошибки исправить, а не

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

← →
robt5 (2013-06-03 22:01) [67]

просто будь готов послать все в ж. и уволиться в любое время - станет легче

← →
cloppership (2013-06-03 23:38) [68]

> robt5 (03.06.13 22:01) [67]

Вариант не исключен :)

← →
ТимоховД (2013-06-04 13:20) [69]

раз тут Юрий Сергееич меня упомянул, выскажусь...

1. Рефактор - офигенный материал для прокачки скилов. Я как математик по образованию и, к сожалению, только немного по сути чтобы в чем-то разобраться строю общую картинку, в которой есть слова: "знает", "обращается", "врапит" (оборачивает). К сожалению я лично не знаю серебряной пули в части тех. средств, я лично пока не "забью" в голову тему не могу ничего придумать. Поэтому - стараюсь с аспектами (частными) своей же системы (плюс часть от другого программиста - за десять лет и 1млн строк свой код равен чужому) разбираться глубоко. Тогда и можно реинжиниринг сделать. Все объять не стараюсь - незя это.

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

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

Мораль пункта - на рефактор нужно время.

3. В общем, общий совет - рефактори по чуть-чуть затрагиваемые аспекты системы, прокачивай скилы, получай ЗП, ставь заплатки (с возможным частным рефактором). Все отрефакторить не выйдет все равно. Как говорит наш руководитель проекта - как ни пиши (правильно или коряво), все равно - это те же яйки, только вид сбоку. Речь о том, что предметная (бизнес) сложность от красивого кода и архитектуры никуда не уйдет. Все равно каждая предметная (бизнес) логика стоит определенного времени, а если объять твою систему и помножить на время разработки, то выйдет N лет.

4. Моя личная позиция в части своей системы:
а. Я хочу делать качественный продукт. Поэтому стараюсь модернизировать темы, которые мне мешают отвечать за результат.
б. Большое Г, если оно работает и все же поддается анализу, я стараюсь не трогать. Оборачиваю документацией, которая А) поясняет, почему это Г сделано именно так, как сделано и Б) что надо сделать (когда-то) с этим Г, чтобы оно перестало быть Г.

И еще, хоть у меня и уникальная отчасти ситуация, и хоть я и владею кодом и могу сам выделять время на рефактор - мне не удалось пока сделать из системы конфетку. Все равно, есть пласты, которые хочется переписать нафиг.

Мораль - ставить задачу все отрефакторить - дело гиблое.

← →
ТимоховД (2013-06-04 13:20) [70]

> и тут же, не начав читать, спросят: нафик все это делал,
> кто просил? и впарят куда и сколько надо, и правы будут.
> . :)

Не исключено, что такое поведение возможно, тут многое зависит от личных качеств, целей и ситуации, но вот вопрос, а в чем они будут правы?

← →
знайка (2013-06-05 00:19) [72]

в том что человек вместо того чтобы делать то, что ему говорят, занимается не пойми чем, мало?
за такое уволить мало :)

1. Мне удалось, сделать реинжиринг довольно сложной системы - но только БД (исходного кода не было).
2. Запустить процесс одновременной работы двух систем над одной БД - изначальной и своей.
3. Удалось перевести работу тысяч пользователей на свою систему относительно безболезненно.
Отчасти, это связано с новым, созданным и интуитивно понятным даже "бабушкам" интерфейсом.
4. Удалось исключить рутинную работу пользователей в части интеграции данных.
5. Удалось исключить многократную закупку для пользователей пакетов типа "Статистика" или SPSS. ( в систему добавлен функционал фильтрации данных, регрессионого анализа, прогнозирования..)

Это личный опыт - наверняка он не поможет, но идеи должны быть понятны.

> знайка (05.06.13 00:19) [72]
> в том что человек вместо того чтобы делать то, что ему говорят,
> занимается не пойми чем, мало?
> за такое уволить мало :)

У Вас замечательный менеджмент...

Кроме того это первая стадия задачи, которую автору поручили.

Разумеется она могла быть выполнена другими, в чем я сильно сомниваюсь.
А принятие решение на основе "мы так привыкли", просто недопустимо.

P.S. Вопрос был другой...

← →
знайка (2013-06-05 10:05) [75]

При чем тут наш менеджмент? о_О

> Кроме того это первая стадия задачи, которую автору поручили.
из топика, а точнее - вот тут:

> И вот, захотелось мне получить ясную картину того, что сейчас
> имеется в этой системе, чтобы, проанализировав, можно было
> понять - что здесь лишнее или где бизнес-процессы построены
> из рук вон плохо и их необходимо менять.
> Задача нетривиальная, здесь скорее
> нужен специалист, который имеет опыт по реинженирингу. Сразу
> скажу - переписать систему с нуля нельзя. Но, вот, начальство
> может не пойти на то, чтобы нанять специалиста, поэтому
> надо попробовать для начала самому.
ни о каких поручений речи нет, просто автору захотелось не то что ему поручили.

> за такое уволить мало :)
причем увольнять нужно того кто "не понимает" в основном...
блин, да большинство задач которыми занимаюсь с точки зрения начальства это "не пойми чем", но без них "все встанет". а вот то, что они говорят делать зачастую = "немедленное убийство" программы/процесса.

> просто автору захотелось не то что ему поручили.
а что у него по должностным обязанностям? может как раз управление/поддержка вот того самого рабочего процесса. или он вообще за "идею" свое свободное время?

вообще, делать только то что сказали, и именно так как сказали называется "итальянская забастовка".

← →
знайка (2013-06-05 10:24) [77]

"страной может руководить даже кухарка", тут не о чем даже спорить :)

← →
знайка (2013-06-05 10:29) [78]

> а что у него по должностным обязанностям?
откуда мне это знать? я лишь вижу из его темы, что его об этом не просили, по крайней мере в топике нигде об этом упоминаний нет
хотите узнать про должностным обязанностям автора? наверное лучше спросить у него самого

> "страной может руководить даже кухарка", тут не о чем даже спорить :)
не нужно цитировать неправильно, в оригинале смысл обратный.

> я лишь вижу из его темы, что его об этом не просили
так же видно что он этим хочет заняться... и нигде нет упоминаний о запрете на это, значит "право имеет"? нет?

> хотите узнать про должностным обязанностям автора?
мне то зачем? ты делаешь выводы на "пустом месте". мне пофигу на его обязанности, и просили его это делать или нет.

← →
Аббат Пиккола (2013-06-05 11:34) [81]

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

После того, как станет ясно, кто как работает и кто чего хочет, можно уже сформулировать проблемы и принимать какие-то решения. Прежде всего нужно будет все проблемы упорядочить по приоритету (срочности и необходимости).

Дальше уже смотреть в имеющуюся реализацию.

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

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

← →
clippership (2013-06-06 00:01) [82]

Аббат Пиккола (05.06.13 11:34) [81], читаете мои мысли. Именно этим я и начал заниматься.
=================================
Отвечу на некоторые высказывания, которые напечатаны выше. По моим должностным обязанностям, одним из пунктов значится положение, что я обязан поддерживать работоспособность системы. В том виде, котором система сейчас существует - это заведомое усугубление проблемы, которая рано или поздно (скорее рано) загонит меня в угол. Программа и бд весьма заковыристые, и очень много времени и сил уходит на то, чтобы поддерживать их в рабочем состоянии, а так быть не должно. Хорошо написанный и отлаженный программный комплекс должен давать сбои нечасто. Последний крупный проект, который я писал на прежней работе, был отлажен, можно сказать - до нормального рабочего состояния. При интенсивной загрузке пользователями - последняя ошибка по тому проекту проявилась года полтора назад (спасибо разработчикам, аналитикам и тестерам за безупречную работу :) ), причем не по вине программы, а из-за того, что изменились маршрутизаторы на АТС (в программу был встроен упрощенный call - центр на основе Avaya ATC). Когда меня просили что-то в той системе добавить или изменить - в прямом смысле приходилосьь вспоминать, что да как работает, так как изначально все было продумано.
Та программа, которую я имею счастье обслуживать сейчас - не дает забывать о себе никогда, а я так не привык. Так что переработать программулю и сделать ее менее глючной - в моих интересах. Порой диву даешься: программе 20 лет, а ошибки валятся, будто она сейчас проходит бета-тестирование.. Это ли не безобразие, я Вас спрашиваю? :)

>Это ли не безобразие, я Вас спрашиваю? :)

Чем система проще, тем ближе к идеалу:)

← →
clippership (2013-06-06 11:00) [84]

> Чем система проще, тем ближе к идеалу:)

Это точно. Самая идеальная программа называется:"Hello world" :)

← →
cippership (2013-07-09 14:03) [85]

Таки, решил я уйти все-таки... Нашел работу, более подходящую мне по всем критериям.
Теперь вакансия открыта. Кто хочет заменить меня - прошу писать на e-mail, подробности сообщу.
Можно выбить зарплату, в принципе приличную для программиста Delphi в СПб.
Работа рядом со ст. м. "Нарвская".

Надеюсь - это правильное решение, тем более, что и форум тутошний тебя ненавязчиво к нему подталкивал.

← →
cippership (2013-07-10 19:18) [87]

Надеюсь, что правильное... Организация солидная, з/п белая и вполне приличная для СПб.
Теперь это IP-телефония, С#, Delphi, Oracle, MS SQL, JScript...
Видимо скоро придется открывать тему "Управление Alcatel АТС" в связке с Delphi. С Avaya опыт имею, но новый работодатель хочет такое же, но "с перламутровыми пуговицами", то есть с Alcatel

Отлично!
"Чем больше Жизнь предлагает разнообразие - тем разнообразнее становится Мыслитель"
(С) Jeer

P.S.
Скинь на мой email (algcom@mail.ru) свои контакты - надо поговорить о младшем поколении:)
Да и ваще - по жизни тоже можно.

Реинжиниринг торговой системы Найти похожие ветки