1765984430
2025-12-17 14:55:00
Когда вы изучаете новую технологию, вы можете носить с собой фальшивую уверенность. Вы смотрите несколько видеороликов, просматриваете документацию, получаете работающий игрушечный пример и говорите себе: «Да, у меня есть это». Я сделал это. Это никогда не длится долго. Трудный урок часто сопровождает единственный опыт, который имеет значение.
Вы учитесь через неудачи: падая ничком, глядя на беспорядок и выясняя, почему он сломался. Что-нибудь, что кажется слишком простым? Вероятно, так оно и было, и вы не вышли из процесса, не получив ничего, что стоило бы изучить.
Спросите о неудаче: неудача === опыт
Когда я нанимаю кого-то, кто претендует на опыт работы с реляционными базами данных, я задаю «хитрый» вопрос:
Расскажите мне о худшей схеме базы данных, которую вы когда-либо создавали. Чего он научил вас избегать?
Это не совсем уловка. Любой, кто был по колено в реляционных базах данных, знает, что идеальной схемы не существует. Есть конкурирующие варианты использования которые постоянно тянутся друг к другу. Вы проектируете рабочие нагрузки для транзакций, но неизбежно кто-то пытается использовать его для создания отчетов, и тогда все задаются вопросом, почему сканируются запросы. Другой разработчик из команды случайно оптимизирует схему (обычно спустя годы) для сценария использования отчетов только для того, чтобы сделать транзакционную рабочую нагрузку неработоспособной.
Правильный ответ обычно звучит так:
Мы создавали систему с учетом транзакционной пропускной способности: один из основателей компании думал, что MySQL — это база данных, и это было нашей первой ошибкой. Затем компания использовала его для целей отчетности. В течение нескольких лет система несколько раз переходила из рук в руки. Соединения стали неудобными, индексы не соответствовали шаблонам доступа, а ночные задания начали мешать пользовательскому трафику. Нам пришлось разделить реплики чтения, в итоге ввести хранилище, и через 5–6 лет мы упростили транзакции и перенесли их на Cassandra.
Схема, которая меня чуть не сломала
Однажды я представил транзакционную схему, которая на бумаге выглядела хорошо: нормализованная, аккуратная, все на своих местах.
Затем появилась аналитика с «всего парой быстрых дашбордов». Следующее, что вы знаете, моя симпатичная модель 3NF, которая теперь подключена к каждому начальному классу в Америке, использовалась как электронная таблица Excel с миллионом строк для суммирования бухгалтерского отчета. В течение нескольких месяцев все было хорошо, пока это не изменилось, и база данных стала медленно работать, потому что 80% времени тратила на обновление индекса. Не то чтобы я мог что-то исправить, потому что это означало бы несколько дней простоя в сочетании с переписыванием проекта, контракт которого почти истек.
И как мы пытались это исправить? Если вы были в такой ситуации, вы поймете, что то, что я собираюсь написать, является признаком того, что вы достигли нового уровня отчаянной неудачи. Вместо того, чтобы рассматривать рациональный подход к реформированию схемы или отделению того, что в 2007 году стало рабочей нагрузкой «веб-масштаба», от базы данных NoSQL, мы пытались выяснить, как приобрести более быстрые жесткие диски с более высоким числом операций ввода-вывода в секунду.
Я многому научился:
- Я узнал, что обновление оборудования (покупка более быстрого компьютера или покупка жесткого диска на миллион долларов) только отсрочит кризис. Настоящее исправление неизбежно: массовое горизонтальное масштабирование несовместимо с реляционными базами данных.
- Я узнал, что означает «план запроса из ада». Мы заклеили его материализованными представлениями и прочитанными репликами. Затем мы сделали то, что должны были сделать с первого дня: настроили реальный путь отчетности.
- Если вам приходится оптимизировать план запроса каждую неделю? Ваша база данных посылает вам важный сигнал, который вы должны перевести так: «Пришло время искать альтернативу».
Урок сгорел: Проектируйте для того варианта использования, который у вас есть на самом деле, а не для того, который вы надеетесь получить.— и предположим, что вариант использования изменится.
Какое это имеет отношение к курсору и второму пилоту?
Я вижу, как много людей пишут в LinkedIn и на других сайтах о том, насколько удивительным является кодирование Vibe. Эти праздничные посты рассказывают о людях, публикующих их, больше, чем они думают, поскольку они редко признают реальность процесса — это не только развлечения и игры. Хотя удивительно, какого прогресса можно добиться за день или неделю, те из нас, кто действительно использует эти инструменты для написания кода, первыми говорят вам, что мы извлекаем много трудных уроков.
Это непросто. В этом процессе нет ничего «яркого», и если вы все делаете правильно, вы начинаете использовать ругательства в своих подсказках. Например, некоторые из моих подсказок в ответ вчерашнему агенту курсора были такими: «Вы, должно быть, шутите надо мной, у меня есть правило, в котором говорится, что я никогда не хотел, чтобы вы это делали, а вы просто проигнорировали его?»
Всякий раз, когда я вижу, как люди в восторге от последней, величайшей причуды, которая меняет мир, я также первым замечаю, что, возможно, они не используют все это. Если бы это было так, они бы поняли, что это не так «легко», как они сообщают.
Мышца неудачи, которую вы наращиваете с помощью баз данных, такая же, как и с инструментами кодирования ИИ. Нельзя войти на цыпочках. Приходится толкать, пока что-нибудь не сломается. Затем вы поймете, как профессионально подойти к новой технологии.
- Попросите агента провести рефакторинг одного файла — отлично.
- Попросите его координировать изменения в 20 файлах, переосмыслить обработку ошибок и обеспечить успешное выполнение тестов — теперь мы учимся.
- Смотри, где он спотыкается, и учись рамка работу, чтобы она могла добиться успеха в следующий раз.
- Проведите все выходные в «погоне за дикими гусями», потому что ваш агент-программист решил полностью игнорировать правила курсора. ← Это дорого, но именно так и учишься.
Хитрость не в том, чтобы избежать неудачи. Его контролируемый, обратимый отказ.
Мета-урок
Если вы никогда его не ломали, вы этого не знаете. Это справедливо для программирования, составления бюджета, управления, приготовления пищи и катания на лыжах. Если вы не потерпели неудачу, вы этого не знаете. А большинство людей, говорящих о «кодировании вибрации», этого не делают.
Люди, которым я доверяю больше всего, как инженеры, могут мне сказать почему что-то не удалось и как в результате они скорректировали свой подход. Вот и вся игра с инструментами кодирования ИИ. Чем быстрее вы сможете запустить цикл — попробовать → сломать → проверить → уточнить — тем лучше у вас получится.
#Если #вы #никогда #этого #не #ломали #вы #на #самом #деле #об #этом #не #знаете #ОРейли
По теме
