Розділяй і владарюй: допоможіть вашому стартапу орієнтуватися в невідомому — Частина 3

Це третя частина трилогії статей, присвячених невідповідності між пітч-деком та готовим до використання продуктом, з якою стикаються всі стартапи.

Якщо ви їх пропустили, ось перша частина та друга частина.

З поверненням. Схоже, ви серйозно налаштовані. Ця стаття для таких будівничих, як ви. Які частини з другої частини цієї статті ви впровадили?

Минулого разу ми обговорювали, як можна використовувати патерн «Розділяй і владарюй» для, здавалося б, неосяжних проблем, розбиваючи їх на стійкі, повторно використовувані, самодостатні блоки різного розміру.

Сьогодні ми обговоримо випадки, коли натомість має сенс нарізати на однорідні частини приблизно однакового розміру, оскільки немає очевидного місця, де розріз був би найбільш доречним.

Іконографія дизайн-системи

Налаштування та розвиток дизайн-систем зазвичай лягали на мої плечі в більшості стартапів на ранній стадії. Хоча багато видів діяльності в роботі з дизайн-системою відповідають парадигмі CDD (Component-Driven Development), як обговорювалося в другій частині, цілий клас підзадач вимагає виконання повторюваних дій, які не можна повністю автоматизувати. У таких випадках має сенс розділити на частини еквівалентного або подібного розміру та пропрацювати весь список фрагмент за фрагментом.

Яскравим прикладом такої підзадачі є іконографія. Коли дизайнеру потрібно усунути невідповідність між набором іконок, який «майже підходить», але не зовсім, він має пропустити іконки через свій процес одну за одною, коригуючи розміри, тони, товщину обведень, формати тощо. Саме тут важливо знайти хороший плейлист, щоб час минав швидше.

Перетворення існуючої інфраструктури на IaC

Описувати вашу хмарну інфраструктуру як код — це те, що я рекомендую починати робити одразу, як тільки ви починаєте її будувати. Однак особистий досвід показує, що в більшості випадків ви почнете працювати з уже існуючим налаштуванням.

// Імпортувати наявні ресурси та поступово замінювати їх новими.

this.vpc = Vpc.fromLookup(this, 'ExistingVPC', { vpcId: 'legacy-vpc-id' });

Ви можете розділити сервіси, які потрібно імпортувати, на пакети по n. Потім ви можете опрацьовувати їх один за одним. Це сповільнить вас, але необхідно для поступового переходу застарілих конструкцій на створені через IaC (Infrastructure as Code). Такі міграції будуть майже миттєвими для stateless-речей, як-от мережеві конфігурації або lambda-функції. Однак для stateful-речей, таких як бази даних або пули користувачів, міграція буде значною. Зверніться до нас, якщо вам потрібна порада.

Файли Storybook

Тепер, коли ваш Storybook налаштовано, кожен веб-компонент матиме окремий файл зі сторіз. Якщо ви починаєте з нуля, дотримуйтесь Definition of Done (DoD) і створіть файл хоча б з однією базовою сторі. Якщо ви успадкували існуючу кодову базу, ви можете виділити час на ітеративне збагачення існуючих компонентів такими файлами.

У міру просування я рекомендую структурувати ієрархію всіх ваших компонентів і сторінок у бібліотеці як дерево, що повторює структуру папок коду. Ви хочете, щоб ваші компоненти були настільки високо в деревоподібній структурі, наскільки це необхідно, і не вище. Документування компонентів за допомогою 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) або еквівалента. Якщо ви зробили цей мудрий вибір, тепер вам потрібно буде регулярно наповнювати вашу модель бізнес-сутностями, які використовуються в компанії. Існує список загальновживаних, таких як користувачі, запити, повідомлення в чаті тощо. Але, безперечно, є й специфічні для бізнесу.

Моя рекомендація — почати з розробки ERD або діаграми зв'язків сутностей. Кожна релевантна бізнес-сутність має бути відображена з атрибутами, які ви хочете зберігати разом із нею. З'єднайте їх за допомогою нотації «пташина лапка» (crow's foot).

Дотримуйтеся вищого, концептуального погляду замість низькорівневого мислення на рівні таблиць бази даних. Хоча атрибути зображені як частина певної сутності, вони не обов'язково мають бути реалізовані в одному сховищі даних. Це особливо актуально у випадку розподілених систем, які становлять більшість сучасних платформ. Ви також можете використовувати конвенції RDF або OWL-онтологій, але це тема для іншого разу.

Не так багато кросплатформного програмного забезпечення для моделювання, гідного вашої уваги та грошей. Я завжди рекомендую StarUML, оскільки це найближче, що мені вдалося знайти до першокласного аналітичного ПЗ, не виходячи за межі бюджету.

Висновок

Цей матеріал спочатку був написаний, щоб не повторюватися.

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

Я не вказую пальцем. Ми всі за деревами не бачимо лісу. Я, безумовно, теж цим грішу. Хитрість полягає в тому, щоб помітити це достатньо рано або поставити себе в умови, де ймовірність цього стає низькою. Саме для цього ми використовуємо фреймворки. Вони обрамляють нашу роботу, вимикаючи людський фактор. «Розділяй і владарюй» — лише один з них.

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

Особлива подяка

Ця серія статей була б неможливою без безцінного внеску Lilian T. , Farouq Aldori, Teppo Hudsson, Jarek Owczarek, Nickolay Tsybulyanko та Jason Collins.

Малік АлімухамедовІнженер, технооптиміст, підприємець, письменник, музикант, інвестор і мінімаліст. Я прагну автоматизувати якомога більше в своєму житті. Письмо допомагає мені кристалізувати думки та керувати ними. Технології — це мій хліб насущний, а також моя пристрасть. Ви можете сміливо звертатися будь-коли.