Как перейти от хорошего к великому

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

«Группа людей проводит мозговой штурм за ноутбуком и листами бумаги» Штефана Штефанчика на Unsplash

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

Чем быстрее вы сможете повторить, тем лучше станет ваш продукт.
«Гибкий рабочий процесс итерации» от Smartsheet

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

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

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

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

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

С помощью этого центрального хранилища составных компонентов мы можем создавать прототипы и идеи для тестирования в коридоре и даже предоставлять новые функции в ускоренном темпе.

Уровни тестирования программного обеспечения

Вы заметили, что мы доносим до сведения, что тестирование важно. Тестирование программного обеспечения является обширной темой в разработке программного обеспечения, но давайте сосредоточимся на четырех уровнях тестирования, которые являются неотъемлемой частью бесперебойной работы непрерывного процесса доставки - единица, интеграция, система и принятие.

Мы используем модульные тесты для проверки отдельных компонентов, наименьших тестируемых модулей, в программном обеспечении. В нашем случае это обычно компоненты пользовательского интерфейса или вспомогательные методы. Интеграционное тестирование происходит, когда отдельные компоненты тестируются как группа. Например, это может означать такую ​​функцию, как калькулятор, где у вас будут кнопки и экран дисплея, а также проверка правильности отображаемого числа в ответ на нажатие кнопки. Для API конечная точка может установить соединение с базой данных для получения набора данных.

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

Это краткий обзор того, как мы планируем сделать процессы нашей команды переднего плана более эффективными. Более подробно о реализациях мы расскажем в следующих статьях о разработке фронт-энда в StashAway. Следите за обновлениями!

Мы постоянно ищем талантливых специалистов, чтобы присоединиться к нашей команде - посетите наш сайт, чтобы узнать больше и не стесняйтесь обращаться к нам!