На собеседовании по разработке иногда дают готовый проект с багом. Решение уже написано. Оно просто не работает: есть маршруты, которых вы не выбирали, слой хранения, который вы не проектировали, и падающий тест с почти издевательски простым описанием. Где-то внутри чужого кода изменение выглядит успешным, а после обновления страницы исчезает.
Практика полезнее, чем ещё один вечер на узнавание паттернов. Сначала надо решить, куда смотреть. Потом — что писать.
Главная ловушка — желание сразу быть полезным. Видите неуклюжую функцию, начинаете чистить, через десять минут код красивее, а исходная ошибка не объяснена. Для такого разбора я держу правило: каждое изменение должно опираться на конкретное наблюдение.
Сначала жалоба, потом один запрос
Пользователь меняет цену аренды машины с 80 на 60. В ответе приходит 60. Новый запрос возвращает 80.
Это учебный пример с выдуманными данными и упрощённым интерфейсом репозитория. Он не восстанавливает чужой приватный код.
До открытия всех папок запишите контракт: авторизованное обновление должно изменить сохранённую цену, а последующее чтение — вернуть это изменение. В примере чтение идёт в то же хранилище, других писателей нет.
Без последней оговорки устаревшая реплика, кэш или параллельная правка дадут похожий симптом по другой причине.
Теперь смотрите только один путь: запрос → аутентифицированный пользователь → обработчик → репозиторий → сохранённая запись → ответ.
Первый полезный вопрос: изменилась ли сохранённая запись. Если там по-прежнему 80, копайте запись. Если там 60, а чтение возвращает 80, копайте чтение. Поиск сузился без единой правки.
Ответ выглядит правильным, потому что ошибка в ответе
Функция editCar находит запись, собирает новый объект копированием и возвращает его. Вызова записи в хранилище нет. HTTP-обработчик может сериализовать этот объект в убедительный успешный ответ, пока сохранённая запись остаётся нетронутой.
Поэтому ожидаемый результат надо записать до чтения реализации. Ответ, совпадающий с входными данными, кажется доказательством, хотя доказывает мало.
Моя заметка о диагнозе состояла бы из четырёх строк:
- Наблюдение: ответ на правку содержит 60; свежее чтение содержит 80.
- Гипотеза: сервис меняет только возвращаемый объект.
- Доказательство: этот путь вызывает метод чтения и ни разу не вызывает метод записи.
- Починка для проверки: выполнить обновление с ограничением владельца, затем вернуть сохранённый результат.
Заметка короткая. Её можно объяснить вслух. И её легко оспорить.
Самая маленькая починка, которая возвращает контракт
В наброске у репозитория есть updateOwned. Контракт явный: совпасть должны и ID машины, и ID владельца; применить только проверенные поля; после успешной записи вернуть сохранённую запись. Если подходящей записи нет — вернуть null; при сбое хранилища — отклонить операцию.
Функция editCar вызывает updateOwned и возвращает saved.
Короткая функция — не достижение. Достижение в том, что репозиторий теперь выполняет операцию, которую обещает endpoint.
Это интерфейсный набросок, не готовая реализация базы. В реальном проекте проверьте фактический метод обновления: он возвращает старую запись, новую или только число затронутых строк? Может ли он сообщить об успехе, когда ничего не совпало? Обработчик должен перевести эти исходы в документированный ответ. И обработать отклонённую запись, а не объявить успех до завершения операции.
await ждёт, пока промис завершится. Он не превращает отсутствующую запись в реальную и не чинит репозиторий, который резолвится раньше, чем закончилась работа.
Ограничение владельца нужно внутри операции обновления. Предварительный поиск сам по себе не повод разрешать запись в любую запись с таким ID.
Доказать починку отдельным чтением
Проверка, которая смотрит только на ответ редактирования, приняла бы сломанную версию. Сильнее проверка, которая повторяет следующее действие пользователя.
- Создайте машину C1 с владельцем A и ценой 80.
- От имени A поменяйте цену C1 на 60 и дождитесь завершения запроса.
- Прочитайте C1 через обычный путь чтения приложения.
- Убедитесь, что и ответ, и сохранённая запись содержат 60.
Потом усложните проверку двумя способами. Попробуйте правку от пользователя B и убедитесь, что изменений нет. Сделайте запись в хранилище неудачной и убедитесь, что endpoint не возвращает успешно сохранённую запись.
Для кодов статуса используйте документированный контракт ошибок проекта. Заменять его своим любимым API-стилем посреди починки смысла нет.
Ловушка в тестовой обвязке: если фейковый репозиторий возвращает тот же объект, который хранит, случайная мутация может выглядеть как сохранение. Фейк должен воспроизводить важное поведение хранилища, включая отдельные копии при чтении, если так ведёт себя настоящий репозиторий.
Для сервиса на диске, который обещает сохранность после перезапуска, добавьте отдельную проверку. Два чтения из общего объекта в памяти не доказывают устойчивость к падению.
Другой симптом — другое расследование
Полезная привычка: найти первую точку, где фактическое состояние расходится с контрактом. Она работает и когда жалоба меняется.
| Симптом | Где смотреть | Что проверить |
|---|---|---|
| Новая запись не появляется | Хранилище и создание | Если записи нет, проследите создание и его завершение. Если есть, сравните поля, по которым строит список, с тем, что реально сохранило создание. Несовпадение поля владельца может спрятать успешный insert. |
| В списке чужие записи | Аутентификация в запросе | Проследите идентичность до запроса. Фильтрация в браузере недостаточна: сервер должен проверять доступ. Сверьте соседние пути получения, правки и удаления с тем же правилом владельца. |
| Изменение пропадает иногда | Порядок событий | Запишите порядок. Два запроса могут прочитать одно старое состояние, сделать разные изменения и перезаписать друг друга. await в каждом запросе не сериализует их между собой. |
| Данные в одном JSON-файле | Пересекающиеся записи | Node предупреждает об одновременных writeFile в один файл без ожидания. Даже отдельные завершённые записи теряют обновления, когда две последовательности read–modify–write гоняются. Координация должна покрывать всю операцию и всех писателей. |
Это следующий шаг, когда доказательства ведут туда. Не повод менять маленький сервис на новую архитектуру до понимания исходного бага.
Сделать из этого тренировку
В публичном описании похожего упражнения по Node.js с арендой машин есть несколько жалоб: записи утекают между пользователями, новые записи пропадают, правки теряются после обновления. Исходного кода там нет, так что используйте описание для диагностики, а для практики возьмите небольшой локальный сервис.
Для 35-минутной тренировки я предпочитаю такую структуру. Это план практики, не оценка найма.
- Первые 5 минут: прочитайте контракт API, запустите supplied checks и сопоставьте падения с затронутыми операциями. Убедитесь, что сервис использует нужное окружение.
- Следующие 10 минут: воспроизведите один сбой на крошечной фикстуре. Проследите только нужный запрос и запишите первое неверное значение.
- Ещё 10 минут: сделайте одну обоснованную починку. Проверьте исходный симптом и соседнее поведение, которое правка может задеть.
- Последние 10 минут: перезапустите полный набор проверок, посмотрите на изменение и объясните причину, починку, доказательство и оставшуюся неопределённость.
Держите диагноз до открытия решения. Если используете разбор с подсказками, это шаг сравнения после своей попытки. Полезный вопрос — где ваше рассуждение разошлось, а не как быстро вы узнаёте объяснение после.
На реальном собеседовании следуйте его правилам насчёт ассистентов и внешних ресурсов. На тренировке ассистент может помочь найти путь вызова или предложить контрпример; объяснить, почему починка следует из доказательств, всё равно вам.
Оставить себе больше, чем зелёный экран
В конце сохраните короткую запись о починке: дано такое состояние → этот запрос должен вызвать такое изменение → это наблюдение доказало дефект → этот патч вернул поведение → эти проверки его защищают.
Если не можете заполнить наблюдение, возможно, вы угадали правильно, но не поняли ошибку. Если не можете назвать проверки, не показали, какое поведение защищает починка.
Не нужно понимать весь репозиторий, чтобы стать полезным внутри него. Нужно достаточно системы, чтобы сделать одно утверждение, найти доказательство и не сломать следующий запрос.
Перед следующей тренировкой возьмите небольшой проект и попросите кого-то посадить один баг. Сохраните ожидаемое поведение, спрячьте изменённую строку и объясните починку вслух, когда найдёте.
А если успешный ответ врёт?
Fluxs
Комментарии (0)
Войдите, чтобы комментировать.
Пока нет комментариев. Будьте первым.