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

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

Ключовий словник

** Досвід розробника (DX) ** Загальна якість щоденного досвіду розробника з використанням внутрішніх інструментів, процесів і платформ - включаючи легкість використання, якість документації і тертя в спільних робочих потоках. *Приклад: “Ми зараз розглядаємо DX як першокласну метрику - ми щоквартально опитуємо інженерів про те, скільки тертя вони встигли в процесі розгортання.” *

Самообслуживание Інструмент або платформа, розроблена так, щоб користувачі могли виконувати завдання самостійно, без необхідності відкривати квиток або чекати на іншу команду.

• Приклад: « Для створення нового середовища тестування раніше потрібно було звертатися до команди з розробки платформи; тепер це повністю самообслуговування за допомогою внутрішнього порталу. »*

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

** Внутрішня платформа розробника (IDP) ** Централізована платформа, часто створена і підтримується спеціальною командою платформи, яка надає стандартизовані інструменти, абстракції інфраструктури і потоки робіт для інших інженерних команд. *Приклад: “IDP обробляє служби, управління секретами і конвеєри розгортання, тому команди продукту не вигадують цю інфраструктуру знову.” *

** Когнітивне навантаження (в контексті платформи) ** Ментальне зусилля, яке розробник має витратити, щоб зрозуміти і використовувати систему - ключова метрика платформи, яку команди намагаються зменшити за допомогою хороших абстракцій і документації. Приклад: “Цей новий CLI значно зменшує навантаження на когнітивні процеси — інженерам більше не потрібно запам’ятовувати шість окремих прапорців, щоб розгорнути базову службу.”

** Прийняття (внутрішнього інструменту) ** Ступінь, в якій інженерні команди фактично вибирають використовувати внутрішній інструмент, на відміну від просто доступу до нього - критичний і часто недооцінений метрик для успіху внутрішнього інструменту. Приклад: “Ми побудували функцію, але її прийняття є низьким — лише дві з дванадцяти команд перейшли, тому нам потрібно зрозуміти, що блокує решту.”

• Собачої їжі Використання вашого власного внутрішнього інструменту як регулярної частини потоку роботи вашої команди, як для перевірки його корисності, так і для виявлення проблем, перш ніж інші команди зіткнуться з ними.

• Приклад: « Ми самі перевіряємо інструмент розгортання для кожного з наших власних випусків, завдяки чому ми виявили цю ваду відновлення, перш ніж будь-яка інша команда встигла її виявити. » *

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

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

Звичайні фрази

** В обзорах коду: **

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

В стоячих позах:

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

В беседах с заинтересованными сторонами или лидерами:

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

Фрази, яких слід уникати

**Сказати “просто використовуйте інструмент”, коли прийняття є низьким. ** Это отклоняет реальный сигнал. Замість цього скажіть: «прийняття нижче, ніж очікувалося — давайте дізнаємося, яке тертя зупиняє команди від перемикання» і розглядати низьке прийняття як корисні дані, а не помилку користувача.

**Сказати “це зроблено”, коли інструмент відправлено, але ще не прийнятий або не розданий. ** Внутрішнє інструментування не “зроблено” в часі корабля, як це може бути у випадку з одноразовим сценарієм. Замість цього скажіть: «перша версія була відправлена; ми зараз її перевіряємо і відстежуємо прийняття, перш ніж назвати її повною»

Слово “наши пользователи” неоднозначно, когда вы имеете в виду внутренних инженеров. У змішаній розмові з командами продукту, поясніть: “наші внутрішні користувачі - інженерні команди, які споживають цю платформу” - щоб уникнути плутанини з кінцевими клієнтами.

Краткий справочник

Term	How to use it
DX	”We’re tracking DX with a quarterly friction survey.”
self-service	”Environment provisioning is now fully self-service.”
golden path / paved road	”The golden path wires up logging and CI automatically.”
IDP	”The IDP standardizes deployment pipelines across teams.”
adoption	”Adoption is the metric that tells us if the tool actually helped.”
dogfooding	”We dogfood every release of our own tooling internally first.”

Ключеві моменти

• Розглядати досвід розробників (DX) і прийняття як вимірювані, першокласні результати, а не нечіткі післядумки - це оформлення допомагає обґрунтувати внутрішні інвестиції в інструменти для лідерства.
• Використовуйте « золотий шлях » або « асфальтова дорога », щоб описати офіційно підтримуваний, низькотертячий спосіб робити щось, відмінний від того, що просто технічно можливо.
• Низьке прийняття є сигналом для дослідження, а не невдачею для відкидання - оформити його таким чином в ретроспективах і оновленнях зацікавлених сторін.
• Випробування власних інструментів перед їх поширенням є як практикою, так і сигналом надійності — згадайте про це, коли описуєте процес вашої команди.
• Будь точним щодо «наших користувачів» у змішаних розмовах — пояснюй, коли ти маєш на увазі внутрішні інженерні команди проти зовнішніх клієнтів.

Науковий напрямок: «Спостереження та аналіз»

Як внутрішній розробник інструментів, ви не просто створюєте код; ви сприяєте спілкуванню і керуєте співпрацею в межах своєї команди. Велика частина цього полягає в розумінні нюансів англійської мови, використовуваної у зворотному зв’язку - чи це короткий коментар до запитів на витягування, чи детальна дискусія в Slack. Часто, не-рідні носії знаходять ці взаємодії викликом, тому що вони сильно покладаються на неявне значення і тонке фразування. Це не просто про буквальний переклад; це про розуміння намірів за словами.

Розглянемо таку ситуацію: рецензент може залишити коментар на зразок « Цій гілці потрібні додаткові перевірки ». На перший погляд, це виглядає просто, але його можна розглядати як критику всієї бази коду. Більш конструктивним формулюванням було б: «Чи можемо ми додати деякі тести модулів, щоб конкретно покрити нову функціональність в calculate_interest()? Це допоможе забезпечити його надійність і запобігти регресії. ” Різниця полягає в додаванні контексту – пропонуючи * як * поліпшити код, а не просто зазначаючи недолік. Аналогічно, повідомлення Slack з запитом на зміни може звучати грубо: « Виправте цю помилку ». Краще було б сказати: « Привіт @john, я бачу проблему з перевіркою даних у формі профілю користувача. Чи не могли б ви подивитись і впровадити деякі додаткові перевірки?” Ввічливий тон і пряме звернення до відповідної особи роблять співпрацю набагато гладшою.

Іншою поширеною областю неправильного тлумачення є технічні описи в описах запитів на завантаження. Розробники часто використовують такі фрази, як « переробка », « оптимізація » або « поліпшення продуктивності ». Ці терміни містять припущення щодо того, як слід робити зміни. Важливо уникати припущень і натомість зосередитися на описі проблеми, яку ви намагаєтеся вирішити, і рішень, які ви реалізували. Замість того, щоб сказати: « Перебудувати цю функцію для кращої продуктивності », скажіть щось на зразок: « Ця функція мала повільний час виконання під час пікового навантаження. Я переписав його, використовуючи більш ефективний алгоритм і зменшив його слід в пам’яті. ”

Ось приклад, який показує, як використовувати gdb (зневадник GNU) у командному рядку — звичайний інструмент для діагностики проблем з продуктивністю, які часто обговорюються у командах:

gdb ./my_application -p 12345  # Attach gdb to process ID 12345
break calculate_interest    # Set a breakpoint in the function
run                         # Start execution
next                       # Step over the next line of code
print $result               # Print the value of the variable 'result'
continue                   # Continue execution until the breakpoint is hit.

Зрозумівши ці тонкі відмінності і зосередившись на ясній, дійовій мові, ви значно поліпшитимете своє спілкування, зменшите кількість непорозумінь і, врешті-решт, станете ефективнішим розробником внутрішніх інструментів.