1. Введение
Процесс, через который проходит экран, прежде чем быть представленным пользователю, гораздо более длителен, чем кажется. Он начинается с планирования, затем идет запрос на публикацию, разработка, тестирование — и все это связано в единый поток. На этот раз я взял на себя большинство процессов, кроме публикации.
Эта статья является записью, которая больше посвящена процессу, чем результату. Я хотел бы разобраться, о чем я размышлял, какие трудности возникли и что можно улучшить в следующий раз, основываясь на личном опыте одного цикла.
2. Планирование — с точки зрения пользователя, а не разработчика
На этапе планирования больше всего волновало использование экрана пользователем. В процессе разработки часто возникает желание реализовать что-то просто, но я старался прежде всего представить, какие действия пользователь будет повторять на самом деле.
Ярким примером является функция изменения состояния элемента в списке. С точки зрения разработки самый простой способ — это кликнуть по строке, перейти на экран деталей, изменить значение и сохранить. Структура экрана ясна, и сложность реализации невысока.
Но, размышляя о реальном сценарии использования, я заметил, что пользователи часто меняют состояние, проверяя несколько элементов одновременно. Переходы на экран деталей постоянно приводили к нежелательным кликам и переключениям экрана по мере увеличения количества элементов.
Поэтому я выбрал способ инлайн-редактирования, который позволяет изменять состояние прямо на экране списка. В процессе реализации потребовалось дополнительное работа по управлению состоянием на уровне строк, обработке ошибок сохранения, оптимистичному обновлению и т.д. Объем разработки увеличился, но удалось уменьшить объем работы, которую пользователю нужно выполнять повторно.
Конечно, нельзя основываться только на удобстве пользователя при принятии всех решений. Существуют и реалистичные ограничения по времени и ресурсам. Однако я пришел к выводу, что важно четко осознавать причины любого выбора. Понимание того, является ли выбор компромиссом из-за графика или сделан ради удобства пользователя, поможет яснее определить направления для будущих улучшений.
3. Запрос на публикацию — Что важнее передачи: ясность
На этом этапе цикла я научился больше всего в процессе запроса на публикацию. Хотя сама публикация выполнялась отдельной командой, моя роль заключалась не только в передаче задач, но и в приведении информации в состояние, в котором можно было бы работать.
Сначала мне казалось, что достаточно объяснить функции и структуру экрана. Однако в процессе совместной работы информация, которую я считал само собой разумеющейся, зачастую не была таковой для другой стороны. Если критерии для состояния экрана или поведения не ясны, это ведет к дополнительным обсуждениям и исправлениям.
Еще одним важным выводом для меня стало то, что перед началом работы важно иметь достаточное понимание. Образы экранов в наших головах могут немного отличаться, и если мы не согласуем их заранее, затраты на пересмотр после начала работы могут оказаться значительно выше, чем ожидалось.
В конечном итоге запрос на публикацию — это не просто задача по передаче информации. То, насколько ясно я могу систематизировать и поделиться своим пониманием, сильно влияет на эффективность сотрудничества. На этом опыте я осознал, что многие проблемы, возникающие в сотрудничестве, могут быть связаны не с проблемами в способностях выполнения работы, а с передачей информации.
В будущем я, вероятно, буду уделять больше времени подготовке и проверке, чтобы убедиться, что другая сторона рисует ту же картину, прежде чем запрашивать работу.
4. Разработка — чем больше подготовлен, тем проще
На этом этапе разработки все прошло без особых трудностей. Я сам занимался как бэкендом, так и фронтендом, и, к счастью, было не так много затруднений, как я ожидал.
Сначала я не сильно задумывался об этом, но теперь, оглядываясь назад, я понял, что легкость разработки была связана с тем, что на предыдущем этапе вектор был заранее определен. Было относительно ясно, что нужно создать, в каком состоянии должен быть интерфейс, и как пользователи будут взаимодействовать с функционалом. Благодаря этому я смог сосредоточиться на реализации уже определенных аспектов, а не принимать новые решения во время процесса разработки.
Также оказало помощь то, что я занимался как фронтендом, так и бэкендом. Обычно требуется согласовать API-интерфейсы или структуры данных, но на этот раз я смог работать, рассматривая это как единый поток. Я смог разработать API, принимая во внимание необходимые формы на фронтенде, и, наоборот, реализовать интерфейс, понимая структуру бэкенда.
Этот опыт снова напомнил мне, что сложность разработки определяется не только в момент написания кода. То, насколько сильно я обдумал и упорядочил все на предыдущем этапе, во многом определило сложность последующей разработки. Это был опыт не о том, что разработка была легкой, а о том, почему она могла быть такой.
Изучая связанные примеры, я заметил, что некоторые команды тратят больше времени на проектирование и определение интерфейса, чем на разработку, что впечатлило. Сначала это может показаться медленным процессом, но на самом деле это сокращает затраты на исправление на этапе реализации и сокращает общее время выполнения.
По мере выполнения этой работы мне стало немного понятно, почему выбирают такой подход. Причиной быстрого продвижения на этапе разработки было то, что много решений было принято на предыдущем этапе, а не в процессе реализации.
5. Тестирование — последний этап, оказавшийся менее готовым, чем ожидалось
Наиболее разочаровывающим этапом был этап тестирования.
На этот раз я не писал отдельные тестовые коды и провел проверку, самостоятельно проверяя готовый интерфейс. Это был вполне возможный подход в ситуации с небольшим количеством функций и в итоге я смог завершить работу без серьезных проблем.
Однако оглядываясь назад после завершения работы, я понял, что тестирование сильно зависит от человеческой памяти. По мере увеличения количества экранов и повторяющихся изменений возникают ситуации, когда необходимо повторно проверить функции, которые были проверены ранее. Сейчас это под контролем, но с увеличением объема работы поддерживать тот же подход будет затруднительно.
Особенно обычно легко проверить нормальный поток данных, но я почувствовал, что исключительные случаи, такие как отсутствие данных или ситуации с ошибками, легче пропустить. Мне казалось, что в процессе разработки я учел это, но на этапе проверки часто сосредоточиваются именно на сценариях нормальной работы.
Проводя ретроспективу, я также исследовал способы тестирования других команд. Вместо того, чтобы управлять всеми функциями через тестовые коды, оказывается, более распространенным является автоматизация только ключевых потоков, которые наиболее часто используют пользователи, и сочетание этого с ручной проверкой остальных. Особенно впечатляющими были примеры, когда осуществлялось подтверждение основных сценариев через E2E тестирование или управление состоянием интерфейса с помощью Storybook.
Хотя это может быть немного преждевременное решение для текущего масштаба проекта, я чувствуя, что, если количество повторных проверок будет расти, это будет вполне подходящий вариант для рассмотрения. Более реалистичным представляется добавление небольших защитных механизмов к текущему подходу, чем полностью менять все сразу.
6. Заключение
Самым значимым моментом этой работы стало то, что я смог полностью пройти через процесс, до того как экран был передан пользователю.
Ранее я думал о планировании, верстке, разработке и тестировании как о независимых этапах. Но, пройдя весь процесс, я осознал, что каждый этап сильно связан друг с другом. Сведения, собранные на предыдущем этапе, облегчали следующий, а неопределенные моменты оборачивались все большими затратами на последующих этапах.
Кроме того, у меня также была возможность взглянуть на ситуацию с точки зрения других ролей. Я немного понял не только, какая информация нужна, но и в каких областях возникают трудности, не просто отправляя запросы и получая результаты. Благодаря этому я научился многому о том, что еще нужно подготовить для процесса сотрудничества.
Этот обзор ближе к записи процесса, чем к записи результата. Важно, что было создано, но большим достижением стало то, что я полностью испытал процесс его создания. В следующий раз я хотел бы постепенно исправить недостатки, обнаруженные на этот раз, и создать лучший цикл.
jun