English for Presenting Architecture Decisions During a Walkthrough
Вивчіть англійські фрази, які використовуються для проходження команди або зацікавлених осіб через діаграму архітектури, пояснення компромісів і чітких відповідей на запитання.
Проходження архітектури відрізняється від письмового документа проекту — ви оповідаєте діаграму наживо, відповідаєте на питання на місці, і коригуєте ваше пояснення на основі того, що кімната розуміє або не розуміє. Цей посібник містить англійську фразу, яка описує, як це зробити, зокрема, як пояснити компроміси і як обробляти відкидання у реальному часі.
Ключовий словник
** Розповідь діаграми ** — опис потоку системи у логічному порядку (зазвичай, за напрямком пересування даних або запитів), замість випадкового пересування між блоками.
- “Я буду розповідати це зліва направо, слідуючи за запитом від клієнта через шлюз, в рівень обслуговування, і вниз до бази даних.” *
** Комбінація** — навмисний вибір між двома варіантами, кожен з яких має свою вартість, описаний у огляді, назвавши обидві сторони, а не просто захищаючи вибраний варіант. “Ми обміняли послідовність на доступність — у мережевому розділі ця служба продовжує обслуговувати читання зі застарілого репліки, а не повертає помилку.”
** Збільшення / зменшення масштабу ** — перехід між оглядом високого рівня і докладним поясненням певного компонента, звичайний спосіб керування увагою аудиторії під час огляду.
- “Дозвольте мені на секунду зменшити масштаб, перш ніж я глибше займуся чергою — на високому рівні, вся ця підсистема існує для від’ єднання обробки замовлень від обробки платежу.” *
** Відкладене питання ** — питання, яке було поставлено під час огляду, але яке було підтверджено, але навмисно розглянуто пізніше, щоб уникнути втрати поточного пояснення. “Це чудове питання про обробку помилок — я розгляну це в наступному розділі, тому дозвольте мені затриматися там і повернутися до вас.”
** Припущення (явно зазначене) ** — обмеження або очікування, на які покладається дизайн, викликане безпосередньо, щоб аудиторія могла поставити під сумнів його, якщо воно неправильне.
- “Ця схема передбачає, що обсяг запису залишається нижче 500 запитів за секунду. Якщо це припущення виявиться хибним, то підхід, заснований на черзі, тут потрібно буде переглянути»
Звичайні фрази
- «Давайте прослідкуємо за запитом зліва направо»
- «Я збільшу тут, перш ніж зайти в деталі цього компонента.»
- «Ми обміняли [X] на [Y] тут, і ось чому це мало сенс для наших обмежень»
- «Готове питання — я захоплюся цим за хвилину, дозвольте мені тримати його там»
- “Ця конструкція приймає [X]. Якщо це неправильно, нам потрібно переглянути цю частину»
Приклади висловлювань
Відкриття екскурсії за допомогою орієнтації аудиторії перед зануренням:
- “Перед тим, як я проаналізую кожне поле, ось версія у одному реченні: ця система відокремлює швидкий синхронний шлях, на який чекає користувач, від повільного асинхронного шляху, який виконується у фоновому режимі. Не забувайте про це, коли ми будемо продовжувати детально розбиратися в деталях»
Пояснюючи компроміс чесно, включаючи і мінуси:
- “Ми обирали можливу послідовність для індексу пошуку, що означає, що новостворений елемент може не з’ являтися у результатах пошуку протягом декількох секунд. Це справжній компроміс — пошук іноді буде застарілим — але це дозволяє нам зберігати шлях запису швидко, що має більше значення для цього випадку використання.”*
Як обробляти питання, що відкидаються, не вступаючи в оборону: “Це справедливий виклик — ви праві, що це додає новий пункт невдачі. Ми погодилися з цим, тому що альтернатива, робити це синхронно, додало б 200 мс до кожного запиту. Я щасливий пройти через обробку помилок для цього компонента, якщо це допоможе.»
Відкладання питання плавно без його відкидання: “Це стосується поведінки повторних спроб, яку я розгляну через два слайди — дозвольте мені зупинитися на секунду і повернутися до неї, щоб не перестаратися.”
Професійні поради
- ** Розповідати діаграми у послідовному напрямку ** (зазвичай, за запитом або потоком даних) — пересування по діаграмі заплутує аудиторію, яка намагається створити ментальну модель у реальному часі.
- Завжди вкажіть компроміси як ** обидві сторони **, а не тільки користь від вибору, який ви зробили - “ми обміняли X на Y” є більш правдоподібним, ніж “цей підхід краще”, тому що він визнає реальну вартість.
- Використовуйте “дозвольте мені зменшити масштаб” і “дозвольте мені зайти глибше” явно як вербальні позначки — вони допомагають аудиторії відстежувати, чи ви даєте загальний огляд або докладне пояснення в будь-який момент.
- При відкладанні питання, **назвіть, коли ви його розглянете ** (“Я розкрию це за хвилину” / “давайте розглянемо це після проходження”) замість нечіткого “хороше питання, пізніше” - це заспокоює людину, що вони насправді отримають відповідь.
- Коли викликають наживо, ** визнайте дійсну частину відсічі перед відповіддю ** - “це справедлива точка” не коштує нічого і робить ваше пояснення краще, ніж негайний захист.
Практичні вправи
- Напишіть одне речення, яке ви б дали перед тим, як зайнятися гіпотетичною діаграмою архітектури.
- Напишіть два речення, у яких пояснюється компроміс, назвавши як переваги, так і витрати.
- Напишіть речення, у якому ви відкладаєте питання, але точно вказуєте, коли ви до нього повернетесь.
Недоліки: Неможливість використовувати інші мови
Представлення архітектурних рішень не просто показує діаграму; це про те, щоб сформулювати * чому * вибір був зроблений і керувати очікуваннями. Часто, найбільш складним аспектом для не-рідних носіїв є переклад технічних міркувань на ясну, переконливу англійську. Не достатньо просто стверджувати факти - вам потрібно оформити їх таким чином, щоб вони відповідали розумінню аудиторії і активно вирішували потенційні проблеми. Подумайте про те, як ви пояснюєте складну концепцію другу; ви розбиваєте її, використовуєте аналогії, які можна порівняти, і передбачаєте їхні запитання. Такий же підхід застосовується під час проходження.
Поширена пастка - це представлення рішень як абсолютних істин. Замість того, щоб сказати «Ми обрали React, тому що це найшвидше», спробуйте щось на зразок: «Ми обрали React в цьому випадку через його встановлену екосистему і знайомість розробників в нашій команді - фактори, які значно скорочують час впровадження і потенційні проблеми з інтеграцією, які, на нашу думку, є ключовими пріоритетами, враховуючи часову шкалу проекту». Це демонструє продуманий підхід, а не декларативне твердження. Аналогічно, уникайте жаргону, коли це можливо, і завжди пояснюйте технічні терміни чітко - навіть якщо ви часто використовували їх внутрішньо.
Під час перегляду коду, наприклад, замість того, щоб сказати « Це порушує принципи SOLID », ви можете запропонувати: « Я помітив, що цей клас має високу зв’ язність з іншими; рефакторизація для зменшення залежностей буде відповідати нашим архітектурним цілям, що сприяють підтримці і перевірці ». Цей підхід зосереджується на * впливі * рішення, а не просто на вказівці на порушення правил. Аналогічно, в повідомленні Slack, що пропонує зміну архітектури, уникайте сказати «Це краще». Замість цього: «Я пропоную нам рухатися до архітектури мікросервісів, щоб поліпшити масштабованість і ізоляцію помилок - це дозволить нам незалежно масштабувати компоненти, коли зростає попит»
Нарешті, активне залучення зворотнього зв’язку є критичним. Завершуючи питаннями на кшталт: «Чи відповідає цей підхід вашому розумінню довгострокових потреб системи?» або «Чи є якісь потенційні ризики, які ви передбачаєте, що ми не розглядали?» демонструє відкритість і сприяє співпраці. Це показує, що ви цінуєте їх внесок і готові адаптувати своє пояснення на основі їхньої перспективи - ключовий елемент ефективного спілкування. Пам’ятайте, що презентація архітектури - це створення консенсусу, а не диктованих рішень.