# Мой драфт план грид 23.1

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

а) это тесты и рефакторинг, б) это вики и рефакторинг

## Тесты

С тестами у нас очевидно проблемы раз баги приходят, вне зависимости от того это регрессии или нет.

- мало интеграционных тестов. У нас абсолютное большинство тестов это неинтеграционные qunit'ы, в которых включена только одна фича. Из-за этого одна фича работает нормально, а как только подключается что-то ещё происходит что-то ненормальное. Сейчас тесты мы пишем только когда приходит какой-то баг, и добавляем только конкретный сценарий от пользователя (ну может быть соседние на всякий случай тоже покроем). Из-за этого какие-то сценарии всё ещё неправильно работают, и потом приходят новые баги. Кмк лучше взять покрытие тестов как отдельную задачу и покрыть всё что можно
- тесты плохо структурированы. Чтобы понять какие тесты писать нужно понимать что покрыто тестами, а это сделать очень сложно. У нас тестовые файлы по 10к строчек, где намешаны регрессионные тесты после фикса багов, тесты на какие-то фичи и т.д.
- сами тесты сложно (и возможно плохо) написаны. Например от [⁠⁠тестов с 5 уровнями форов](https://github.com/DevExpress/DevExtreme/blob/23_1/testing/testcafe/tests/dataGrid/editing_matrix.ts#L393) лучше избавиться. Из-за того что тесты сложно написаны их сложно поддерживать: добавлять новые сценарии без разведения каши, поднимать после изменения функционала, фиксить мигалки

Надо будет

- написать хороший план по тестам: что где должно тестироваться. Будет хорошее понимание что нужно в этом тесте прочекать а что нет -> не будут дублироваться тесты -> их будет меньше с тем же покрытием -> будет проще их поддерживать. Будет хорошая структура папок с тестами -> не будет файлов по 10к строчек -> будет проще их поддерживать. В компаниях с QA это называется план/стратегия тестирования, нужно будет взять брейндей и почитать литературу, если запланируем эту задачу
- Написать тесты. Тут мы разделяемся на несколько направлений:
- тесты на демки — стыдно когда демки не работают. Плюс демки это сборище основных сценариев. Карточка: https://trello.com/c/APMZEGiM/64-ensure-datagrid-demos-have-enough-test-coverage
- основные тесты. Нужно их правильно разбить, узнать текущий coverage и дописать недостающее. Или же оставить текущие тесты как есть и дописать отдельно кроссфичные тесты.
- тайпскрипт. Тайпскрипт это тоже тесты. Карточка: https://trello.com/c/Ugyi8tGK/6755-typescript-in-jsdocs

## Вики

Описываем старый код, не даём новому коду стать потайными знаниями в будущем

Тут я сильно бы хотел зафорсить идею "один ПР — один котрибьют в вики". Чтобы это правильно железно исполнялось и учитывалось во время ревью

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

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

## Рефакторинг

- Переделка кейборд навигации.
- Переделка фиксированных колонок.

Всё с тестами, всё с вики, со спекой, с тс'ом. Проблемные зоны, рефакторинг (в случае удачи) поможет избавиться от инкаминг багов. Эти зоны тесно связаны с другими фичами (KN с эдитингом, фиксированные колонки с рендером в целом), повысится компетенции и пополнится вики

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

## Продуктовая часть

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

- легко сделать
- ничего не отломает и не прибавит неожиданных багов (как минимум фича должна быть отключена по дефолту)

Погрумим бэклог видно будет

Однако рефакторинг KN и фиксированных колонок тоже можно записать в чейнджлог, поэтому нужно подумать нужны ли нам вообще фичи

## Баги

Инкаминг всё равно будет, текущая стратегия "делать что-то кроме багов только когда уменьшим кол-во багов" кажется себя не оправдала. Кажется лучше сфокусироваться на стабилизации, а багам выделять определённый % времени, даже если они будут накапливаться. Иначе мы только и будем фиксить баги. Тем более что сквадом из 8 разработчиков баги вряд ли будут накапливаться