Англійська мова для архітектурних оглядів: як дати і отримати зворотній зв'язок проекту

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

Архітектурно-будівельний огляд

** Масштабування** — здатність системи обробляти збільшене навантаження за допомогою додавання ресурсів. Розрізняти вертикальне масштабування (потужніше обладнання) і горизонтальне масштабування (більше екземплярів). « Головною проблемою, з якою я зіткнувся під час розробки цього проекту, є горизонтальне масштабування — спільний кеш сеансів стає в’ язкою, коли ми додаємо більше вузлів програм »

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

** Сполучення ** — ступінь залежності між компонентами. Високий рівень зв’ язку означає, що зміна одного компонента вимагає зміни інших компонентів. « Пряме викликання бази даних з служби A до схеми служби B створює сильний зв’ язок — це означає, що обидві служби слід розгортати разом кожного разу, коли змінюється схема. »

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

** Вузький вузол ** — компонент, який обмежує пропускну здатність або швидкодію всієї системи. « Синхронне викликання служби створення PDF є вузьким вузлом — його виконання може тривати до 8 секунд, що блокує всю нитку запиту. »

** Одна точка відмови (SPOF) ** — компонент, який при відмові призведе до аварійного завершення роботи всієї системи. « Поточний проект має одну точку відмови у брокері повідомлень; якщо він відмовиться від роботи, всі асинхронні завдання припинять обробку. »

** Радіус вибуху ** — обсяг впливу, якщо компонент зазнає невдачі. « Відокремивши службу сповіщень у її власне розгортання, ми зменшуємо радіус вибуху у разі невдачі — аварія у сповіщеннях не вплине на обробку замовлень. »

** Ідемпотентність ** — властивість операції, яку можна безпечно повторювати без зміни результату після першого виконання. Критично важливо для логіки повторення. « Перед тим, як ми схвалимо стратегію повторення, нам слід переконатися, що кінцева точка нижче є ідемпотентною; у іншому випадку повторення може створити дублікати замовлень. »

** Послідовність у майбутньому** — модель послідовності, за якої, якщо буде надано достатньо часу без нових оновлень, всі копії набору даних зближаться до одного значення. « Ця модель передбачає послідовність у майбутньому для кількості запасів, що є прийнятним для показу, але потребує більшої гарантії послідовності у моменті придбання »

Як дати конструктивну критику на дизайни

Мета перегляду архітектури полягає у поліпшенні дизайну, а не у демонстрації ваших знань. Оцініть результати, а не недоліки.

Повідомлення про занепокоєння (без нападу):

• «Я хочу попередити про потенційну проблему зі стратегією кешування — якщо кеш і база даних ненадовго не синхронізуються, користувач може побачити застарілу інформацію про ціни при оформленні. Чи це прийнятний ризик?»
• «Я не впевнений, що поточний дизайн обробляє сценарій невдачі, де [X відбувається]. Як система поводиться в цьому випадку?»
• «Одна річ, яку я б трохи відкинув, це вибір X — чи можете ви допомогти мені зрозуміти роздуми? Я хочу переконатися, що я не втрачаю контексту»

Пропоную альтернативу:

• «Один варіант, який варто розглянути, це [X], тому що він уникає проблеми з’єднання, яку я підняв, хоча я визнаю, що там також є компроміси»
• «Альтернативним підходом, який деякі команди використовують для цієї проблеми, є [Y]. Це може не бути правильним рішенням тут, але це варто мати на увазі»

Визнання того, що працює:

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

Як реагувати на занепокоєння

Професійно приймати критику так само важливо, як і давати її. Ці відповіді роблять огляд конструктивним.

Відповідь на законне запитання:

• «Це справедлива точка зору — я не повністю продумав сценарій повторної спроби. Дозвольте мені переглянути цю частину»
• “Ви праві, що тісне з’єднання тут є проблемою. Я думаю, ми можемо розв’язати це за допомогою [X]»
• “Це хороший половець. Я додам зауваження до документації проекту і ми можемо обговорити зменшення в подальшому»

Захист рішення з поясненням причин:

• «Ми розглядали цей підхід, але ми відкинули його через [особливу причину]. Чи це вирішує вашу проблему, або ви думаєте, що компроміс все ще не працює?»
• “Причиною, чому ми обрали X, а не Y, було [пояснення]. Я відкритий до перегляду цього, якщо ви вважаєте, що компроміс неправильний»

Граціозно відкладаючи:

• «Це хороший виклик, і я хочу дати йому правильну відповідь — чи можу я взяти це як пункт дій і продовжити до кінця тижня?»
• “Я не маю достатньо даних, щоб відповісти на це з впевненістю зараз. Дозвольте мені витягти числа і повернутися до вас»

Приклад архітектурного перегляду фраз у контексті

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

2. “Радиус вибуху від несправності в запропонованій службі спільної конфігурації досить великий; якщо вона стане недоступною, кожна залежна служба не зможе запуститися. Я рекомендую зробити завантаження налаштувань стійким до помилок, кешуючи останні відомі хороші значення локально.”

3. «Це справедливий виклик на кінцеву модель послідовності — ви праві, що застарілий читання при оформленні може призвести до перепродажу. Ми повинні додати явну вимогу послідовності до потоку покупок і документувати, що кінцева послідовність прийнятна тільки для сторінки списку продуктів. ”

4. «Я хочу позначити одну точку невдачі в поточній установці брокера повідомлень; перед тим, як це перейде в виробництво, я б хотів побачити конфігурацію високої доступності або документований підручник з відновленням з перевіреним RTO.»

5. «Ви праві, що в’язке місце, яке я визначив, є реальною проблемою, але я думаю, що ми можемо розв’язати її без повного перепроектування — перенесення генерації PDF на асинхронне завдання і негайне повернення ідентифікатора завдання виключить поведінку блокування»

Навигація Nuance: Common Phrases for Architectural Feedback (англійською)

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

Однією з областей, де багато розробників борються, є обговорення компромісів. Просто заявивши, що «це не масштабоване», не зменшиться. Замість цього, намагайтеся формулювати так: “Хоча цей підхід пропонує негайний прибуток в продуктивності, ми повинні розглянути потенційні обмеження масштабованості, оскільки наша база користувачів зростає. Зокрема, поточна схема бази даних може стати в’ язким місцем, якщо ми очікуємо X одночасних користувачів протягом [часового інтервалу]. Можливо, дослідження шардованої архітектури або стратегій кешування може зменшити цей ризик. “Зауважте, як це включає в себе як визначену проблему, так і запропонований напрямок для подальшого дослідження - демонструючи проактивне мислення. Аналогічно, коли ви обговорюєте * з’ єднання *, не просто скажіть « це занадто взаємопов’ язано ». Замість цього спробуйте: « Високе з’ єднання між модулями А і Б створює залежності, які можуть перешкоджати майбутнім модифікаціям або незалежним розгортанням. Ми повинні оцінити, чи можемо ми ввести посередницьку службу для від’єднання цих компонентів»

Інша часте завдання виникає під час перегляду коду, коли йдеться про проблеми з вибором дизайну. Важливо вийти за рамки критики результату і зосередитися на основних міркуваннях. Замість того, щоб сказати «це поганий дизайн», більш конструктивний підхід може бути: «Я переживаю, що ця монолітна структура може призвести до збільшення складності в майбутньому обслуговуванні і потенційних конфліктів під час злиття. Чи не розглядали ми можливість розбити цей компонент на менші, більш управлянні модулі?» Це переносить розмову на розуміння того, * чому* прийнято це рішення, і відкриває діалог щодо альтернативних рішень. Не забувайте завжди вводити свій відгук з підтвердженням будь-яких позитивних аспектів - “Я ціную зусилля, які ви вклали в спрощення цього процесу, проте…”

Нарешті, при повідомленні цих питань в описах Slack або PR, коротка і чітка мова є найважливішою. Замість довгих пояснень, скористайтеся такими фразами, як: « Запит на пояснення щодо довгострокових наслідків масштабованості цієї конструкції » або « Дослідження потенційних проблем з продуктивністю, пов’ язаних з [особливим компонентом] ». Підтримка професійного тону, навіть під час надання викликаючих зворотнього зв’ язку, створює атмосферу взаєморозуміння і сприяє співпраці — це те, що дуже цінується у будь- якій команді розробників.