Всем привет. Сегодня хотел затронуть тему, которая в бытности разработчика вызывает и смех, и слезы, — о самых необычных запросах на разработку от коллег, поставляющих задачи. Также заранее прошу не принимать прочитанное близко к сердцу: какие-то из ситуаций могут показаться наивными, но обойти их стороной я не смог в этом посте.
Итак, начну с собственного реноме. Меня зовут Богдан, я работаю в одном достаточно большом отечественном финтеке вот уже 7-й год и добрую половину из них занимаю позицию Java-лида в одной из интеграционных команд. За такое (относительно) длительное время в энтерпрайзе периодически приходят требования на разработку, от которых хочется или плакать, или смеяться, а то и всё вместе. Происходит это по самым разным причинам, которые мы сегодня касаться не будем. Скажу лишь, что никого не осуждаю, не пытаюсь никого принизить и наверняка сам генерировал нечто схожее, о чем пойдет речь ниже. Также стоит учесть, что мой бэкграунд преимущественно бэкендово-интеграционный, соответственно, и кейсы будут из этой области и контекста. Ну а дальше — по кейсам, по тем 7 кейсам, когда прочитав требования, внутри что-то скукоживается от отвращения либо раздается улыбка во всё лицо — у кого как.
Немного глобального контекста: проект, вокруг которого будут описаны курьезные запросы, — интеграционная шина данных, напичканная самой разной интеграционной логикой, Java-приложение, состоящее из невообразимого количества SOAP/REST-методов, шедуллеров и всяческих очередей.
1. Прокиньте Exception в PDF!
Приходит задача на интеграцию: необходимо реализовать генерацию некоего отчета для некой периферийной коробочной системы. По сути, сделать прокси-метод, который сходит в отчетную систему, смаппит в нее параметры и вернет готовый отчет вызывающей коробочной системе. Ну, значит, выдали функционал на тест, заранее позаботившись о заворачивании выдаваемых отчетной системой Java-стектрейсов (так оно работает, да) в понятный HTTP-код и тело ответа...
В ходе тестирования заказчик обнаружил, что при определенном сочетании входных параметров наше API возвращает вместо нужного PDF-файла HTTP-код 400 и структурированное тело ответа. Тут же прилетело замечание на фикс, которое заключалось примерно в следующем:
"При тестировании с параметрами X, Y, заполненными значениями ... ожидали получить PDF-файл с стектрейсом, но не получили его. Просьба переделать согласно требований."
На вопрос, зачем это нужно, был получен ответ: "Так устроен процесс, и коробка не может обрабатывать ошибки. Оператор при необходимости перегенерирует запрос, если увидит ошибку в десктопном клиенте." :D
2. Нейминг параметров
Часто на грумингах мы удивляемся, как коллеги, разрабатывающие хранимки в различных периферийных АБС, называют параметры: ни смысла, ни структуры, ни вообще какой-либо идеологии. Очень часто имена ничего не несут, только всё запутывая.
И вот на одном из грумингов кто-то из коллег обронил пассивно-агрессивную шутку: "Скоро, мол, вообще придут с параметрами на кириллице написанными."
И через некоторое время... интеграция с... 1С. Надо вызывать некие методы и передавать туда JSON-тело, где параметры на русском языке. Тут, конечно, 1С можно понять, но в тот момент мы угарнули =)
3. Экзотическая интеграция с модулем
В один из дней прилетает задача на интеграцию с покупным антифрод-модулем. Без особых подробностей: вот эндпоинт, вот такое тело нужно передать, вроде POST-запросом. Разрабатываемся, идем в тест... ииии... не работает.
При дальнейших разборках выяснилось, что с сервисом нужно взаимодействовать по голому TCP. Ну, прям: открываешь сокет, пушишь туда байты, ждешь ответа. Почему? "Сервис по-другому не умеет."
4. Куда бы еще засунуть тебе своё тело
Периодически на собесах встречаю вопросы про стандарты: "А расскажи про HTTP, REST, RESTful, про 7 принципов" — и не всегда понимаю, зачем. Ведь в реальности к тебе придут однажды и попросят сделать GET-метод, который принимает тело, или вызвать нечто подобное. Почему? "Заказчик просит, и есть на это убедительная причина."
И ведь это только вершина айсберга. Наверняка каждый из вас встречал извращения похожей направленности и позаковыристые.
5. "Сделайте SOAP-метод, который возвращает данные… но только как если бы запрос пришёл вчера"
Да-да, правильно. Есть некая коробка, которая забирает из нас некую информацию, и по каким-то внутренним причинам она может её не забрать, но забрать должна обязательно! Доработаться она тоже не может по тем же самым причинам.
Соответственно, что делают бравые парни из интеграции? Правильно! Машину времени. Ну, просто пилишь табличку и отмечаешь себе: если вчера вызывала — значит, отдаем сегодняшнее; если не вызывала — вчерашнее. :D
6. "А давайте вы будете смотреть на наше CPU и в зависимости от него контролировать количество направляемых нам запросов?"
Есть такая штука для банков — ЦФТ, оракловая коробка, которая что-то вроде "главной книги банка". Там живут счета, деньги, некая отчетность. И коробка эта не всегда работает быстро (возможно, это связано с особенностями нашей конкретной инсталляции).
Ну и собственно, мы, как интеграция, генерируем в эту коробку множество запросов на формирование бух. проводок. Ну там: пришла какая-нибудь C2B-оплата — нужно её обязательно положить в эту коробку, чтобы она учла её на счетах и отчиталась о транзакции во всех нужных инстанциях.
И вот значит эта АБС стала захлебываться из-за увеличения количества продуктивного трафика в очередной раз. Один из руководителей, в чьем ведении лежит эта система, выдвигает гениальную постановку задачи:
"А давайте вы будете в зависимости от показателя нашей загруженности по CPU уменьшать или увеличивать поток создаваемых проводок."
Благо, от этой идеи удалось тогда отбиться...
7. "Зашифруйте тело запроса в... Base64"
— Мы не хотим, чтобы данные передавались в открытом виде!
— Но ведь Base64 — это не алгоритм шифрования.
— Достаточно, чтобы данные не передавались в открытом виде.
— Ладно.
P.S. У меня есть, там пишу на технические темы преимущественно: https://t.me/umenyarabotaet