English for C# Developers

Перегляди коду C# повні точної, часто компілятором вимушеної термінології, і отримання правильної англійської мови має значення, тому що ці терміни описують гарантії часу компіляції, а не тільки стилі. Цей набір словників містить п’ ять поняттів, які використовуються майже у кожній дискусії команди. NET.

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

** Тип посилання, який можна скасувати ** — можливість C# 8+, за допомогою якої типи посилань анонсуються як або нульові ( string? ) або не нульові ( string ), що дозволяє компілятору попереджати вас про те, що значення, яке може бути нульовим, використовується без перевірки. “Компілятор позначив це як попередження, тому що user є нульовим типом посилання і ми отримуємо доступ до .Name без перевірки на нуль спочатку.”

** LINQ query ** — синтаксис мови Integrated Query, який надає змогу фільтрувати, проектувати і агрегувати збірки за допомогою виразів SQL- типу або виразів метод- ланцюга безпосередньо у C#. “Замість вкладеного циклу foreach, ми переписали його як один запит LINQ, використовуючи Where і Select.”

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

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

** Збір сміття ** — процес автоматичного керування пам’ яттю середовища виконання.NET, який відновлює пам’ ять, використовувану об’ єктами, які більше не посилаються, організованими у покоління для ефективності.

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

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

• Чи є цей параметр нульовим типом посилання, або ми просто забуємо анотацію?»
• Чи можемо ми спростити цей цикл до одного LINQ запиту?
• Чи ви очікували на цей дзвінок, чи це був випадковий пожежа-забувай?»
• Чи є ця служба зареєстрована з ін’єкцією залежностей, або ми оновлюємо її безпосередньо?»
• Чи може це сповільнення бути паузою збирання сміття, а не справжнім вузьким місцем в нашому коді?»

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

Перегляд запиту на звантаження: “Ви відкидаєте посилання на це без перевірки на нуль — оскільки це нульовий тип посилання, попередження компілятора тут не те, що нам слід придушувати.”

Пояснення рішення щодо архітектури:

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

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

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

• Викликати попередження ** нульового типу посилання ** за назвою у перегляді коду замість простого сказання « це може призвести до аварії » — це вказує автору прямо на діагностику компілятора.
• Пропонуйте перетворення багатослівних циклів у запит ** LINQ **, якщо це справді покращує читабельність, але не намагайтеся використовувати його там, де цикл є більш зрозумілим — згадайте обидва варіанти у коментарях до перегляду.
• Під час обговорення продуктивності під навантаженням, запитайте чи ** async/ await ** використовується правильно від початку до кінця, оскільки один блокуючий виклик у ланцюзі може перевершити всі переваги.
• Аргументи перевіряемости блоків навколо ** залежності введення ** — це стандартне виправдання.NET команди очікують, коли пояснюють, чому клас приймає інтерфейси замість конкретних типів.

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

1. Пояснити молодшому розробнику, чому попередження про нульовий тип посилання не повинно бути просто придушено !.
2. Опишемо в одному або двох реченнях, яку проблему async/await вирішує, а синхронний код не вирішує.
3. Напишіть речення, яке ви б використали у розгляді проекту, щоб захистити використання введення залежностей від прямого створення екземплярів.

Навигація по нумерації: понад технічний жаргон

Як розробник C#, ви вільно володієте кодом - але ефективне спілкування про цей код з колегами так само важливо. Часто найбільш впливові обговорення відбуваються не в IDE, а через електронну пошту, повідомлення Slack і під час перегляду коду. Освоєння професійної англійської мови дозволяє вам чітко сформулювати складні технічні поняття, висловити свої ідеї і безперешкодно співпрацювати. Багато не-рідних носіїв знаходять термінологію навколо сучасних.NET можливостей особливо складним; це набагато більше, ніж просто перекладаючи “нуль” або “асинхронний”. Незначні нюанси формулювання - * як * ви описуєте проблему, пропонуєте рішення або даєте зворотній зв’язок - можуть значно вплинути на розуміння і прийняття. Не бійтеся просити про пояснення, якщо щось не відразу зрозуміло, ввічливо оформлюючи свій запит такими фразами, як «Чи можете ви розібратися в цьому?» або «Я хочу переконатися, що я повністю розумію…». Крім того, активно слухати інших так само важливо, як говорити чітко; звертаючи увагу на *намір * за їхніми словами, можна виявити цінні знання. Розвиток словникового запасу, зосередженого на конструктивному зворотньому зв’язку - рухаючись далі простого сказати “це неправильно” - є життєво важливим для продуктивного середовища розробки. Сфокусування на реальних поліпшення, а не загальна критика завжди дасть кращі результати. Нарешті, пам’ятайте, що технічна мова швидко розвивається; залишатися в курсі промислових тенденцій і термінології через професійні спільноти і документацію є постійним процесом.

Однією з поширених пасток для носіїв мови, яка не є рідною, є надмірно буквальний переклад концепцій. Наприклад, просто сказати «цей код не працює» не допомагає в перегляді коду. Натомість, такі фрази як «Ця лінія викидає NullReferenceException при виклику з нульовим вхідним» або «Логічний потік тут потребує пояснення щодо нульових типів» є * набагато * більш точним і дієвим. Аналогічно, використання неясних термінів, таких як «оптимізувати це» вимагає негайного розроблення — «Чи можете ви розробити, які аспекти продуктивності коду ви націлюєтесь?» є кращим підходом. Зрозуміти контекст, в якому використовуються ці фрази, є критичним. Повідомлення Slack вашій команді про те, що ви зіткнулися з проблемою, може дуже відрізнятися від офіційного звіту про помилку, і ця різниця вимагає зміни тону і словникового запасу. Навчання формулювати технічні питання як питання, а не заявами («Я намагаюся зрозуміти…») демонструє скромність і заохочує співпрацю. Освоєння мистецтва короткого, однозначного спілкування зробить вас більш ефективним і шанованим членом будь- якої команди розробників.

using System;

public class NullableExample
{
    public static void Main(string[] args)
    {
        object? nullableValue = null; // Demonstrates nullable type usage
        try {
            Console.WriteLine($"Value: {nullableValue?.ToString()}");
        } catch (NullReferenceException ex) {
            Console.WriteLine($"Caught exception: {ex.Message}");
        }

    }
}