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

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

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

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

** Чиста функція ** — функція, вивід якої залежить лише від її вхідних даних і не має спостережуваних побічних ефектів, що робить її тривіально перевіряною і безпечною для переупорядкування або запам’ ятовування. “Витягніть виклик журналювання з побічним ефектом з цієї функції — як тільки вона буде чистою, ми зможемо перевірити її з простими вхідними/вихідними твердженнями замість того, щоб щось вигадувати.”

** REPL- керований розвиток ** — робочий процес оцінки і тестування коду інкрементально в живому сеансі REPL, а не написання коду сліпо і запуску всієї програми для його перевірки.

• “Не вгадуйте, що поверне ця трансформація — завантажте простір імен у REPL і спочатку оцініть його за реальними прикладними даними.” *

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

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

** Spec ** — бібліотека і шаблон ( clojure.spec ) для опису форми даних і функціональних контрактів, які можна використовувати як для перевірки, так і для генеративного тестування.

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

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

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

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

Перегляд запиту на звантаження:

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

Пояснення рішення про проектування: “Ми використовували перетворювач тут замість того, щоб робити три окремих виклики map / filter, оскільки це працює над послідовністю з декількома мільйонами рядків, а додаткові розподіли з’являлися в профілі.”

Опис події: “Вада була відстежена до функції, яку ми вважали чистою — вона тихо читала і скидала спільний атом, тому двічі викликаючи її, ми отримали різні результати.”

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

• Скажіть “чиста функція” точно при перегляді перевіряемости - це сильніше, більш конкретне твердження, ніж просто “це виглядає просто”
• Використовуйте « REPL- driven » для опису вашого потоку роботи, коли пояснюєте, як ви перевірили крайовий випадок — це ідіоматичний стиль розробки Clojure, а не неформальний скорочений варіант.
• Прапор **“прихований побічне дія” ** явно, коли функція, що виглядає чистим торкається атом, референс, або вхід/вихід — це один з найпоширеніших коментарів перегляду Clojure.
• Назва “transducer” спеціально при запропонуванні виправлення продуктивності для операцій з ланцюговою послідовністю — це сигналізує про точний механізм, а не просто “зробити його швидшим”

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

1. Поясніть у двох реченнях, чому незмінні структури даних роблять функції простішими для обґрунтування.
2. Написати коментар перегляду коду у одному реченні, у якому буде позначено функцію, яка виглядає чистою, але має прихований побічний ефект.
3. Опишемо, вашими словами, яку проблему вирішує датчик у порівнянні з послідовним map і filter.

В практиці: оновлення комунікації для професійного співробітництва

Як розробник Clojure, ви вже боретеся з такими поняттями, як незмінність, перетворювачі і простори імен — складні ідеї, які вимагають точного спілкування, щоб ефективно обговорювати їх в команді. Але навіть найкращі технічно розробники можуть зіткнутися з труднощами при перекладі цих ідей на ясну, професійну англійську. Це не просто уникнення жаргону; це про сприяння співпраці, отримання конструктивного зворотнього зв’язку і значний внесок у обговорення проекту. Поширеною пасткою є надмірне покладання на технічні терміни, які розумієте тільки ви і ваші найближчі колеги. Уявіть перегляд коду, де хтось запитує: «Чи можете ви пояснити «трансформацію» тут?», Не повністю сформулювавши * чому * ця трансформація була необхідна або її потенційний вплив. Рецензент - і, можливо, навіть оригінальний автор - може пропустити важливий контекст.

Аналогічно, створення ефективних PR-описів є життєво важливим. Замість простого повідомлення « Оновлена функція », кращим підходом буде повідомлення « Впроваджено перетворювач для ефективного фільтрування вводу користувача на основі заздалегідь визначеної схеми, скоротивши час обробки приблизно на 15%, як це було виміряно під час тестування ». Такий рівень деталізації показує розуміння, виправдовує зміну і дозволяє рецензентам швидко оцінити цінність внеску. Іншою частою проблемою є конструктивне формулювання розбіжностей. Замість того, щоб сказати щось на зразок «Це неправильно», спробуйте «Я розумію вашу думку про використання іншого підходу. Однак, я переживаю, що цей метод може ввести складність в довгостроковій перспективі. Можливо, ми могли б розглянути [альтернативне рішення]? “Це демонструє повагу до різних думок, але все ж підтримує вашу улюблену стратегію. Сфокусуйтесь на тому, щоб сформулювати, чому ви вважаєте, що щось краще, підкріплюючи це аргументами і доказами.

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

(def my-transducer (cons (fn [user-input] (:name user-input))
                       (filter #(contains? % :name))))

(defn process-data [data]
  (map my-transducer data))

Цей простий приклад датчика демонструє силу короткого, добре поясненого підходу. Опис його функції — фільтрування списку карт на основі присутності :name ключа — набагато ясніше, ніж просто сказати «Я використовував датчик»