Панбагон. Ломается структура файла, если в нем первые колонки пустые

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

Тестировали Дадату. Явки-пароли, разумеется, изменены. Воспроизводить тоже бесполезно, до прода баг не дошел ツ

********************************************************************

Ломается структура файла, если в нем первые колонки пустые

Шаги

1. Открыть форму обработки файла — https://dadata.ru/clean/#process-file (почта - test@gmail.com, пароль - 1)
2. Загрузить файл, содержащий пустые столбцы (см. «Пустые колонки.xlsx»).

Результат

Система отображает "m-n" количество столбцов загруженного файла, где m —количество столбцов в файле, n — количество пустых столбцов.

В нашем файле:

• исходно заполненных колонок — 5
• колонок в структуре — 5

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

Ожидаемый результат
Отображены все столбцы загруженного файла

********************************************************************

+ К задаче приложен файл, иллюстрирующий проблему.

Очень классный баг, который в том числе показывает важность проверки нуля. Если говорить о колонках в файле, то ноль можно применить:

• к числу самих колонок, но это сложно, не может быть N строк и 0 колонок;
• к данным внутри. Ноль = пустота

Студент проверил ноль и обнаружил отличный баг — из-за пустой колонки пропадает заполненная!

В чем суть локализации такого бага? Понять ответы на вопросы:

• Всегда ли структура ломается? Нет, только если есть пустые колонки
• На каком количестве пустых колонок начинает ломаться? На любом, от одной и больше. Это показывает формула "m-n"
• Какой будет минимальный для воспроизведения файл? 1 пустая колонка и 2 заполненных

В целом, если говорить о том, что «раз уж докопался до причины, то можешь сделать минимально возможный файл». Тут не спорю. Хотя 3 колонки и 5 — небольшая разница. А картинка получилась более наглядной, мол, смотри, сколько всего пропало.

Понимаете, есть разница между:

— у меня упало на этом конкретном файле, больше ничего не проверял, причин не знаю, пусть разработчик разбирается;

— упало на этом файле, но я понял, в чем соль, локализовал. Но для наглядности оставил файл на 5 колонок, а не 3;

Если есть осознанное понимание, почему именно такой файл — почему бы и нет? Плохо, когда аттачится файл на 2гб там, где достаточно файла на 5кб. А если разница измеряется одним мегабайтом, можно оставить и так.

Другой вопрос относительно названия — ведь как же так, непонятно, как именно структура ломается. И тут согласна. В названии вполне может фигурировать конкретная проблема о пропадающих данных.

С другой стороны, структура реально ломается. И такое название обязательно привлечет внимание менеджера, который почитывает баг-трекер. Плохо, когда в названии катастрофа «ломается система!», а потом выясняется, что просто сообщения об ошибке нет и то в редких случаях. Здесь название привлекает катастрофой, и она правда есть. Так что можно и так оставить))

Тем более что бывает так, что люди запоминают броское название и потом уже сложно переименовать баг, так как все его гуглят по старому названию. Так что или сразу придумывать попонятнее, или оставить как есть. Разумеется, если в баг-трекере появляется несколько багов с одним названием, это уже плохо. И как минимум новые надо описывать понятнее. Чтобы потом было проще искать. Вот, как-то так.

См также:
Класс эквивалентности «Ноль-не ноль» — использовался в статье
Шаблон бага — использовался в статье
Шаблон улучшения — Как продумывать свое улучшение с примером, когда это приводит к отказу от постановки задачи.
Как заводить задачи в баг-трекер → подробнее о том, как ставить задачу и заполнять обязательные поля.

PS — добавила пост в общую копилку багов. Используется в книге