LINUX.ORG.RU
ФорумTalks

итак, все что вы хотели знать про банки, но боялись спросить.

 , , ,


1

1

тезис: банк --- это сурово, это надолго, это круто и хоть как-то стабильно. некоторые думают что там можно нарубить много бабла и там огромные зарплаты.

применительно к тематике форума, некоторые думают что там крутые спецы, там поставлен техпроцесс, там можно «развиваться»...

парни, все это фуфло :)

нет, это ненадолго. точно такие же сокращения, точно так же «оптимизируют», все как у людей.

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

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

ну и конечно ИТ :)

нет, там спецы не крутые. они... не сказать что спецы. «спец» там может быть один, в лучшем случае, и обычно он начальник отдела. или даже начальник запросто может быть «ни в зуб ногой», тогда все совсем печально.

«безопасники» не в состоянии отследить свои же сертификаты, сертификаты для общения со сторонними системамы. админы понятия не имеют кто когда и для чего запросил тот или иной сервер. слова bash, sed, grep, awk вгоняет в ступор, хотя основные сервера на aix-e. программисты... на собеседовании дается задание: бинарный поиск. справляется один из 10, а то и из 15-ти... посчитать сумму диагоналей матрицы вообще за гранью.

и вот со всей этой фигней банк пытается взлететь :)

банк --- это такая очень консервативная и замкнутая экосистема. говоря про российские банки --- это экосистема, которая вертится вокруг.... java? а вот херЪ )). она на 80% вертится вокруг ibso. ее пытаются выкинуть, но...

это совершенно никому не знакомый и ненужный язык PL+, эдакий sql на стероидах. с костылями, без документации, с закрытыми пакетами и кучей магии. велкам :). модель разработки такова, что предполагает бинарные накаты на боевые сервера, потому что «diff» он не диф, а mdb со структурой, которая просто перетирает то что было, этому на всякой случай «то, что было», сохраняется в old.mdb :)

все инструменты разработки, если это убожество можно назвать инструментами, самопальные, естественно кривые и чудовищные.

масса вещей, купленных банком, написана на каких чудовищных самопальных языках с самопальными же компиляторами.

вот все эти ужасы: в таблицах поля-блобы с таблицами внутри, сервисы, которые стартуют в cmd и не дай б-же кому-то разлогиниться, совершенно фееричные админы систем, которые просто от нефиг делать на бою могут поменять значение настройки с «3» на «8» и у тут же отваливается процессинг... все это цветет и пахнет.

ну... что было понятно. вместо ИДЕ там есть в лучшем случае «блокнот». никакой не gedit, не вим и ничего подобного. блокнот. но даже этот блокнот контора, которая продала в банк ПО, может написать плохо и с феерическими багами: если где-то встретился таб где ждали пробел, эта радость курсор будет рисовать не так где положено. поэтому открывать сырцы сторонними редакторами может быть опасно для психики )).

процедуры по тысяче строк? запросто.

копипасты этих тысяч строк из модуля в модуль? да как нефиг нафиг.

ну просто потому что такая культура разработки. поменять поля в 80-ти однотипных табличках? кто-то сказал «скрипт»? нет, в банке принято засучить рукава и отдолбить, с недельку.

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

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

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

★★★★

Последнее исправление: Rastafarra (всего исправлений: 1)
Ответ на: комментарий от pacify

Назови хотя бы одну гос.организацию России, где такая вещь используется. Я имею ввиду, отечественную разработку.

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

anonymous-
()
Ответ на: комментарий от dmxrand

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

Iron_Bug ★★★★★
()
Последнее исправление: Iron_Bug (всего исправлений: 1)
Ответ на: комментарий от n_play

Обожаю крайности. Но хочется получить примеры организаций с ОБЯЗАТЕЛЬНЫМИ костюмами (униформа, униформе рознь) которые не гавно.

dmxrand
()
Ответ на: комментарий от n_play

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

Iron_Bug ★★★★★
()
Ответ на: комментарий от Rastafarra

tl/dr? :)

не перевелись ещё на лоруси линуксоиды с кешем 512байт!

darkenshvein ★★★★★
()
Ответ на: комментарий от Iron_Bug

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

1) При создании системы нужно закладывать возможность расширения. Например взять СУБД. Все очень любят noSQL потому, что можно на ходу пополнять или менять схему. Я сейчас пишу маленький магазинчик и в многих сущностях у меня есть поле куда можно положить JSON. Тут кстати привет Zope.

2) Часто возникает соблазн подоткнуть костыль. Надо понимать когда система проектировалась под одни реалии, а от них не осталось НИЧЕГО и пора делать другую (собственно если она на 50% выпала, то пора).

3) Что понимает или не понимает начальство не важно. Собственно о том и идет речь, что ИТ спецы как рыбы. Сидят и слова не скажут. Их в авгиевы конюшни привели, они тяжело вздохнули и ку-ку. Мы видим уровень банковских спецов. Это результат процесса вымывания кадров.

dmxrand
()
Ответ на: комментарий от dmxrand

Ты знаешь даже на фокс про писались вполне вменяемые проект.

Под те задачи.

Сейчас их не осталось конечно, но именно потому, что они были вменяемые.

Неа, потому что задачи изменились. Прежний инструментарий не позволял удовлетворить новые требования.

Вполне можно было потихоньку апгрейдить не ломая всю структуру.

Нельзя. Потому и отказались.

Структура осталась, а фокспро нет.

Да не осталось ничего от прежнего. Кроме воспоминаний о славных 90-х.

anonymous-
()
Ответ на: комментарий от Iron_Bug

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

1) Есть владелец. Он видит или ему доложили... (ваоиант владелец идиот не хочу рассматривать). Он теряет бабки... Значит часть финансов вложит в выращивание другой коровы или апгрейда этой все зависит от того что дороже.

2) Нет владельца. Отложим на потом. Может завтра опять клевер будет, да и я тут не вечно сижу. А выращивать корову это терять прибыль сегодня (а у нас процент - да? кстати есть способы лишить процента и сохранить вовлеченность).

dmxrand
()
Ответ на: комментарий от anonymous-

Под те задачи.

Задача могла сохранится. Например я видел систему учета пациентов в больнице написанную на Clipper. Задача сохранилась.

Неа, потому что задачи изменились. Прежний инструментарий не позволял удовлетворить новые требования.

Задача сохранилась. Но поменялось оборудование и появились выгодные технологии.

Нельзя. Потому и отказались.

Можно. структуры баз остались похожими, а сама система из Clipper прошла уже делфи и теперь веб.

dmxrand
()
Ответ на: комментарий от dmxrand

Значит плохая архитектура.

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

Я конечно не буду пихать пиксельные шейдеры в бухгалтерскую программу, но много вещей сейчас И НЕ ХОТЯТ предусматривать.

Где-то не хотят — бывает и такое. Но дело в том, что даже если ты найдёшь Самого Умного и Предусмотрительного спеца, даже он не гарантирует от того, что не появится нечто, что невозможно будет красиво впихнуть в имеющееся. Увы, предугадывать будущее со 100% гарантией мы пока не умеем.

anonymous-
()
Ответ на: комментарий от dmxrand

ты рассматриваешь маленький промежуток времени. а если та СУБД, под которую ты писал всю свою программу, через десять лет вдруг просто перестала существовать, как класс? а если сменились все технологии и парадигмы, которые когда-то были в тренде, а потом вдруг вообще исчезли? а если нужна поддержка на огромном количестве разных платформ, причём от новейших мэйнфреймов до совсем древних компов в каких-то деревнях? вот пример - обслуживание сетевого обмена для Сбера. я этого монстра поддерживала одно время. эта хрень работала на миллионах серверов по всей стране. причём «сервер» - понятие очень относительное. это мог быть i486 c NT 4.0. а мог быть интелловский новейший холодильник в каком-нить мощном дата-центре. и всё это должно было работать. причём где-то сеть была 24 часа в сутки, а где-то её подключали через модем на час, например. и всё это надо было дорабатывать и сопровождать, при постоянно меняющихся библиотеках, всяких обновлениях, плюс новые требования заказчиков, плюс интеграция во все мыслимые и немыслимые интерфейсы от отправки отчётов в формате, который понимает какой-нить аутглюк, до внедрения элементов управления в системную панель управления (причём их там много разных версий и они разные). это невозможно сделать универсально. это страшный и очень объёмный код, покрытый ifdef'ами.

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

Iron_Bug ★★★★★
()
Последнее исправление: Iron_Bug (всего исправлений: 1)
Ответ на: комментарий от Iron_Bug

в костюмах должны ходить даже технические спецы

Кстати да, в банках часто ИТ-специалисты выглядят солиднее большинства остальных сотрудников.

winlook38 ★★
()
Ответ на: комментарий от winlook38

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

Iron_Bug ★★★★★
()
Ответ на: комментарий от Iron_Bug

банк - это приход на работу ровно в 8, как дурак, причём не в нормальной футболке и джинсах, а в костюме и галстуке-удавке.

ну тут вольность допускается. лично я ходил в джинсах и майке, у нас был спец.ящик с бухлом и не возбранялось...

но это так, девиация :)

Rastafarra ★★★★
() автор топика
Ответ на: комментарий от Iron_Bug

ты рассматриваешь маленький промежуток времени. а если та СУБД, под которую ты писал всю свою программу, через десять лет вдруг просто перестала существовать, как класс?

Так она и перестала. Были dbf файлы. Теперь постгрес. А был фаербед.

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

Эта та самая досовская штукенция? ТЭКОС? Дык обычный UUCP собственно надо было взять что, то типа REX400 и на него переползти потихоньку.

это невозможно сделать универсально. это страшный и очень объёмный код, покрытый ifdef'ами.

Это делается с помощью интерфейсов и адаптерами. Я сам такое делал. У меня была программа обмена данными с клиентами. У нас была самописная система (которую в головном офисе писали бараны), а у клиентов 1000 разных конфигураций 1С, несколько самоделок и вообще эксель. Вот тут я сначала дымился, а потом вычитал про адаптеры и все.

dmxrand
()
Ответ на: комментарий от dmxrand

Все очень любят noSQL потому, что можно на ходу пополнять или менять схему.

Это потому что

Я сейчас пишу
маленький магазинчик

NoSQL удобно когда ты только пишешь/проектируешь и когда у тебя маленький магазинчик. В остальном NoSQL должны применяться там, где модель данных соответствует модели данных, реализуемой СУБД.

на 50% выпала

Не бывает такого. Требования не меняются так кардинально, но бывает дисбаланс: требование небольшое, а влияние на архитектуру большое.

Мы видим уровень банковских спецов

Они на нормальном уровне, на своем, не сравнивай их с разработчиками.

winlook38 ★★
()
Ответ на: комментарий от winlook38

NoSQL удобно когда ты только пишешь/проектируешь и когда у тебя маленький магазинчик.

Я не использую NoSQL...

Требования не меняются так кардинально

Не, не не. Вот тут уже я делаю оценку КАК требование поменялось. Если был текст, а он превратился в видео - требование изменилось кардинально. Правило такое оценку дает тот кому делать.

Они на нормальном уровне.

Тебе виднее. Когда в банках ИТ спец будет знать что такое URL я буду рад этому.

dmxrand
()
Ответ на: комментарий от dmxrand

Эта та самая досовская штукенция? ТЭКОС?

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

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

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

Iron_Bug ★★★★★
()
Ответ на: комментарий от dmxrand

1) При создании системы нужно закладывать возможность расширения.

Ежу понятно. Вопрос в том, каков у нас горизонт прогнозирования изменений? Насколько быстро развивается предметная область — от этого зависит закладываемая расширяемость. Нужен баланс. С одной стороны, расширяемость удешевляет сопровождение. С другой — удорожает разработку. Соответственно, чем быстрее на момент проектирования развивается предметная область, тем меньше закладываем возможностей для расширения. Понимаю, на первый взгляд вывод звучит абсурдно. Но если хорошо подумать, то всё логично: очень быстро появится нечто невпихуемое, и всё равно придётся всё перекраивать, т.е. доп.затраты на расширяемость не окупятся.

2) Часто возникает соблазн подоткнуть костыль. Надо понимать когда система проектировалась под одни реалии, а от них не осталось НИЧЕГО и пора делать другую (собственно если она на 50% выпала, то пора).

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

3) Что понимает или не понимает начальство не важно. Собственно о том и идет речь, что ИТ спецы как рыбы. Сидят и слова не скажут. Их в авгиевы конюшни привели, они тяжело вздохнули и ку-ку.

Миром рулят деньги. Увы. Не красота программной архитектуры. Любое начальство соизмеряет затраты на перепроектирование и получаемые в результате этого ништяки. Если рыночная стоимость ништяков меньше себестоимости перепроектирования, начальство будет против. А если оно будет за, то ты первый будешь недоволен — тем, что тебе зарплату не платят (потому что не из чего).

anonymous-
()
Ответ на: комментарий от dmxrand

в многих сущностях у меня есть поле куда можно положить JSON

Очень реляционно, ага.
Ну я, кстати, понимаю откуда такое желание. Как раз от невозможности предусмотреть все возможные варианты развития. Но ты зря думаешь, что такой хитрый и всех обманул. Этот подход работает когда тебе нужно в конкретном случае дополнить/перекрыть дефолтное поведение. У нас такой же подход используется. Так вот, когда им начинают злоупотреблять, чтобы не заморачиваться проектированием (это же так сложно добавить колонку, а вдруг потом передумаем), это приводит к негативным последствиям. В нашем случае около 1 процента от общей нагрузки на сервер приходится на сериализацию/десериализацию этого «nosql».

winlook38 ★★
()
Ответ на: комментарий от Iron_Bug

вопрос поддержки таких систем всегда в том, что невозможно протестировать софт на всех конфигурациях.

О да. Но кстати! Это очень важно я за все время работы в банка НИ разу не видел функционального тестирования. Помню как переходили на новый формат обмена с ЦБ году так в 2004. Приехал чувак с МСК (отличный кадр). Мы с ним на паскакале написали конвертер из Diasoft в новый формат (Диасофт выкатил бешеную сумму за доработку, а у нас было в области пара их пользователей и потому типа бесплатно не будем делать). Тип уехал. Я для разминки на Python написал свою версию. До запуска в промышленную эксплуатацию остается неделя. Ссыкотно (там миллиарды бабла будут через твою софтину бегать). И тут местный ЦБ присылает бумазейку. Мы тут немного поменяли. Ну ладно поля местами поменяли (зачем, ну ладно). Но вот теперь это поле стало тремя разными, да еще с условиями типа если так, то это поле означает это, а иначе то.... И на 50 страниц. Короче кончилось, что ребята из ФондСервисБанка пришли ко мне взяли мой конвертер на Python потому, что не успевали переписать свой конвертер на FoxPro. Потом они им пользовались лет 5 точно. 1 раз поле сумма у них переполнилось и они не могли отправить сколько то там миллиардов. Исправил аз 15 минут.

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

Ну так о том и речь, что программист НЕ ДОЛЖЕН готовить указ. Ну вот не должен. И если кто не организовал процесс....

мы в обход официальных инструкций хоть как-то тестировали новые версии. и когда появлялась уверенность

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

такой крупнокалиберный софт можно переделывать только глобально.

Как пример такой крупной системы - это интернет. Да он не идеален, но его делали нженеры. И он работает. Что нельзя сказать о куче систем которые делали менеджеры.

dmxrand
()
Ответ на: комментарий от winlook38

Очень реляционно, ага.

А что? Например надо вот этот товар пометить красненьким. Поиск по этому полю осуществлятся не будет (хотя в PG можно). А если нужно будет организовать поиск будет индексная таблица в которую данные будет класть триггер или процедура работающая по расписанию.

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

Эээээ стоп стоп.

В нашем случае около 1 процента от общей нагрузки на сервер приходится на сериализацию/десериализацию этого «nosql».

Я про это часто говорю. Особенно с монгой это клево. Мы берем из базы JSON десиреализуем его, работаем СЕРИАЛИЗУЕМ В JSON и отдаем на фронт. Получаем с ФРОНТА JSON ДЕСИАРИЛИЗУЕМ, работаем СЕРИАЛИЗУЕМ в JSON и отдаем в базу.

А знаешь что? Я выше СОЛГАЛ... мы ничего не СИРЕАЛИЗУЕМ и не ДЕСИАРИЛЕЗУЕМ в JSON. Мы работаем со строками! И классно получить из базы документ (слава богу в монге можно указать поля) с 9000 полями и использовать 2.

dmxrand
()
Ответ на: комментарий от dmxrand

Кстати тут мы и приходим к разнице предприятия у которого есть хозяин и предприятия у которого нет хозяина.

Хозяин (собственник) есть всегда и у всего. Вопрос в том, насколько он эффективен. Государство как собственник по эффективности проигрывает частнику (не всегда, но как правило). Будет ли у нас замена государства на частника? Нет, не будет. Потому что нашему обществу нужна не эффективность с её рисками, а гарантии, что ему (обществу) не дадут помереть с голоду.

anonymous-
()
Ответ на: комментарий от dmxrand

да, и требования ЦБ туда же. и всякая там постоянно меняющаяся отчётность. изменения у такого софта есть всегда, даже если они никому не нужны.

программист указ не готовит. за этим начальство обращается к начальству Сбера, например. с официальными бумагами и объяснительными записками, почему надо выпускать новую версию. это же не просто посты юзера «а у меня не работает» в багтрекере. каждый отчёт о багах и глюках печатается на листе, на него ставится огромная печать и вот это барахло прилетает начальнику. а он уже идёт стучать по голове программисту. у меня был случай, причём случилось это перед новым годом как раз, декабрь, число так 25-27. вдруг в одном отделении перестал работать наш софт. просто так, без всяких видимых причин. я пытала админов: что делали? стандартный ответ: ничего не делали! меня выгоняли на работу чуть ли не круглосуточно, весь мозг выели и нервов кучу испортили. и главное, что у нас на тестовых серверах глюк не воспроизводился. я дошла до удалённой отладки через кучу проксей на машине клиента. убила массу времени на то, чтобы понять, что там могло покриветь. а оказалось что? оказалось, мелкософт выпустил глючную библиотеку математических функций и выкатил её с каким-то апдейтом, причём апдейт вообще был для осла, какой-то такой маловажный. но он подменял системную плюсовую библиотеку. админы апдейт накатили, библиотека обновилась, математика сломалась, отчёты перестали сходиться, банковский сервис встал. перед новым годом. меня чуть не убили в процессе, орали, что я там накосячила. потом оказалось, что вот такая вот лажа от мелкософта. убрали апдейт - всё заработало. но сколько нервов тогда испортили - страшно вспоминать.

Iron_Bug ★★★★★
()
Последнее исправление: Iron_Bug (всего исправлений: 1)
Ответ на: комментарий от dmxrand

Задача сохранилась. Но поменялось оборудование и появились выгодные технологии.

Что есть задача? Если «обеспечить бухше возможность выполнения её работы» — то да, задача неизменна. Но это с точки зрения бухши. А с т.з. программиста задача поменялась. Раньше нужно было, чтобы каждая бухша на своём компе учитывала движение материалов. А потом объединили в сеть филиалы, и потребовалось делать то же самое централизованно. Это изменение задачи с т.з. программиста.

anonymous-
()
Ответ на: комментарий от Iron_Bug

Давай так. Мы обсуждаем как есть или как быть должно? В конце концов если какойнибудь Трамп увидит, что из-за «туда-сюда» ЦБ его банк теряет миллиарды - он заплатит сенатору и руководитель ЦБ улетит. А возможно десяток трампов подадут в суд с требованием компенсировать потери из-з чрезмерных и глупых требований ЦБ. В принципе такое реально.

Ну и про работалио и сломалось. ФУНКЦИОНАЛЬНЫЕ ТЕСТЫ.

dmxrand
()
Ответ на: комментарий от anonymous-

Блин. Давай так. Я вот сам прошел по всем этим граблям. Вот тебе пример. я магазинчик пишу в рамках обучения. Делаем корзину. ID заказа клиента какой тип? Из 8 человек (в том числе профессиональные программисты) 8 ответили Integer автоинкремент. Ну чтож. Приплыли.

dmxrand
()
Ответ на: комментарий от dmxrand

я просто рассказываю, как оно бывает. конечно, большинство проектов до такого размаха никогда не дорастут (и это хорошо для программистов). но всё-таки есть вещи, которые от программиста никак не зависят, заранее предвидеть и учесть их никак нельзя и поэтому создать идеальный софт в вакууме не получится. и это ещё мы не обсуждали то, что требования к интерфейсам и форматам могут тоже быть заданы заказчиком. и архитектор системы оказывается зажат в тесные рамки всяких ГОСТов и прочих мамонтячьих говен. плюс производительность. например, в большинстве проектов я не работала со строками, потому что это непозволительная растрата ресурсов. да, это может быть удобно программисту, но не проканает по причинам чисто техническим. так что хорошо, когда ты можешь использовать любые технологии и любые форматы и не упираться в потолок железа. но это не всегда так.

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

Iron_Bug ★★★★★
()
Последнее исправление: Iron_Bug (всего исправлений: 3)
Ответ на: комментарий от dmxrand

я за все время работы в банка НИ разу не видел функционального тестирования.

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

Rastafarra ★★★★
() автор топика
Ответ на: комментарий от Iron_Bug

я просто рассказываю, как оно бывает.

Вот потому я и говорю, что это спор ниочем (даже не спор это).

Я когда работал в Сбере всегда говорил, что нам отрубили ноги и заставили бежать стометровку. Даже в таком случае можно работать если руководство понимает КАКИЕ это сложности и с уважением относится к труду. Конечно получая 35 т.р. в месяц прикольно видеть менеджера с ЗП в 100т.р. с часами за 50т.р. который в обеденный перерыв бежит от входа с кастрюлей шашлыков, а через час на митинге сообщает тебе что «нас не интересуют проблемы - нам нужно решение, за это мы вам и платим деньги. В конце концов бизнес для ИТ или ИТ для бизнеса?» Ооок говорю я. Хотите так - пусть будет так. И да я знаю как решить проблему. И да я могу сократить расходы банка в 80 раз. Только вот в конце квартала мне от этого не упадет...

dmxrand
()
Ответ на: комментарий от dmxrand

И да я знаю как решить проблему. И да я могу сократить расходы банка в 80 раз. Только вот в конце квартала мне от этого не упадет...

вот так и начинается профессиональная деградация

alpha ★★★★★
()
Ответ на: комментарий от Rastafarra

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

Не делайте мне смешно. Я участвовал в двух слияниях террбанков. И сам был участником и тестером несколько раз. Знаешь как это делается? Ты приходишь на работу в 9 утра и уходишь в 9 вечера. С Москвы приходит бумазейка, что вот мы меняем АРМ и вы должны его протестировать и предоставить отчет с результатами. Но нельзя сказать, что ты с 9 до 9 сидишь и смотришь кино (кстати у нас был отдел у которого плазма на стене и они смотрели там кино). Итак у тебя есть задачи. И тут еще вот это. Ооок говоришь ты запускаешь новый АРМ. Жмешь все, что видишь. Если что неясно пишешь письмо (как говорят в банке по луку) отвественному (кстати надо иметь с десяток писем, это создает видимость. А потом если что пойдет не так, то всегда можно сказать, что ты не виноват - ты сигнализировал). Ну и потом пишешь бумажку - все Ок. А уже когда АРМ запускают в продакшн выфсняется, что в нем нет самого главного.

dmxrand
()
Ответ на: комментарий от Rastafarra

А функциональное тестирование выглядит как каталог с наборами данных и ключиком в командной строке --test (для GUI прикладух). Ты после компиляции запускаешь тесты и получаешь выхлоп. Когда в филиале у дяди Васи твоя программа падает - ты запускаешь у дяди --test и смотришь в чем разница. Если с разбегу не понял, то пишешь расширенный тест с дампом всех переменных и т.д и т.п.

dmxrand
()
Ответ на: комментарий от Stil

После этой фразы, боржоми пить поздно :)

Не вижу проблемы. Работник и работодатель это союз двух равноправных. Если Один из них считает, что он главнее. Оок. Пусть считает, в эту игру можно играть вдвоем. Как это соотносится с деградацией?

dmxrand
()
Ответ на: комментарий от dmxrand

Не делайте мне смешно. Я участвовал в двух слияниях террбанков. И сам был участником и тестером несколько раз. Знаешь как это делается?

знаю. плавали.

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

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

«не мои проблемы», «мне за это не платят», вот это все.

как только ты скажешь «вот тут я могу починить» и не только скажешь, но и починишь, то

1. твоя конкретно жизнь наладится

2. жизнь людей, которые так или иначе с тобой контактируют, наладится

3. и в банке будет чуть веселее, в том числе и тебе, от чувства выполненного.

в качестве плюшек: от этого растет ЗП. не сразу, но растет. быстрее чем у соседа, который «бывший ты».

Rastafarra ★★★★
() автор топика
Ответ на: комментарий от dmxrand

Не вижу проблемы. Работник и работодатель это союз двух равноправных. Если Один из них считает, что он главнее. Оок. Пусть считает, в эту игру можно играть вдвоем. Как это соотносится с деградацией?

При таком подходе исчезает увлечённость. Без увлечённости работа превращается в унылую рутину. Рутина убивает и скиллы, и желание что-то менять. Ты деградируешь.

Stil ★★★★★
()
Ответ на: комментарий от dmxrand

Работник и работодатель это союз двух равноправных. Если Один из них считает, что он главнее. Оок. Пусть считает, в эту игру можно играть вдвоем.

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

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

а ты устраиваешь маленькую французскую революцию. она хороша когда она массовая, а так, в одно рыло, ты вызываешь разве что раздражение и некоторое желание уволить нафиг :)

в конце концов кто на кого работает? не нравится? дверь сам найдешь? у нас свободная страна ;)

Один из них считает, что он главнее. Оок. Пусть считает

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

а пока извини, чисть где сказано.

Rastafarra ★★★★
() автор топика
Последнее исправление: Rastafarra (всего исправлений: 2)
Ответ на: комментарий от Iron_Bug

функциональные тесты это отчасти помогает. но только не когда у тебя миллионы инсталляций на разных конфигурациях, ага :) .

Надо еще про тесты добавить, что тесты или делают все, или не делает никто - а это уже решение менеджмента. В ситуации, когда ты один делаешь тестирование, ты всегда выглядишь дураком - от трети до половины твоего времени уходит на тестирование, выхлоп меньше. «Василий, что ты делал в последнюю неделю?»

ptarh ★★★★★
()
Ответ на: комментарий от ptarh

Надо еще про тесты добавить, что тесты или делают все, или не делает никто - а это уже решение менеджмента.

для этого нужна инфраструктура и такой код, который тестами можно покрыть.

как тестить sql на стероидах я не придумал :)

Rastafarra ★★★★
() автор топика
Ответ на: комментарий от dmxrand

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

winlook38 ★★
()
Ответ на: комментарий от Rastafarra

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

Ха. Карфаген ДОЛЖЕН быть разрушен. Почему ты своими усилиями поддерживаешь работу банка? Ты как в этом заинтересован? Если руководство банка не понимает, что они создали для тебя невыносимые условия труда - у них ДОЛЖНЫ быть проблемы. Можно 1 раз сказать, что «ребят это херня». Можно 2. На третий раз надо саботировать. Мы одному сотруднику кстати в перерыве даже бока чуть не намяли. Сразу перестал давать ценные советы руководству. У нас появилось больше свободного времени.

как только ты скажешь «вот тут я могу починить» и не только скажешь, но и починишь, то

1. твоя конкретно жизнь наладится

Нет, станет хуже (как минимум могут побить).

2. жизнь людей, которые так или иначе с тобой контактируют, наладится

Нет.

в качестве плюшек: от этого растет ЗП. не сразу, но растет. быстрее чем у соседа, который «бывший ты».

Вообще ни разу нет.

Смотри я пришел на работу и стал один делать отчет который ранее делало более 100 человек. Мой директор на совете директоров сообщил, что «вот у нас есть такой талант». К нему подошли несколько человек и попросили решить проблемы еще их отделов.

В итоге я получил дополнительную работу. Далее директора соседних подразделений увидели, что у нас есть некие данные которые их интересуют и вместо того чтобы их добывать силами своих отделов написали письма с запросом этих данных. Мои коллеги (те кто сидит за соседним столом) получили задания кроме их основной работы предоставлять эти данные «дружественным подразделениям».

В конце квартала по данным которые предоставили вы руководство стало оценивать работу структур. Многие структуры сказали, что вот эти данные кривые (у нас есть свои данные и по ним мы план выполнили даже перевыполнили). Вы (весь отдел) получили депримирование (а кто разбирается вы правы или нет). Вас заставили добыть все данные снова и согласовать с «пострадавшими».

Несколько сотрудников соседних подразделений которые считались незаменимыми оказались в ситуации когда теперь это не так (и подловив тебя в коридоре отдавили ногу). У нескольких подразделений не сошлись данные и их тоже депримировали.

Желаю далее продолжать решать проблемы.

dmxrand
()
Ответ на: комментарий от Stil

Рутина убивает и скиллы, и желание что-то менять.

Глупости какие. Лично я когда послал всех нафиг великолепно улучшил свои скиллы причем до того уровня, что мной заинтересовались гораздо более интересные работодатели.

dmxrand
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.