Як написати технічну пропозицію дизайну Перегляд коментаря англійською мовою
Практичний посібник англійською мовою для перегляду технічних проектних пропозицій — як сформулювати зауваження, задати прояснюючі питання і схвалити з впевненістю.
Перегляд технічної пропозиції проекту відрізняється від перегляду коду — ви оцінюєте ідею перед тим, як вона буде створена, часто через команди або часові пояси, повністю письмово. Для людей, для яких англійська не є рідною мовою, знайти правильний тон має таке ж значення, як і технічна суть: занадто м’який, і ваша занепокоєність буде проігнорована, занадто тупий, і це буде сприйматися як відкидання. У цьому підручнику ви знайдете словниковий запас і фрази для написання чітких, конструктивних коментарів щодо перегляду проекту.
Ключові фрази
** Позначення ризику ** — вказівка на потенційну проблему без твердження, що вона обов’ язково трапиться. “Один ризик, який я б тут позначив: якщо під час вікна перенесення трафік збільшиться, резервний шлях не буде описано.”
** Запит на пояснення ** — запит на більш докладні відомості щодо частини пропозиції, яка є неоднозначною або недостатньо визначеною.
- “Чи можете ви пояснити, що станеться, якщо на кроці 3 служби, що виконує завдання, виповниться тайм- аут?” *
** Запит на порівняння згідно з компромісом ** — прохання автора обґрунтувати рішення, порівнявши його з принаймні однією альтернативою.
- “Чи ви розглядали підхід, заснований на черзі, замість синхронних викликів? Це може бути варте речення про те, чому це було відкинуто.»*
** Умовне схвалення ** — схвалення пропозиції залежно від конкретної зміни або пояснення, яке буде зроблено. “Я в основном согласен с этим. Як тільки план відновлення буде додано, я з радістю схвалю.»
** Обсяг проблеми ** - підняття питання про те, чи намагається пропозиція вирішити занадто багато або занадто мало за раз. “Це виглядає як дві окремі пропозиції — чи варто нам розділити план міграції від нового дизайну API?”
** Неблокуюча пропозиція ** — коментар, який виражає переваги, але не повинен перешкоджати пропозиції рухатися уперед.
- “Не блокує: я б, мабуть, назвав цю службу більш специфічною, ніж « процесор », але це не так вже й багато.” *
** Виникнення прецеденту ** — посилання на подібне минуле рішення або існуючу систему для інформування поточної дискусії.
- “Ми зіткнулися з дуже схожою проблемою зі службою платежу минулого року — варто перевірити, як це було вирішено, перш ніж повторювати цей шаблон.” *
** Запит на діаграму ** — запит на додавання автором візуальної допомоги, оскільки письмовий опис важко зрозуміти. “Діаграма послідовності тут допоможе — у мене є проблеми з відстеженням, яка служба ініціює повторну спробу.”
Складні речення для різних ситуацій перегляду
- «Я хочу переконатися, що я розумію режим невдачі тут — що відбувається, якщо кеш недоступний?»
- “Ця частина мені здається трохи неоднозначною. Чи ми говоримо, що міграція є зворотною, або в одному напрямку?»
- «Я не бачу тут сильних заперечень, але я б хотів отримати другу думку від когось з команди даних, перш ніж ми завершимо це»
- “Все це виглядає твердо. Моє головне занепокоєння стосується часової шкали — три тижні здаються короткими, враховуючи перераховані залежності»
Складання детального огляду
Ясний коментар перегляду зазвичай має просту структуру: вказати проблему, пояснити, чому це важливо, і запропонувати шлях уперед.
- “Пропозиція не охоплює те, що відбувається при частковій невдачі. Це важливо, оскільки напівзавершена міграція може залишити дані у несумісному стані. Чи можемо ми додати розділ, що описує процедуру відновлення?»
- “Я помітив, що зміна схеми описується як зворотньо сумісна, але я не бачу, як старі клієнти оброблять нове обов’язкове поле. Чи може значення за замовчуванням вирішити це, або я щось пропускаю?»
Фрази, яких слід уникати
| Avoid | Try instead |
|---|---|
| ”This won’t work." | "I’m not sure this handles the retry case — can we walk through it?" |
| "You forgot about X." | "I don’t see X addressed — was that intentional, or should we add a section?" |
| "This is too complicated." | "Is there a simpler version of this that would meet the same goals?" |
| "I don’t like this." | "I have a preference for a different approach here — can I explain my reasoning?” |
Практичні вправи
- Напишіть коментар перегляду (3- 4 речення), у якому буде позначено відсутній план відновлення у пропозиції щодо проекту, але не вживатимуть образливих слів.
- Написати коментар з умовним схваленням пропозиції, з якою ви більшою мірою погоджуєтесь, але у якій відсутня одна важлива деталь.
- Переписати тупий коментар « цей дизайн занадто складний » на конструктивну, конкретну альтернативу.
Навигація Nuance: Специфічний словник для відгуку
Багато розробників, які вивчають професійну англійську, вважають тонкощі надання зворотнього зв’язку особливо складними. Це не просто заява про проблему; це про те, щоб сформулювати свою занепокоєність таким чином, що запрошує до співпраці і розуміння. Розглянемо деякі конкретні слова та шаблони фразування, які можуть значно поліпшити ясність, особливо коли йдеться про технічні пропозиції щодо дизайну. Ключовим елементом є перехід від обвинувальної мови до спостережень, зосереджених на результаті, якого ви намагаєтеся досягти. Замість того, щоб сказати «Це не масштабується», що відразу ж означає звинувачення, спробуйте «Я турбуюся про потенційні обмеження масштабованості цього підходу, враховуючи наш прогнозований ріст користувачів»
Зверніть увагу на дієслова, які переносять відчуття дослідження, а не пряму критику. Фрази на кшталт «Чи можемо ми дослідити…» або «Які у вас думки щодо…» демонструють відкритість і заохочують обговорення. Аналогічно, використання таких термінів, як «компроміси» визнає, що рішення про дизайн часто включають компроміси. Сказати «Це погана ідея» закриває розмову; пропонуючи «Давайте оцінюємо компроміси між продуктивністю і складністю тут» відкриває його для продуктивного обміну. Іншою важливою областю є точність - уникати нечіткого мовлення. Замість того, щоб сказати « Потрібно поліпшити », вкажіть * що * потрібно поліпшити: « Схему бази даних можна оптимізувати, щоб зменшити затримку запиту. »
Також розгляньте, як ви представляєте потенційні рішення, навіть якщо вони є попередніми. Фрази на кшталт «Може, ми могли б розглянути…» або «Альтернативний підхід може включати…» демонструють активне мислення і бажання робити позитивний внесок. Не просто підкреслюйте проблеми; пропонуйте пропозиції разом з вашими спостереженнями. Крім того, при обговоренні залежностей або зовнішніх систем використовуйте точну термінологію, пов’ язану з інтеграцією - « API endpoint », « синхронізація даних », « архітектура, керована подією » - це всі приклади технічного словника, який збудує впевненість і покаже вам розуміння більш широкого контексту. Корисною звичкою є послідовне звернення до документа * вимоги *; це забезпечить спільну точку відліку для обговорення.
Наконец, помните, что тон имеет огромное значение. Навіть добре складені речення можуть бути неправильно інтерпретовані, якщо вони надаються з критичним або відкидаючим ставленням. Стрімко і з повагою. Просте «Я запитав, чи…», за яким слідує конкретне питання, часто є більш ефективним, ніж насильницьке твердження про незгоду. Практикування цих фраз у моделях ситуацій — навіть якщо ви просто роздумуєте про можливі розмови — допоможе вам розвинути плавність і впевненість під час надання зворотнього зв’ язку під час перегляду коду або обговорення пропозицій щодо дизайну. Це про будівництво мостів, а не стін.