10 кейсов, после которых вы расхотите тратить время на кастдев :)

Disclamer: за платными советами по кастдеву идите к Ивану Замесину. Ниже я выражаю свой дилетантский взгляд на эту тему, основанный на опыте кастдева и поиска пилотных внедрений инновационного иструмента статического анализа SQL-запросов holistic.dev

1/3

Пример #1: hand made
Если в компании разные люди пишут приложение и SQL-запросы, возникают проблемы синхронизации результатов их работы. Типы, версионирование и тд. Частично решается тестами, но бОльшая часть автоматизации не поддается. Решение - страдать, колоться и жрать кактус. Никто не любит заниматься этим вручную, но считается, что это необходимое зло и все с ним мирятся. "Это работа программиста, нам за это платят".
Размазали проблему между несколькими разработчиками. Это снизило их мотивацию и замедлило работу. Инструмент - недешевый ручной труд.

Пример #2: cheap staff
Если в компании не пишут чистых SQL-запросов, а используют разного рода ORM, то возникают проблемы с производительностью всего. Решение - купить железо помощнее.
Кажется, что получается сэкономить на разработчиках и сократить time to market, а растущие технический долг и затраты на инфраструктуру - "это неизбежно и так у всех".
Размазали проблему по всему проекту. Инструмент - забрасывание деньгами.

Пример #3: startup (vc will pay)
Совокупность двух предыдущих примеров. Я как-то рассказывал про стартап, где не использовали нормализацию базы (https://t.me/nosingularity/410), потому что join'ы страшные и тормозят, но при этом в базе нет ни одного индекса. Инструмент - недешевый ручной труд + забрасывание деньгами.

Во всех этих случаях нет главного - осознания проблемы. Как говориться, признание проблемы - это 50% ее решения.
У всех есть налаженные процессы, потери на которых приняты как приемлемые.

Почему никто ничего не делает?
Перенастройка процессов может стоить дорого и/или не дать никакого результата.
Ничего не трогай, ничего не меняй (с) анекдот

Кастдевить таких клиентов бестолку. Может сложиться ощущение, что ты делаешь то, что никому не нужно.

Пример #4: look-alike
Есть какая-то осознанная проблема, которая кажется похожей на ту, которую может решить твой продукт.
"О, круто ты придумал! Твой инструмент же расскажет мне каких индексов не хватает?" Это не самая большая из проблем, связанных с базой. Потратив день, можно вручную идентифицировать и устранить 80% проблем, связанных с индексами. Мой инструмент полезен не этим.
"Твой анализатор не ругается на поля в запросе, которых нет. Это не правильно." Это правильно. Это анализатор для DBA. Он не рассчитан, на то, что в него будут прилететь запросы, которые не валидны в run-time. Клиент хочет от инструмента для DBA получить функционал инструмента для разработчиков.

Это не те проблемы, которые ты собирался решать.

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

Стоит бросить задуманный функционал и начать решать то, что озвучили? Можно. Но, скорее всего, ты погружен в предметную область гораздо сильнее и у тебя уже есть big picture. Возможно, ты допилишь этот функционал когда-нибудь потом. Возможно, решать эту проблему не надо совсем, потому что это не проблема.
Но если вам одно и тоже сказали 90% опрошенных, и это одно и то же укладывается в концепцию продукта, то, наверное, стоит пересмотреть приоритеты.
Если не укладывается, то это еще ничего не значит. Просто идите дальше.