Проектування систем — це складно. А співпраця — ще складніше.
Обговорення проектування системи з п’ятьма чи шістьма людьми може бути дуже ефективним.
Але це також може призвести до п’яти або шести абсолютно різних ідей щодо того, про що ви домовились. Через тиждень чи два обговорення може стати далекою пам’яттю.
Виникатимуть питання типу: “Хіба ми не вирішили робити це так?” або “Стривай, чому ми не можемо зробити це так?”. І сесія проектування, яку ви провели, стане марною.
Давайте виправимо це за допомогою Design Records.
Design Records
Design Records — це візуальні записи, які фіксують, уточнюють, спрощують і документують рішення щодо проектування системи. Вони є чудовим центром для будь-якого обговорення, яке можна створити під час зустрічі з проектування або підготувати заздалегідь. Вони допомагають повернути людей до фокусу, створюють залучення та зрозумілу візуальну допомогу, а також гарну поверхню для критики.
Я люблю структурувати Design Records наступним чином.
- Опис проблеми (Given, When, Then)
- Діаграма послідовності
- Інша діаграма
- Запис зустрічі з проектування
- Опціональний статус зворотного зв'язку для майбутніх записів
Кожен з цих розділів розроблений для того, щоб допомогти
- Створити ясність
- Виявити граничні випадки
- Уточнити вимоги
- Розширити перспективу
- Розібратися з проблемами інфраструктури
- Пам’ятати, про що ви говорили минулого тижня.
Я продемонструю це на прикладі.
Приклад проблеми
“Я хочу отримати CSV, що описує замовлення бургерів після перевірки наявності товару.”
Скільки крайніх випадків ви можете знайти прямо зараз, не продовжуючи читати статтю?
Давайте розберемо це.
Крок 1. Уточнення проблеми за допомогою “Given-When-Then”
Given: Наявність інвентарю для всього замовлення
When: Я отримую дійсний CSV з бургерами
Then: Я створюю замовлення на бургери
And: Надсилаю його на кухонний сервіс
Просто структурація мови таким чином може викликати кілька запитань.
- Що відбувається, якщо інвентарю немає? Чи я роблю стільки бургерів, скільки можу, чи відразу відхиляю замовлення?
- Що таке дійсний CSV з бургерами?
- Що відбувається, якщо він недійсний?
- Чи перевіряю я його по рядках або як цілий файл?
Це важливий етап для створення поверхні для перевірки і має допомогти вам розгорнути ваші вимоги на основі цього.
Більше про це можна прочитати тут.
[
6 кроків до чудових функціональних вимог
Чому вам потрібні хороші критерії прийняття
levelup.gitconnected.com
](/language-has-taken-us-a-long-way-from-the-caves-into-towns-and-cities-and-modern-civilization-82db61f169d2?source=post_page-----a230b664b7c1--------------------------------)
Крок 2. Діаграми послідовності
Моя улюблена частина.
Діаграми послідовності чудові, оскільки вони:
- Менше нудні, ніж текст
- Легко створюються
3.
Легко зрозуміти
sequenceDiagram
title Замовлення бургера з файлу
participant S3 as S3 Folder
participant BO as Burger Order
participant IS as Inventory Service
participant KS as Kitchen
note over BO: Наявність інвентарю для всього замовлення
S3->>BO: Дійсний CSV з бургерами
BO->>IS: Перевірити інвентар
IS →>BO: 200 OK (Інвентар дійсний)
BO->>KS: Замовлення бургерів
KS →>BO: 202 Accepted (Замовлення отримано)
BO →>S3: 201 Created (Замовлення надіслано)
Витративши час на створення такої діаграми, ви отримаєте багато запитань від різних зацікавлених осіб.
Інфраструктура:
- Як файл потрапляє на S3?
- Чи можна змінювати файли?
- Як S3 сповістить сервіс про замовлення?
- Які вимоги до дозволів?
Розробники:
- Які випадки валідації?
- Як щодо випадків помилок?
- Як нам відображати помилки?
- Чи будуть інші способи замовлення бургера, чи враховано це в моєму проєкті?
- Інтеграція з аналітичною платформою?
- Як і коли ми повідомляємо, що замовлення було прийнято чи оброблено?
Може я просто дивний, але мені насправді подобається створювати діаграми, оскільки це не так складно, якщо поєднувати копіювання, вставку та редагування.
Якщо цього недостатньо лінивим способом, ви можете навіть попросити штучний інтелект допомогти як із малюванням діаграми, так і з перевіркою самого проєкту. Одне з моїх відкриттів полягає в тому, що чітко пояснити ідею людині — це те саме, що пояснити її штучному інтелекту.
Штучний інтелект просто краще ітераціонує ці ідеї.
Чудові питання для обговорення:
“Подивіться на кожну з цих системних взаємодій і спробуйте проаналізувати дизайн, зважаючи на найбільш поширені https помилки” — Чи можете ви генерувати повідомлення про помилки для цих випадків?
“Які питання інфраструктури можуть виникнути у разі використання AWS з lambdas у vpc ….. (можливо, надайте архітектурну діаграму)”
“Використовуючи принципи доменно-орієнтованого дизайну, поставте мені серію запитань, щоб допомогти визначити сильні домени та обмежені контексти”
“Згенеруйте мій код…”
Навчіться використовувати найкращий інструмент для малювання діаграм у світі, читайте мій пост:
[
Найбільш недооцінений інструмент у розробці
Коли ви оптимізуєте, слід враховувати три речі.
levelup.gitconnected.com
](/the-most-underrated-tool-in-engineering-dc3c7f68000a?source=post_page-----a230b664b7c1--------------------------------)
Крок 3. Записуйте зустрічі для фіксації рішень
Додавання відеозапису вашого обговорення проєкту — це простий, але неймовірно потужний крок для довгострокової ясності та узгодженості. Це відповідає на класичне питання “Про що ми говорили минулого тижня/місяця/року/години і чому ми так захоплювалися цим?” і допомагає новим членам команди або відсутнім зацікавленим особам швидко наздогнати.
Поради для ефективних записів:
Використовуйте інструменти як Loom, Zoom, Google Meet, Microsoft Teams, щоб безшовно записувати зустрічі.
Візьміть транскрипт. Нехай штучний інтелект підсумує транскрипт.
Виділяйте важливі рішення або ключові моменти, зазначаючи часові мітки. Наприклад:
— “Часова мітка 05:32: Рішення валідовати весь CSV як ціле.”
— “Часова мітка 12:48: Обговорення кодів помилок для невідповідності інвентарю.”Хоча це може бути часозатратним процесом, інструменти ШІ стають набагато кращими в цьому і можуть допомогти прибрати цю рутину з вашого життя.
Поділіться посиланням на запис разом з записом проєкту, щоб було легко отримати доступ до контексту.
Не забудьте зупинити запис, перш ніж почати нарікати на своїх колег.
Крок 4. Залиште це в репозиторії
Git — це чудово. Його розробив Лінус Торвальдс і все таке.
Чому варто комітити записи проєктів у репозиторій?
- Версіонування: Зміни у документах проєкту відслідковуються через значущі повідомлення комітів. Ви завжди можете повернутися до попередніх версій або порівняти їх.
- Доступність: Зацікавлені особи, які пропустили зустріч, можуть переглянути проєкт без потреби у ще одній зустрічі.
3.
Співпраця: Pull requests дозволяють залишати коментарі та проводити перевірки перед остаточним затвердженням дизайну, що сприяє спільній відповідальності. - Еволюція ідей: Легко побачити, як дизайни змінюються з часом. Ви можете відповісти на питання, як-от: “Чому ми це змінили?” або “Як виглядала попередня версія?”
- Легко знайти: Скільки разів ви писали хорошу документацію, щоб потім викинути її в бездонний вічний ефір, який називається Confluence?
Бонусний крок. Поділіться своїми дизайнами
Проблеми рідко існують в ізоляції.
Ймовірно, що інші команди у вашій компанії зіткнуться з подібними проблемами. Якщо ви реалізуєте добре спланований дизайн, у вас вже є рішення з готовим кодом, інфраструктурою, перевіркою та роздумами.
Приклади: Системи сповіщень, Комунікаційні системи, Системи обміну файлами, Архітектури на основі подій, Централізоване логування, Системи метрик.
Висновок
Ефективні обговорення дизайну (і пам’ятання про них) є основою хороших програмістських команд.
Записи дизайну можуть допомогти уточнити вимоги, виявити крайні випадки та забезпечити узгодженість усіх учасників — що призводить до кращих дизайнів і менше помилок, які можуть значно збільшити вартість доставки.
З мого досвіду, підтримка цієї ідеї приходить дуже легко, і людям це подобається.
Вам варто це робити.
Якщо вам сподобався цей пост і він був корисний…
Дайте йому аплодисменти (або 50 — вони безкоштовні)! 👏
Слідкуйте за мною для отримання більше.
Є думки, ідеї чи питання? Залиште коментар нижче.
Поділіться цим постом з вашою командою.
Хочете більше? 🍔
Перегляньте ці схожі пости:
[
Чому Story Points не мають сенсу
Час для сповіді.
levelup.gitconnected.com
](/why-story-points-dont-make-sense-117fabdac8ca?source=post_page-----a230b664b7c1--------------------------------)
[
Одна річ, яку потрібно зробити, щоб збільшити продуктивність розробки в 10 разів — без ШІ
Одна річ, яку потрібно зробити, щоб збільшити продуктивність розробки в 10 разів — без ШІ
Одна річ, яку потрібно зробити, щоб збільшити продуктивність розробки в 10 разів — без ШІgarrett-james-cassar.medium.com
](https://garrett-james-cassar.medium.com/the-one-thing-you-need-to-do-to-10x-development-productivity-without-ai-813f6f7437f8?source=post_page-----a230b664b7c1--------------------------------)
[
6 кроків до відмінних функціональних вимог
Чому вам потрібні чудові критерії прийняття
levelup.gitconnected.com
](/language-has-taken-us-a-long-way-from-the-caves-into-towns-and-cities-and-modern-civilization-82db61f169d2?source=post_page-----a230b664b7c1--------------------------------)
Перекладено з: How to Run System Design Meetings that Actually Work