Это третья часть трилогии статей, посвящённой несоответствию между презентацией для инвесторов и пригодным к использованию продуктом — проблеме, с которой сталкиваются все стартапы.
Если вы их пропустили, вот первая и вторая часть.
С возвращением. Похоже, вы настроены серьёзно. Эта статья для таких строителей, как вы. Какие идеи из второй части вы уже внедрили?
В прошлый раз мы говорили о том, как можно применять паттерн «Разделяй и властвуй» к на первый взгляд неразрешимым задачам, разбивая их на устойчивые, повторно используемые, самодостаточные блоки разного размера.
Сегодня мы рассмотрим случаи, когда разумнее делить на однородные части примерно одинакового размера — когда нет очевидного места, где «разрез» был бы наилучшим.
Иконография дизайн-системы
Настройка и развитие дизайн-систем чаще всего ложились на мои плечи в большинстве стартапов на ранней стадии. Хотя многие задачи в рамках работы над дизайн-системой соответствуют парадигме CDD (разработка, ориентированная на компоненты), о которой шла речь во второй части, существует целый класс подзадач, выполнение которых сводится к повторяющимся действиям и не может быть полностью автоматизировано. В таких случаях разумно разбить работу на части одинакового или схожего размера и последовательно пройтись по всему списку, шаг за шагом.
Пример иконографии. Источник: storybook.js.orgЯркий пример такой подзадачи — иконография. Когда дизайнеру нужно устранить несоответствие между набором иконок, который «почти подходит», но всё же не совсем, ему приходится прогонять каждую иконку через свою «мясорубку» вручную — подгоняя размеры, оттенки, толщину линий, форматы и прочее. В такие моменты особенно важно подобрать хороший плейлист, который поможет скоротать время.
Преобразование существующей инфраструктуры в инфраструктуру как код (IaC)
Определять вашу облачную инфраструктуру в виде кода — это то, что я рекомендую начать делать как можно раньше, сразу же при её создании. Однако личный опыт показывает, что в большинстве случаев вы начнёте работать с уже существующей инфраструктурой.
// Подтягивайте существующие ресурсы и постепенно заменяйте
// их новыми.
this.vpc = Vpc.fromLookup(this, 'ExistingVPC', { vpcId: 'legacy-vpc-id' });
Вы можете разделить сервисы, которые нужно импортировать, на пакеты по n штук. Затем вы можете обрабатывать их по одному. Это замедлит процесс, но необходимо для постепенного перехода от устаревших конструкций к тем, что созданы с помощью IaC (Infrastructure as Code). Такие миграции будут почти мгновенными для бессостоящих элементов, таких как сетевые настройки или функции Lambda. Однако для состоящих элементов, например баз данных или пулов пользователей, они будут значительно сложнее. Обращайтесь, если нужна помощь или обсуждение.
Файлы Storybook
Теперь, когда ваш Storybook настроен, у каждого веб-компонента будет отдельный файл со стори. Если вы начинаете с нуля, следуйте определению готовности (Definition of Done, DoD) и создайте файл как минимум с одной базовой историей. Если вы унаследовали существующую кодовую базу, вы можете посвятить время итерациям и обогащению существующих компонентов такими файлами.
Базовый файл компонента Storybook
Получившаяся интерактивная историяПо мере продвижения я рекомендую структурировать иерархию всех ваших компонентов и страниц в библиотеке в виде дерева, которое повторяет структуру папок в коде. Вам нужно, чтобы компоненты располагались в дереве как можно выше, но не выше, чем необходимо. Документирование компонентов с помощью Storybook может помочь визуально определить, нужно ли опустить что-то вниз или поднять выше по иерархии.
Тестовые файлы
Поскольку тестовый фреймворк был установлен и настроен в рамках оснащения необходимыми контекстно-независимыми инструментами разработки, теперь вы можете приступать к простым задачам партиями по x штук.
В первой части статьи упоминаются smoke-тесты и snapshot-тесты.
...
// Smoke test
it('renders without crashing', () => {
const container = document.createElement('div');
const root = createRoot(container);
root.render(<Hint text={'Hint'} />);
});
// Snapshot test
it('renders correctly', () => {
const view = render(<Hint text={'Hint'} />);
expect(view).toMatchSnapshot();
});
Эти тесты повторяются при написании и не требуют глубокого осмысления. Всё, что вам нужно сделать — это дополнить каждый компонент, будь то пакет, React-кнопка или конструкция Amazon Web Services (AWS) CDK, дополнительным файлом, как описано в вашем документе DoD (Definition of Done). У вас будет столько таких файлов, сколько у вас тестируемых самостоятельных компонентов. Пройдитесь по всем итеративно и добавьте эти несколько строк кода.
Отслеживание событий аналитики
Meta известна тем, что отслеживает около 50 000 точек данных о вас. Ваш стартап, вероятно, не нуждается в таком объёме отслеживания, но вы хотите собирать аналитику по важным событиям. Не стоит с первого дня внедрять 50 тысяч случайных событий. Такой уровень сложности приходит с опытом и зрелостью.
// Типичная аналитика корзины пользователя.
await analyticsAddToCart({
currency,
items: products.map(({ id }) => id),
webappUserId: user.username,
value: numberOfItems,
})
Часто я наблюдаю, что разработчики, которым предстоит реализовать отслеживание аналитических событий, ожидают, что маркетологи точно знают, какие события они хотят отслеживать. «Дайте нам список того, что вы хотите, и мы расставим приоритеты», — часто слышу я. Если только это не опытные специалисты, которые уже сталкивались с таким же типом продукта, обычно это не так.
Однако, если такой список будет составлен, его можно разбить на управляемые части и доставлять каждую часть ежедневно или за спринт.
При покрытии вашей кодовой базы отслеживанием событий я рекомендую не усложнять и двигаться от грубого к более точному. Ограничьтесь простыми событиями, такими как просмотры страниц и прокрутки за пределы видимой области. Затем добавьте поисковые запросы и длительность сессий. Позже можно стать более детальным и собирать данные о товарах в корзине и их связи с рекомендациями, которые ваша система выдала на основе их поисковых намерений.
Моделирование бизнес-сущностей
Надеюсь, вторая часть статьи убедила вас вложить силы в моделирование вашего бизнеса с помощью UML (Unified Modeling Language) или его аналога. Если вы приняли это мудрое решение, теперь вам предстоит заполнить вашу модель бизнес-сущностями, которые регулярно используются по всей компании. Существует список часто используемых сущностей, таких как пользователи, запросы, сообщения в чате и т.д. Но, безусловно, есть и специфичные для вашего бизнеса сущности.
Базовая диаграмма вариантов использования UMLМой совет — начать с разработки ERD, или диаграммы «сущность-связь» (Entity Relationship Diagram). Каждая значимая бизнес-сущность должна быть отражена с теми атрибутами, которые вы хотите хранить вместе с ней. Связывайте их, используя обозначение «куриной ножки» (chicken leg notation).
Товар может входить в ноль или множество корзин. Корзина может содержать ноль или множество товаров.Примите более высокий, концептуальный уровень восприятия вместо низкоуровневого мышления в стиле таблиц базы данных. Хотя атрибуты изображаются как часть конкретной сущности, их не обязательно реализовывать в одном и том же хранилище данных. Особенно это актуально для распределённых систем, которыми являются большинство современных платформ. Можно также использовать соглашения онтологий RDF или OWL, но это тема для другого раза.
Существует немного программ для моделирования, независимых от операционной системы, которые действительно стоят вашего внимания и денег. Я всегда рекомендую StarUML, так как это самый близкий к моему представлению софт для анализа, при этом недорогой.
Заключение
Этот текст изначально был написан, чтобы не повторяться.
Действительно, во всех компаниях, где я работал, без исключения, пытались сделать всё одновременно или уделяли слишком много внимания второстепенным вещам в ущерб основным, жертвуя эффективностью и тратя деньги нерационально.
Я не указываю пальцем — мы все иногда не видим леса за деревьями. Я тоже в этом виноват. Главное — заметить это вовремя или поставить себя в такие условия, где вероятность этого минимальна. Вот почему мы используем фреймворки. Они задают рамки нашей работы, уменьшая влияние человеческого фактора. «Разделяй и властвуй» — один из таких подходов.
Если то, что вы прочитали, кажется здравым смыслом, так и есть. Большинство работающих вещей — на удивление просты. Я ничего не изобрёл. Никто этого не делает. Это проверенная временем практика, заимствованная из других дисциплин, где подобные методы — стандарт для достижения целей. Уверен, они подойдут и вам.
Особая благодарность
Эта серия статей не была бы возможна без бесценных вкладов Lilian T. , Farouq Aldori, Teppo Hudsson, Jarek Owczarek, Nickolay Tsybulyanko, и Jason Collins.