Англійська для розробників Groovy

Більшість розробників зустрічають Groovy через Jenkinsfiles або Gradle build scripts, а не вибирають її як мову програми, що означає, що прогалина в словнику зазвичай стосується DSL і динамічного типування, а не основ JVM, які вони вже знають з Java.

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

Closure — блок коду першого класу Groovy, який може бути переданий як значення, захоплює змінні з його обсягу, і викликається пізніше, механізм, що лежить в основі більшості синтаксису DSL Groovy, включаючи скрипти збирання Gradle. “Цей блок doLast { ... } не є особливим синтаксисом скрипту збирання — це звичайне закінчення, яке передається як аргумент завдання, саме тому він може посилатися на змінні, визначені раніше в тому ж скрипту.”

** Groovy DSL (мова, специфічна для домену) ** — синтаксис, побудований на основі гнучких правил аналізу Groovy (необов’ язкові дужки, закінчення як кінцеві аргументи, шаблони конструктора), який читається як формат налаштування, але насправді є виконуваним кодом Groovy, як це можна побачити у Jenkinsfiles і файлах Gradle. “Це не файл налаштувань у стилі YAML, хоча він виглядає як такий — це Groovy DSL, тому ви можете вставити в нього справжню умовну логіку і петлі, що є як силою, так і небезпекою Jenkinsfile.”

@CompileStatic — анотація, яка вибирає клас або метод для статичної перевірки типів і компіляції, закриваючи розрив у продуктивності і виявленні помилок між динамічним Groovy і Java, за рахунок деяких динамічних гнучкостей Groovy. “Ми додали @CompileStatic до цього класу після того, як помилка в динамічно розв’ язаній назві методу, відправлена до виробництва, не була виявлена — статична компіляція виявила б це під час збирання, а не під час виконання.”

** MetaClass ** — об’ єкт, який Groovy використовує під капотом для реалізації динамічного розповсюдження методів, що дозволяє додавати методи і властивості до класу під час виконання, що є потужним для DSL, але може зробити зневадження « де цей метод навіть визначено » справді важким. “Цей метод не визначено ніде у джерелі класу — він був додано під час виконання за допомогою metaClass у коді ініціалізації додатка, що є саме такою динамічною поведінкою, яка ускладнює відстеження цієї помилки.”

** шаблон будівничого (будівники Groovy) ** — ідіом Groovy, що використовує вкладені закриття і відсутність методів для побудови ієрархічних структур (таких як XML, JSON або дерева інтерфейсу користувача) з синтаксисом, що відображає структуру, що будується, а не серію імперативних викликів add. “Замість будівництва цього XML з серією викликів appendChild, ми використовуємо шаблон будівництва Groovy — вкладення закриття в коді візуально відображає структуру XML, яку він виробляє, що робить його набагато простішим для перегляду.”

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

• Чи є це закінченням, що захоплює зовнішні змінні, або простою посиланням на метод?»
• «Чи ми пишемо це як Groovy DSL, або простий конфігураційний файл буде яснішим і безпечнішим?»
• Чи повинен цей клас бути позначений @CompileStatic, враховуючи, що він знаходиться на гарячому шляху?
• «Чи цей метод походить від фактичного визначення класу, чи він був доданий динамічно через metaClass?»
• Чи зробить шаблон будівництва цей код будівництва яснішим, ніж поточна імперативна версія?

Приклади висловлювань

Пояснення шаблону Jenkinsfile: “Цей блок, переданий stage, є лише закінченням — він захоплює змінну env з обсягу конвеєра, що його закриває, тому зміна env.BRANCH_NAME раніше у файлі впливає на те, що виконується всередині нього.”

Обґрунтування зміни статичного збирання: “Ми додаємо @CompileStatic до класу payment-calculation конкретно, а не до всієї кодової бази — це єдине місце, де тиха динамічна відправка помилки друку була б справді дорогою, тому варто втратити деякі гнучкості Groovy там.”

Зневадження загадки динамічного відсилання:

• “Цей виклик методу працює, навіть якщо методу немає у файлі класу — якийсь додаток вставляє його через metaClass під час запуску. Нам потрібно grep код ініціалізації плагіна, а не тільки сам клас, щоб знайти, де він насправді визначений.”*

Професійні поради

• Розпізнавати closure, коли ви бачите кінцевий блок { } в коді Groovy, навіть у файлах, що виглядають як конфігурація, таких як Jenkinsfiles — розуміння того, що це звичайне закриття, а не спеціальний синтаксис, розмита більшість коду Groovy DSL.
• Будьте обережними при написанні ** Groovy DSL ** проти простого формату даних — DSL є потужними, оскільки вони є виконуваним кодом, але ця ж потужність означає, що файл налаштувань може тепер мати вади, побічні ефекти і недетермінізм, який файл YAML ніколи не міг мати.
• Застосувати **@ CompileStatic ** до класів, які чутливі до швидкодії або критичні для коректності, а не до всієї бази коду — це захоплює справжній клас помилок динамічного відправника під час компіляції, але застосування його скрізь бореться з ідіомами, на які часто покладається код Groovy.
• Розглядати непояснені методи як сигнал для перевірки ** metaClass ** перед тим, як прийняти, що ви неправильно прочитали файл класу — динамічне введення методів є поширеним джерелом « це навіть не повинно компілюватися » плутанини у базах коду Groovy.
• Використовуйте шаблон builder, коли ви створюєте ієрархічну структуру — це більш ідіоматичне для Groovy і зазвичай створює код, форма якого візуально відображає структуру виводу.

Практичні вправи

1. Поясніть, чому блок стадії Jenkinsfile насправді є лише завершенням Groovy.
2. Опишемо компроміс, який @CompileStatic робить між безпекою і динамічною гнучкістю Groovy.
3. Напишіть речення, у якому пояснюється, що таке метаклас і чому він може ускладнити зневадження.

На практиці: Навігація Nuance - Відгуки і співпраця

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

Аналогічно, розмови Slack часто вимагають точних формулювань, щоб передати невідкладність або запитати конкретні дії. Сказати « Виправте це » набагато менш ефективно, ніж запропонувати: « Чи можете ви розслідувати періодичні помилки у тестовому наборі і звернутися до кореневої причини? » Останнє чітко сформулює природу проблеми і направляє одержувача до цілей розв’ язання. Крім того, при написанні Pull Requests (PRs), чіткість щодо * чому * зміни робляться є надзвичайно важливою. Опис PR, що говорить просто «Виявлена помилка», не має контексту і не дозволяє рецензентам легко оцінити вплив виправлення. Замість цього, націляйтесь на щось на зразок: “Ця PR адресує проблему #123 - перервані помилки підключення бази даних під час пікового навантаження. Ця зміна реалізує механізм повторних спроб з експоненційним відступом для поліпшення стійкості. » Використання активного голосу і конкретних деталей посилює ваше спілкування і демонструє професіоналізм.

Крім індивідуальних взаємодій, звернення уваги на встановлену термінологію є критичним. У контексті конвеєрів Jenkins і скриптів збирання Gradle, словник, що оточує * динамічну * проти * статичної * компіляції, стає особливо важливим. Зрозуміло, що скрипт Groovy, виконаний у конвеєрі, може бути динамічно зібраний під час виконання (залежно від середовища) у порівнянні зі статичним зібранням під час процесу збирання Gradle, що дозволяє точніше повідомляти про потенційні проблеми з продуктивністю або сумісністю. Також важливо розрізняти між «конфігурацією» і «реалізацією». Визначення « Ці налаштування потребують оптимізації » є неоднозначним; вказати « Поточні налаштування використовують синхронне викликання бази даних, яке можна оптимізувати за допомогою асинхронної черги » дає вам можливість дізнатися більше про те, що слід зробити.

Ось приклад того, як ви можете використовувати gradlew для діагностики проблеми зі збиранням:

gradlew --stacktrace failedTasks

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