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

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

В работе часто обращаю внимание именно на данную проблему. Реализовывая ту или иную разработку, команда не решает проблему пользователя. Чаще всего, потребителей функционала даже не спрашивают; «а что надо?», «какие проблемы есть?».

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

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

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

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

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

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

Часто взаимодействия с этим функционал и во взаимодействии с старшими коллегами предложил свое решение проблемы, которое никем ранее не было реализовано.

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

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

Решены сразу две проблемы: Поверка на реальных данных, где есть проблема. Перед применением функционала, мы точно знаем как он подействует.

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

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