Як обговорювати досвід розробників англійською мовою
Вивчайте словниковий запас і фрази для обговорення DX — досвіду розробника, ергономіки, когнітивного навантаження, тертя і інструментів — англійською мовою з впевненістю і точністю.
Досвід розробника — зазвичай скорочується як DX — став однією з найбільш обговорюваних тем у сучасних командах розробників програмного забезпечення. Незалежно від того, чи ви оцінюєте нову платформу, пропонуєте внутрішнє поліпшення інструментів або переглядаєте дизайн API, мова DX є специфічною і нюансованою. Для людей, для яких англійська мова не є рідною, знати, як говорити про DX чітко і точно, може справді змінити те, як сприймаються ваші ідеї.
Ключовий словник
** Досвід розробника (DX) ** — загальний досвід, який має розробник під час використання інструменту, платформи, API або внутрішньої системи. Добрий DX означає, що все працює інтуїтивно і швидко; поганий DX означає, що все працює повільно і неприємно. « DX у цій бібліотеці відмінний — документація зрозуміла, а типові значення розумні »
** Ергономічність ** — наскільки природно і зручно інструмент вписується у робочий процес розробника. Запозичено з промислового дизайну. « Ергономіка API вимкнено — вам слід передати п’ ять параметрів, щоб зробити базовий запит. »
** Когнітивна навантаження ** — розумові зусилля, необхідні для розуміння чи роботи з чимось. Зменшення когнітивного навантаження є основною метою хорошого DX. « Ця абстракція значно зменшує когнітивне навантаження — розробникам не потрібно думати про підлеглий транспортний шар »
** Тертя ** — будь- яка перешкода або непотрібна складність, що сповільнює розробника. « У локальному налаштуванні є багато тертя — запуск середовища розробки займає майже годину »
** Footgun ** — можливість або вибір дизайну, який робить простим стріляти собі в ногу (тобто, робити помилки). « Цей API повний footguns — легко викликати методи у неправильному порядку і отримати мовні помилки. »
** Боєрплеєр ** — повторюваний код, який має бути написано з невеликими відмінностями у багатьох місцях. Зменшення кількості типових параметрів часто називають поліпшенням DX. « Новий SDK вилучає багато типових параметрів — вам більше не потрібно налаштовувати контекст автентифікації вручну. »
** Escape hatch ** — спосіб обійти абстракцію, коли API високого рівня недостатньо. Good DX надає люки для виходу з системи, не вимагаючи їх для виконання звичайних завдань. « Я ціную те, що у фреймворку надано люк для виходу з системи для нетипової серіалізації — це заощадило нам багато часу. »
Фрази для оцінки DX
Коли ваша команда оцінює інструмент або платформу, ці фрази допоможуть вам зробити свій внесок у оцінку:
- «Опитування на борту є грубим — є занадто багато кроків налаштування, перш ніж ви отримаєте ‘hello world’ працює»
- «Поведення за замовчуванням є розумним, що значно зменшує криву навчання»
- «Повідомлення про помилки не допомагають — вони не кажуть вам, що ви зробили неправильно, просто щось не вийшло»
- «Вік до першого успіху вражає коротким — я мав робочу інтеграцію менше ніж за 20 хвилин»
- «Документація добре охоплює щасливий шлях, але не розглядає крайні випадки»
Фрази для обговорення когнітивного навантаження
Когнітивне навантаження — це абстрактна концепція, тому точність мови допоможе:
- Це вимагає від розробника мати занадто багато речей в голові одночасно»
- «Абстракція непроникна — вам все ще потрібно розуміти основу реалізації, щоб використовувати її правильно»
- «Приховуючи складність за одним викликом функції, ми зменшуємо когнітивне навантаження для викликаючого»
- «Назва є непослідовною, що додає непотрібні ментальні витрати»
- «Кожного разу, коли я повертаюсь до цієї кодової бази, я проводжу 30 хвилин, знову ознайомлюючись з собою — це знак того, що DX потребує роботи»
Фрази для підняття DX занепокоєння
Запропонування покращень DX часто означає пересування між короткостроковими зусиллями і довгостроковими наслідками:
- «Я хочу попередити DX про проблему з поточним процесом налаштування — це стає в’язкою для нових членів команди»
- “Тріщини тут реальні і це коштує нам часу. Я б оцінив 30 хвилин на розробника на тиждень, втрачених на обходження проблем»
- “Чи можемо ми подивитися на способи зменшення кількості шкідливих речовин у цьому? Це крихке і ніхто не любить писати про це»
- «Я б хотів запропонувати розробникам досвід, щоб відобразити на карті, де найбільші болючі точки.»
- «Хороший DX не є розкішшю — він безпосередньо впливає на нашу швидкість і нашу здатність залучати нових інженерів»
** spike ** у термінології Agile означає дослідження або дослідницьке завдання з обмеженим часом виконання. « DX spike » — це фраза, яку часто вживають у сучасних інженерних командах.
Фрази для похвали Good DX
Мова позитивного DX є так само корисною — вона допомагає вашій команді визначити, що слід захищати і реплікувати:
- Це має чудову ергономіку — API передбачуваний і типові значення просто мають сенс
- «Мені подобається, як ця бібліотека громко відмовляється — вона дає вам чітке повідомлення про помилку, вказуючи вам, що саме потрібно виправити»
- «Відкритий люк тут добре спроектований — ви майже ніколи не потребуєте його, але коли це робите, він працює чисто»
- «Налаштування з нульовою конфігурацією є величезною перемогою — це означає, що молодші розробники можуть бути продуктивними з першого дня»
Фрази, яких слід уникати
| Avoid | Try instead |
|---|---|
| ”This tool is bad." | "The DX here has some significant pain points — let me walk through them." |
| "Nobody can understand this." | "The cognitive load is high — it requires understanding three different abstractions at once." |
| "The docs are useless." | "The documentation covers the basics but doesn’t help with real-world scenarios." |
| "This is too complicated." | "There’s too much friction for a task that should be straightforward.” |
Краткий справочник
| Situation | Phrase |
|---|---|
| Praising DX | ”The ergonomics are excellent — the defaults are sensible.” |
| Criticising friction | ”There’s too much friction in the setup process.” |
| Discussing cognitive load | ”This requires the developer to hold too many things in their head.” |
| Proposing an investigation | ”I’d like to propose a DX spike.” |
| Noting a footgun | ”This API is easy to misuse — it’s a footgun.” |
| Quantifying impact | ”I estimate 30 minutes per developer per week is lost to workarounds.” |
Мова DX точна і переконлива. Розробники, які можуть чітко назвати проблеми, є тими, хто отримує купівлю-продаж для поліпшення - і в кінцевому підсумку робить їхні команди швидшими.
Наприклад, вивчення мовлення: вивчення мовлення в контексті
Будьмо чесними - дискусії про Developer Experience (DX) можуть швидко стати абстрактними. Сказати «це погано» не допоможе; нам потрібно сформулювати * чому * це почувається таким чином, особливо коли йдеться про такі речі, як когнітивна навантаження. Розробники не роботи; наш мозок має обмежену здатність обробляти інформацію. Коли завдання надто складне, погано задокументоване або вимагає розчаруючого взаємодії з інструментами, це додає до цього психічного навантаження - по суті, збільшуючи «тертя», як ви описали раніше. Визначення і вирішення когнітивного навантаження не стосується вимог до досконалості; воно стосується активного зменшення непотрібного навантаження, щоб розробники могли зосередитися на будівництві, а не на боротьбі з самим ланцюгом інструментів.
Поширений сценарій під час перегляду коду. Уявіть, що ви отримали коментар на зразок: « Це здається трохи важким — чи не могли б ми спростити це?» Без подальшого пояснення рецензент може бути сприйнятий як надто критичний. Ефективніший підхід - перетворити це відчуття на конкретні слова. Замість того, щоб просто сказати “зменшити когнітивне навантаження”, ви б пояснили як код робить свій внесок в це. Можливо, велика кількість вкладених if-заяви створює значну психічну перешкоду для когось, хто не знайомий з кодовою базою, або, можливо, відсутність чіткої документації змушує розробників витрачати надмірний час на те, щоб зрозуміти, як використовувати певну функцію. Формування зворотного зв’язку навколо конкретних впливів - “Глибоко вбудована умовна логіка тут збільшує когнітивне навантаження, особливо для нових членів команди.” - є набагато більш продуктивним і дієвим. Це перехід від суб’єктивного відчуття до об’єктивного спостереження і запропонування рішень.
Крім того, розуміння * джерела * когнітивного навантаження є критичним. Чи це погано розроблений API? Сложный рабочий процесс? Старий інструмент? Визначення цих основних причин дозволяє вам запропонувати цілеспрямовані поліпшення. Наприклад, якщо розробник бореться зі складним процесом збирання, запропонувавши автоматизацію або спрощену конфігурацію, можна безпосередньо полегшити навантаження. Не просто вказуйте на проблему; пропонуйте потенційні рішення, засновані на кращих інструментах і спрощених процесах.
Нарешті, пам’ятайте, що визнання когнітивного навантаження не означає звинувачення когось - це спільна відповідальність за оптимізацію середовища розробки. Це сприяє культурі емпатії і проактивного вдосконалення, що призводить до більш ефективних робочих потоків і щасливіших розробників. Давайте зосередимося на тому, щоб інструменти і процеси підтримували наше мислення, а не конкурували з ним.
# Example: Using `eslint` to identify potential complexity issues (simplified)
eslint . --max-complexity 5 # This command flags overly complex code based on a configurable limit