День 2795. #ЗаметкиНаПолях #AI
Рабочий процесс с Copilot для .NET. Начало
Проблема с позиционированием Copilot как «ИИ-напарника», которое использует GitHub в маркетинговых целях, в том, что это определение верно, но неполно. Программист, впервые видящий вашу кодовую базу, — это всё ещё человек. Он может спросить: «Погоди, а вы здесь используете Service Bus именно так?» — перед тем, как уверенно сгенерировать три файла с неверными привязками. Copilot же будет уверенно генерировать код, создавая как безупречный идиоматичный код для .NET, так и галлюцинированный метод, которого не существует ни в одной версии SDK. Лучше воспринимать Copilot как джуна, который идеально помнит публичный код с GitHub, но совершенно не знает вашего конкретного стека, стандартов кодирования, или что предложенный им метод был объявлен устаревшим ещё в 2022 году. Обеспечьте его контекстом. Задайте ограничения. Проверяйте всё, что взаимодействует с внешними системами. Именно такой подход избавит вас от лишних затрат времени на отладку.

Режимы работы Copilot
1. Автодополнение. Вы печатаете, а он предлагает подсказку, которую можно принять нажатием клавиши Tab. Это отличное решение для шаблонного кода: конфигурации сущностей EF Core, запросов LINQ, добавления атрибутов к контроллерам ASP.NET Core и т.п. При работе с повторяющимися паттернами это действительно ускоряет процесс.
Недостаток: задачи, требующие специфических знаний SDK; асинхронный код, где важна правильная передача CancellationToken; и всё, что касается безопасности. В таких случаях действовать нужно более осознанно.

2. Встроенный чат (Ctrl+I в VS Code, Alt+/ в Visual Studio) — возможность отправить точечный промпт непосредственно в редакторе. Это целевой инструмент с ограниченной областью действия. Чаще всего используется для рефакторинга конкретного метода, преобразования синхронного кода в асинхронный, генерации XML-документации или чтобы выяснить, что именно делает код и зачем он это делает.

3. Окно чата (Ctrl+Alt+I в VS Code, Ctrl+\,C в VS) — ваш партнёр по размышлениям. Оно подходит как для написания кода, так и для планирования. Прежде чем приступать к реализации, откройте чат и посоветуйтесь об архитектуре: какие возможны сбои, где должна находиться логика повторных попыток, как это взаимодействует с уже используемым нами паттерном Outbox? Результатом становится не код, а ясность понимания. Это позволяет писать код, имея гораздо более чёткий план действий.

(Также существует функция Быстрого Чата — Ctrl+Shift+Alt+L в VS Code, — предназначенная для разовых вопросов без открытия полноценной панели. О ней стоит знать, даже если вы пользуетесь ей лишь изредка.)

Многие разработчики вообще не пользуются окном чата, считая это неэффективным. Но 10 минут, потраченных там, сэкономят 2 часа на последующем рефакторинге.

Режимы Ask и Agent: какой из них может вам навредить?
Режим Ask — это Copilot в роли консультанта. Он даёт советы, объясняет и предлагает решения, но не меняет файлы напрямую, пока вы сами не скопируете предложенное. Затраты времени на проверку здесь минимальны. Смело используйте этот режим для исследования, разбора незнакомого кода и планирования.

Режим Agent вносит изменения в один или несколько файлов решения. Он способен одновременно работать со всем проектом, выполнять команды в терминале и проактивно исправлять возникающие ошибки. Это действительно впечатляет. Однако именно в этом режиме, если принять изменения без внимательного их изучения, можно внести скрытые баги сразу в несколько файлов — причём каждый из них по отдельности может выглядеть корректно. Никогда не принимайте результат работы режима Agent, не изучив тщательно каждый изменённый файл.

Выбор модели важнее, чем кажется
Copilot позволяет переключать базовую модель, и относиться ко всем моделям одинаково — всё равно что использовать кувалду для выполнения любой задачи.

Для повседневных задач — таких как создание каркаса контроллера, написание валидатора или генерация заглушек для тестов — лучше всего подходят быстрые и «лёгкие» модели. Они быстро реагируют и выдают точный результат в чётко определённых задачах. Прерывать рабочий процесс в ожидании ответа от модели с продвинутыми способностями рассуждения ради обычного LINQ-запроса — просто неэффективно.

Для принятия архитектурных решений, анализа кода, затрагивающего множество файлов, или любых задач, связанных с логикой безопасности, используйте самую мощную модель (с лучшими способностями к рассуждению) и дайте ей необходимое время. Затраты времени на выбор правильной модели — 3 секунды. Затраты на исправление неверного результата — часы.

Продолжение следует…

Источник: https://levelup.gitconnected.com/a-production-ready-copilot-workflow-for-net-0ad2e7183018

День 2796. #ЗаметкиНаПолях #AI
Рабочий процесс с Copilot для .NET. Продолжение
Начало

Три «S» в составлении промптов
Лучшие промпты обладают тремя характеристиками:
- Simple (простые) - одна задача за раз;
- Specific (конкретные) - явно указаны фреймворк, версия, паттерн и ограничения;
- Short (краткие) - достаточно лаконичные, чтобы полезная информация не терялась в «шуме».

Антипаттерн — «мега-промпты», пытающиеся решить всё за один раз. Например: «Создай сервис управления заказами с интеграцией Service Bus, EF Core, механизмом повторных попыток Polly, структурированным логированием и полным набором тестов».
Такой промпт выдаст результат, который технически охватывает все эти области, но в большинстве из них будет содержать ошибки.

Разбейте задачу на части: «Создай интерфейс IOrderService с методами для создания, получения и отмены заказов. Используй асинхронность повсеместно. Возвращай Result<T> — не выбрасывай исключения при передаче данных между компонентами». Это даст результат, который действительно можно использовать.

Ошибка, которая сводит всё на нет, — расплывчатый контекст. Если Copilot не знает, что вы используете .NET 10, он может предложить паттерны для .NET 6. Если он не в курсе, что у вас Polly v8, то предложит синтаксис версии 7. Конкретика в промпте ничего не стоит, а вот исправление неверных версий SDK — да.

Контекстные переменные
Здесь кроется реальный разрыв в продуктивности между разработчиками, которые уделили время правильному изучению Copilot, и всеми остальными.

- #file: позволяет указать Copilot конкретные файлы, вместо того чтобы надеяться, что он сам догадается о контексте на основе открытого в редакторе файла. Добавление в промпт ссылки на copilot-instructions.md (о нём позже) сильно меняет дело. Copilot генерирует код, соответствующий вашим текущим паттернам, а не придумывает новые.

- #terminal используется редко, хотя очень полезна. Если сборка завершается ошибкой, передайте вывод терминала прямо в запрос, вместо того чтобы пересказывать суть ошибки своими словами. Copilot видит реальный вывод компилятора и предлагает точечные исправления, а не общие рекомендации.

- @workspace открывает Copilot доступ ко всей структуре проекта, а не только к открытому файлу: «Учитывая контекст @workspace, где ещё в этой кодовой базе используется похожий паттерн, который стоит проверить на согласованность?»

- /explain — для объяснения любого легаси кода, к работе с которым собираетесь приступить;
- /tests — для создания каркаса (заглушек) тестов NUnit для готового метода;
- /fix — когда тест падает и нужна отправная точка для анализа проблемы.

copilot-instructions.md — то, что принесёт наибольшую пользу
Если вы решите внедрить что-то одно, пусть это будет данный файл. Добавьте .github/copilot-instructions.md в каждый репозиторий.

У каждого разработчика в команде свои привычки и подходы. Если оставить выбор промптов на их усмотрение, один попросит сгенерировать асинхронный код с токенами отмены, а другой об этом даже не подумает. Один знает, что вы используете FluentValidation, а другой попросит Copilot написать валидацию вручную. Один запросит обработку ошибок через Result<T>, а другой позволит Copilot генерировать исключения, пересекающие границы сервисов.

Файл copilot-instructions.md приводит подходы всех разработчиков к единому стандарту на самом раннем этапе. Он определяет ваш стек технологий, стандарты и ограничения, благодаря чему Copilot по умолчанию генерирует код, идиоматичный именно для вашей кодовой базы, а не для абстрактного проекта на .NET из обучающей выборки GitHub. Минимальная версия конфигурации для команды, работающей с Azure и .NET:

## Stack
- ASP.NET Core 8, C# 12, .NET 8
- Azure PaaS: App Service, Azure Functions, Service Bus, Blob Storage
- EF Core 8 with Azure SQL
- xUnit for testing, Moq for mocking
- Polly v8 for resilience, Serilog for structured logging
## Async Rules
- All I/O is async. No .Result, .Wait(), or Task.Run wrappers.
- CancellationToken is the last parameter on every public async method.
- Propagate tokens down the chain. Never discard them.
## Error Handling
- Never throw exceptions across service boundaries.
- Return Result<T> for operation outcomes.
- Use Polly retry + circuit breaker for all transient failures.
## Security
- No hardcoded secrets. Azure Key Vault only.
- Managed Identity for all Azure service auth. No connection string keys.
- Validate all external inputs at the API boundary. OWASP Top 10.

Будьте кратки. Copilot лучше справляется с лаконичными и конкретными инструкциями, чем с огромными массивами документации. Вот пример полноценного рабочего файла.

Окончание следует…

Источник: https://levelup.gitconnected.com/a-production-ready-copilot-workflow-for-net-0ad2e7183018

День 2797. #ЗаметкиНаПолях #AI
Рабочий процесс с Copilot для .NET. Окончание
Начало
Продолжение

Подводные камни, которые только отнимают время
1. Использование комментариев для вызова подсказок
Привычка писать комментарии, чтобы спровоцировать генерацию кода, осталась у многих разработчиков ещё с ранних времен Copilot. Перестаньте так делать. Используйте встроенный чат. Код, сгенерированный по комментарию, часто оставляет в кодовой базе «мёртвые» комментарии-заготовки, если предложенный вариант оказывается неудачным.

2. Доверие к уверенным «галлюцинациям»
Хуже всего при работе с Copilot принять код, который выглядит правильным и компилируется, но содержит скрытую ошибку. Выдуманные пакеты NuGet легко заметить, а вот неверные сигнатуры методов, которые компилируются благодаря совпадению типов параметров, — гораздо сложнее. Любой код, затрагивающий Azure SDK, логику безопасности или внешние интеграции, перед выпуском должен вручную сверяться с официальной документацией.

3. Секреты в чате
Строкам подключения, API-ключам и данным клиентов не место в промпте. Если Copilot нужно понять структуру конфигурации, вставьте саму структуру, заменив реальные данные заглушками.

Если вы решили начать в понедельник
Не пытайтесь изменить всё и сразу. Самое эффективное действие с максимальной отдачей — это добавление файла copilot-instructions.md в ваш самый активный репозиторий. Это займет всего час, но сразу повысит продуктивность всех разработчиков, работающих с этим репозиторием, и инициирует полезное обсуждение ваших реальных стандартов разработки.

Затем проведите сеанс парного программирования с коллегой, который до этого использовал только автодополнение кода, и покажите ему возможности чата и встроенного чата. Понаблюдайте, как меняется его стиль составления промптов, когда для конкретной задачи используется подходящий инструмент взаимодействия.

После того как эти приёмы войдут в привычку, попробуйте режим Agent на задачах с низким уровнем риска. Например, при рефакторинге тестового файла или обновлении документации. Наработайте навык проверки результатов, прежде чем применять этот режим к уровню бизнес-логики вашего приложения.

Наибольшую пользу от Copilot получают не те команды, которые используют его максимально интенсивно, а те, кто разобрался в принципах его работы и обеспечил условия, необходимые для его эффективного функционирования.

Репозиторий
Все материалы из этой статьи — шаблон copilot-instructions.md, каталог с более чем 30 шаблонами промптов для .NET и Azure, эталонный API на ASP.NET Core 8 с корректной настройкой Managed Identity и Service Bus, а также шаблоны Bicep (IaC) — доступны в репозитории на GitHub.

Начните с файла common-prompts.md - там собраны промпты, которые на практике доказали свою эффективность при создании рабочего кода для .NET и Azure; они систематизированы по типам задач.

Если вы обнаружите неточности, устаревшую информацию или найдёте более удачный шаблон для вашего стека технологий — создавайте пул-реквест. Именно для этого материалы и были выложены в открытый доступ.

Вопрос напоследок: расскажите о случае, когда Copilot (или любой другой инструмент) выдал «на вид правильный, но ошибочный» код, который обошёлся вам дороже всего. Галлюцинации при работе с SDK, небезопасные «быстрые решения» или некорректно развернувшаяся инфраструктура как код (IaC)?

Источник: https://levelup.gitconnected.com/a-production-ready-copilot-workflow-for-net-0ad2e7183018

День 2798. #Оффтоп
Утиная Типизация в C# с Помощью Перехватчиков. Часть 2
Некоторое время назад я выложил пост от Steven Giesel о реализации утиной типизации в C# с помощью перехватчиков (interceptors). Тогда это был лишь прототип с множеством недоработок. Теперь же это полноценная библиотека: IfItQuacks.

TL;DR
Объявите интерфейс, пометьте метод атрибутом [DuckTyped] и передавайте в него любой подходящий объект — без базового класса, без явной реализации интерфейса и без каких-либо атрибутов на самих типах:

using IfItQuacks;

public interface INamed
{
  string Name { get; }
}

public class Person { public string Name => "Steven"; }
public class Mallard { public string Name => "Donald"; }

public partial class Greeter
{
  [DuckTyped]
  public string Greet(
   INamed first,
   INamed second,
   string greeting = "Hello")
    => $"{greeting}, {first.Name} and {second.Name}!";
}

Console.WriteLine(new Greeter()
 .Greet(new Person(), new Mallard()));
// Hello, Steven and Donald!

Ни Person, ни Mallard не знают об INamed. Генератор кода на этапе компиляции проверяет наличие у обоих типов свойства Name и перенаправляет вызов через небольшой сгенерированный адаптер. Никакой рефлексии, никакого dynamic. Если типы несовместимы, анализатор выдаст ошибку.

Можно также явно привести объекты к интерфейсу, чтобы хранить их:

List<INamed> names = [
  Duck.As<INamed>(new Person()), 
  Duck.As<INamed>(new Mallard())
];

Подробности можно найти в документации. Далее кратко основные моменты.

Анонимные типы — это «утки»
Анонимные типы отлично «крякают» (по сути, то же самое, что предлагает TypeScript):

new Greeter().Greet(
 new { Name = "Steven" },
 new { Name = "Donald" });

По сути, можно писать свои тесты с «мгновенными моками»:

public interface IPerson
{
  string Name { get; }
  int Age { get; }
}

public partial class AgeChecker
{
  [DuckTyped]
  public bool IsAdult(IPerson person)
   => person.Age >= 18;
}

[Test]
public void Should_detect_adults()
{
  var checker = new AgeChecker();

  Assert.That(
   checker.IsAdult(new { Name = "Steven", Age = 90 }), Is.True);
  Assert.That(
   checker.IsAdult(new { Name = "Baby Duck", Age = 1 }), Is.False);
}

Либо:

IPerson stub = 
 Duck.As<IPerson>(new { Name = "Donald", Age = 90 });

List<IPerson> family =
[
  Duck.As<IPerson>(new { Name = "Huey", Age = 10 }),
  Duck.As<IPerson>(new { Name = "Dewey", Age = 10 }),
  Duck.As<IPerson>(new { Name = "Louie", Age = 10 }),
];

Идентичность сохраняется
Адаптеры перенаправляют вызовы методов Equals, GetHashCode и ToString к обёрнутому экземпляру, благодаря чему они корректно работают в словарях и множествах. Кроме того, можно получить доступ к исходному объекту:

var person = new Person();
Duck.As<INamed>(person)
 .Equals(Duck.As<INamed>(person)); // true
Duck
 .Unwrap(Duck.As<INamed>(person)) is Person; // true

А также поддерживаются:
- Любой интерфейс, включая интерфейсы фреймворков: Duck.As<IDisposable>(x), параметры IEnumerable<T> и т.п.;
- Параметры интерфейса, не требующие утиной типизации (например, ILogger), продолжают принимать реализации, значения null и значения по умолчанию;
- Обобщённые интерфейсы (IContainer<T>) и обобщённые методы [DuckTyped] с выведением аргументов типа;
- События, индексаторы и реализация интерфейса по умолчанию;
- Делегаты, лямбда-выражения и группы методов для интерфейсов с одним методом;
- Статические абстрактные члены и операторы с помощью ограничений утиной типизации (where T : IAddable<T>) - включая обобщённую математику;
- Методы экземпляра и статические методы, ref/out, params, значения по умолчанию и именованные аргументы;
- Нулевая настройка: установите пакет, никаких изменений в файлах проекта не требуется.

Источник: https://steven-giesel.com/blogPost/41599817-4457-441e-b874-1a5c67f4e7cc/if-it-quacks-part-2

День 2799.
Конференция DotNext 2026. Часть 1
25 и 26 сентября в Москве прошла очередная конференция DotNext. Вернулся и делюсь впечатлениями. Я уже писал, какие доклады хочу посетить, однако, по ходу несколько раз передумал. На этот раз решил посетить несколько воркшопов, т.к. они не записываются на видео, а доклады можно посмотреть в записи позже. Воркшоп отличается от доклада тем, что на нём разбирается конкретный практический пример, а аудитория активно участвует, задавая вопросы или предлагая решения. Раньше они меня пугали своей продолжительностью. Доклады длятся по часу, а воркшоп – это обычно от полутора часов и дольше. ИЧСХ, в начале каждого воркшопа любой докладчик считает своим долгом упомянуть, что времени у нас очень мало 😉. Хочу признать, что я много потерял, не посещая воркшопы раньше. Это отличный опыт практики и командной работы.

Первым был воркшоп от Андрея Цветцих (они с братом Денисом завсегдатаи различных конференций) «Паттерны асинхронного взаимодействия в распределенных системах». Мы разбирали пример реализации сервиса уведомлений (например, по e-mail) о событиях. Как настроить передачу информации в сервис рассылки? Какие данные передавать? Как реализовать гарантии доставки и избежать отправки дублирующих сообщений? Возможно ли реализовать доставку «exactly-once»? Интересно, что здесь нет единственно верного решения. Каждое решение – компромисс со своими плюсами и минусами.

После воркшопа я немного поговорил с Андреем.
- Вы выступаете почти на каждой конференции DotNext и ещё на многих других. Что мотивирует постоянно готовить доклады или воркшопы?
- Мне кажется мотивация комплексная. Когда ты что-то хорошо знаешь, хочется поделиться, двигать индустрию. Я не только разработчик и спикер, я ещё и пользователь систем других. Я хочу, чтобы мне не приходило по сто уведомлялок. Хочу, чтобы заказы, которые делаю на разных сайтах, доходили. И так далее. Это желание поделиться тем, что ты хорошо знаешь. Попутно есть мотивация в том, что приятно просто выступать на сцене, но это скорее такая, побочная. Кроме того, хорошо, когда есть какие-то материалы, на которые можно сослаться. Если несколько раз одно и то же рассказываешь, надоедает. Хочется сказать: «Вот ссылка, посмотрите и потом обсудим». Ну и, как правило, когда ссылку даёшь, с вопросами больше не возвращаются.

Самое смешное, что сразу после разговора с Андреем, дочь мне прямо «в тему» прислала скриншот своего почтового ящика с 30+ одинаковыми письмами (вуз уведомлял о необходимости пройти какой-то тест) 🤦‍♂️

Я поговорил и с другими участниками и докладчиками о том, зачем они посещают конференции. Виктор Дзицкий впервые выступал на DotNext с докладом «Extension Members: новый уровень проектирования .NET API или новый уровень сложности?».
- Во-первых, как прошло?
- Отлично, всё по плану.
- Когда раньше выступал где-то?
- Да, на митапах, но на такой крупной конференции в первый раз, надеюсь не в последний.
- Зачем приезжать на большие конференции и зачем выступать, в чём мотивация?
- В первую очередь для нетворкинга, чтобы общаться с другими спикерами, с другими людьми. Для меня, например, было очень интересно вживую со многими встретиться. Приходили совершенно неожиданные ребята. Например, подошёл товарищ, связанный с моей онлайн деятельностью, говорит: «Слушай, это не ты вёл курсы по ASP.NET? Я после них устроился на первую работу». Вот такие приятные события. Встретил вживую коллегу, с которым несколько лет работал онлайн и только на DotNext увиделся вживую. Встретил девочку, которая у нас проходила внутреннюю академию, и сейчас живёт и работает в Москве. Встретился, собственно, с программным комитетом и всем .NET-сообществом. Ну и вообще, для меня DotNext – это когда собираются несколько разработчиков из Сургута, Ухты, Севастополя, Москвы и т.д. за одним столом и, как старые друзья, обсуждают общие проблемы. А выступать, во-первых, конечно, какое-то самовыражение. Доказать себе, что ты можешь на таком же уровне соответствовать другим коллегам.
- Ещё будешь делать доклады?
- Конечно, буду.

А вот мнения участников (зрителей).

Константин Овечкин: «Во-первых, классные доклады интересные на современные темы. Во-вторых, много общения с разработчиками, коллегами с другого стека немного, с другими задачами. Всегда очень интересно пообщаться, узнать их мнение, какие задачи они решают. Соответственно, новые знакомства и активности на стендах тоже вполне интересны. Это уже пятая моя конференция. Каждый год я уезжаю максимально довольный, потому что это всегда свежие эмоции. И самое классное на конференциях – сложные темы, которые есть в докладах. Они подстёгивают тебя для дальнейшего развития. Поэтому с удовольствием ждешь следующую конференцию, чтобы принять следующий вызов».

Дмитрий Сорокин: «Я приезжаю на конференции иногда послушать доклады, пообщаться, но в последнее время я на них начал узнавать, что я просто ни хрена не знаю 😊 Как дохожу до каких-то архитектурных решений… То есть, получается, что мне указывают на слабые места, которые нужно подтягивать».

Александр Сашурин: «Потусоваться 😊 Ну, конечно, вот те же хардкорные доклады – это же не цель посидеть в одиночестве послушать. Ты это доклад послушал, а потом его обсудил с разными людьми, со знакомыми или с новыми знакомыми».

Ольга Бондаренко: «Не хватает живого общения в реале, потому что все мы удалёнщики. И реально заинтересованные своей работой люди – они все заняты своей работой. А DotNext, получается, собирает всех людей, энтузиастов, которые заинтересованы в своей профессии. И живое общение с такими людьми – это больше всего меня тут заряжает. Также зачекиниться на всех стендах, обязательно оставить свои контактные данные. Потому что это потенциальные работодатели. <… общий смех, т.к. её тимлид всё это время стоял рядом …>».

Антон Шевченко: «Пообщаться, со знакомыми увидеться. Может, что-то даже интересное расскажут 😊».

День 2802. #Карьера #Юмор
Секреты Программирования, Известные Только Легендам
Ещё один пост из серии программистских советов, на этот раз менее серьёзный.

Написание кода сегодня обходится дёшево: существует множество инструментов, готовых сделать это за вас. Выдающихся разработчиков отличает умение принимать верные решения. А это умение опирается на привычки, о которых обычно не пишут в учебниках. Большинство таких привычек рождается из ошибок, стоивших кому-то испорченной недели работы. Вы усваиваете их, выпуская код с багами или наблюдая, как старший коллега за минуту исправляет то, на что у вас ушёл целый день.

1. Лучший код — тот, который вы удаляете
Пишите меньше кода, чем, как вам кажется, необходимо. Каждая добавленная строка становится вашей «собственностью» навсегда. Она может сломаться, для неё нужен тест, и когда-нибудь её будет читать другой человек. Чем больше кода, тем больше мест, где могут прятаться баги. Меньше кода — меньше затрат на поддержку и объяснения. Лучший пулл-реквест – тот, в котором удаляется больше строк, чем добавляется.

2. Если что-то сломалось, сначала ищите причину в своём коде
Прежде чем винить чужой код, проверьте то, что написали сами. И чем свежее изменение, тем вероятнее, что ошибка именно в нём. Так вы быстрее найдёте баг и будете выглядеть более компетентным специалистом.

3. Тест, который никогда не падает, ничего не проверяет
Зеленые тесты создают ложное чувство безопасности. И на этом часто обжигаются. Успешный тест бесполезен, если он не падает при поломке кода.
Поэтому намеренно ломайте код, убедитесь, что тест стал красным, а затем исправляйте ошибку.

4. Пишите код для бедолаги, который будет его читать
Компьютер выполнит любой код, а вот человеку придётся в нем разбираться. И этим человеком возможно будете вы. Вы в будущем — когда уже забудете, как всё это работает. Вы будете читать этот код гораздо чаще, чем писать. Так что облегчите себе жизнь. Хитроумный код приятно писать, но мучительно читать. Всегда выбирайте ясность.

5. Нет ничего более постоянного, чем временное решение
Быстрое «грязное» решение, которое вы собираетесь внедрить, переживёт вас в этой компании. Никто не вернётся туда, чтобы привести его в порядок. Следующий разработчик просто построит поверх него новую логику. Как только другой код начинает зависеть от вашего «костыля», его рефакторинг превращается в отдельный проект. Поэтому пишите временное решение так, словно оно должно прослужить 10 лет, — потому что так оно и будет.

6. Оцените срок выполнения… и удвойте его
Если у вас мало опыта в оценке сроков, какую бы оценку вы ни собирались дать — умножайте её на два. Вы представляете себе идеальный сценарий, но работа — это всё, что происходит вокруг него. Тестирование, обработка граничных случаев, ревью, совещания, сбои на демо. Что-то всегда идёт не так. «Первые 90% кода занимают первые 90% времени разработки. Оставшиеся 10% кода занимают вторые 90% времени».

7. Просите о помощи через час, а не через день
Застряли и не продвигаетесь уже час? Спрашивайте. Попытки справиться в одиночку после этого момента тешат лишь ваше самолюбие — и больше ничего.
Старший разработчик в вашей команде наверняка уже сталкивался с такой ошибкой. Один вопрос сэкономит вам часы. Умение вовремя попросить о помощи — это навык. Это признак рассудительности, а не слабости.

8. Если работает — не трогайте
Видите ту уродливую функцию, которую все обходят стороной? Оставьте её в покое. Она выглядит неправильно, потому что выдержала проверку всеми теми граничными случаями, с которыми вы ещё не сталкивались. Каждая странная ветка кода там — это исправленная кем-то ошибка. Этот хаос — живая история проекта. Если всё же приходится вносить правки, меняйте что-то одно и небольшое, тестируйте и наблюдайте за работой прода.

9. Никогда не делайте релиз в пятницу
Никогда не выкатывайте рискованные изменения прямо перед тем, как уйти с работы. Пятница — это классическая ловушка. То же самое касается периодов перед праздниками, длинными выходными или отпуском. Развёртывание требует присмотра. Ошибки проявляются через минуты после запуска, а не через дни. Если просто выкатить обновление и уйти, разгребать проблемы придётся тому, кто остался дежурить. А часто не остаётся никого. Выпускайте обновления в начале дня и в начале недели, пока есть кому помочь.

Итого
Этому не учат на курсах. Такой опыт приобретается ценой собственных ошибок и «шрамов». Или же его можно перенять у того, кто уже заплатил за него высокую цену.

Источник: https://medium.com/javarevisited/9-hidden-coding-secrets-only-great-developers-know-c0ffd93c0b63

День 2803. #Оффтоп
Чем Заняться, Пока Работают Агенты? У VS Code Есть Ответ
Сейчас большую часть кода за вас пишут агенты. И тут возникает вопрос: чем занять освободившееся время? Можно изучить новый фреймворк, но это подозрительно напоминает работу. К счастью, у команды VS Code нашлась идея получше. Они предложили завести питомца.

Что это?
Это интерактивный персонаж, который располагается над полем ввода в чате. Он реагирует на активность в чате и на ваши действия. Пока агент работает, питомец наблюдает. Раньше вы смотрели на индикатор выполнения, делая вид, что контролируете процесс. Теперь есть с кем разделить это занятие.
Примечание: этот питомец — экспериментальная функция, поэтому он может измениться или исчезнуть. Не привязывайтесь к нему слишком сильно.

Как завести питомца
Введите /vscode-pet в поле ввода чата, чтобы показать или скрыть его. Показать и скрыть — это все обязательства. Не нужны ни график кормления, ни ветеринар (по крайней мере, пока).

Чем заняться
- Кликнуть - чтобы вызвать реакцию. С клавиатуры: нажмите Tab, чтобы перевести на него фокус, а затем Enter или пробел. Да, питомец доступен для управления с клавиатуры.
- Перетаскивать по области чата и оставлять там, где захотите (правда, он падает, если под ним ничего нет).
- Начать перетаскивать и отпустить, чтоб подбросить.
- С помощью клавиш со стрелками «влево» и «вправо» заставлять прыгать.
- С помощью клавиш со стрелками «влево» и «вправо» при удержании Shift – бросать в стену. Да, у авторов своеобразное чувство юмора.

Нажмите правой кнопкой мыши на питомца (или Shift+F10, когда он в фокусе), чтобы открыть контекстное меню, где можно:
- посмотреть достижения,
- отправить побегать,
- изменить размер,
- переключаться между цветовыми схемами.

Достижения
Это возможность оценить, насколько вы хороши как владелец питомца. Наконец-то есть показатель, который можно предъявить на следующей аттестации. За достижения питомцу дают различные головные уборы.

Один питомец — множество сеансов
В активной области чата одновременно отображается только один питомец. Его положение и размер сохраняются для всех чатов и окон, а также остаются неизменными после перезапуска VS Code. То есть питомец помнит, где вы его оставили.

Что дальше?
Значит ли это, что освободившееся время стоит тратить на игры с питомцем в редакторе? Решать вам.

Источник: https://laurentkempe.com/2026/09/26/csharp-15-collection-expression-arguments/

День 2804. #ВопросыНаСобеседовании
Марк Прайс предложил свой набор из 60 вопросов (как технических, так и на софт-скилы), которые могут задать на собеседовании.

48. Оптимизация производительности Entity Framework Core
«Как бы вы оптимизировали производительность Entity Framework Core? Приведите конкретные примеры методов и настроек, которые вы бы использовали для повышения эффективности взаимодействия с базой данных».

Хороший ответ
Оптимизация Entity Framework Core включает в себя ряд стратегий, направленных на минимизацию накладных расходов и повышение скорости доступа к данным.

Если в текущем контексте не требуется обновление данных, использование метода AsNoTracking позволяет существенно повысить производительность за счёт снижения накладных расходов на отслеживание изменений:

var products = await
  dbContext.Products.AsNoTracking().ToListAsync();

Также полезно избегать использования ленивой загрузки (lazy loading) в ситуациях, которые могут привести к проблеме «N+1 запросов». Вместо этого лучше использовать явную или жадную загрузку (eager loading) для получения всех необходимых данных одним запросом:

var order = await dbContext.Orders
  .Where(o => o.Id == orderId)
  .Include(o => o.OrderItems)
  .ThenInclude(oi => oi.Product)
  .SingleOrDefaultAsync();

Фильтрация данных, получаемых из базы, и ограничение их объёма только тем, что действительно необходимо. Применение фильтров на уровне БД (вместо извлечения всех записей и последующей фильтрации в оперативной памяти) позволяет существенно сократить задержки и снизить потребление памяти.

Важно убедиться, что в БД корректно используются индексы для ускорения выполнения запросов — особенно для столбцов, часто фигурирующих в предложениях WHERE или условиях JOIN.

Регулярное профилирование SQL-запросов, генерируемых EF Core, с помощью таких инструментов, как SQL Profiler или встроенные средства логирования, позволяет выявлять неэффективные запросы и оптимизировать их.

Внедрение этих практик позволит значительно повысить производительность приложений, использующих EF Core, сделав их более отзывчивыми и масштабируемыми.

Часто встречающийся неудачный ответ
«Важно использовать .Include() для связанных данных, чтобы избежать выполнения множества запросов к базе. Это просто и гарантирует, что все данные будут загружены за один запрос».

Почему этот подход неверен
- Чрезмерное использование жадной загрузки: Беспорядочное применение .Include() может привести к загрузке избыточного объёма данных (особенно при подтягивании нескольких связанных сущностей). Это существенно увеличивает потребление памяти и снижает производительность.

- Увеличение объёма передаваемых данных и рост задержек: Загрузка всех связанных данных одним запросом без учёта реальных потребностей приложения приводит к передаче больших объёмов информации и увеличению задержек. Это особенно критично в условиях высокой сетевой нагрузки или при большом количестве одновременных обращений к приложению.

- Отсутствие точечной оптимизации запросов: Такой подход свидетельствует о непонимании тонкостей работы EF Core и игнорировании более эффективных методов — например, явной загрузки (explicit loading) или выборочной проекции (selective projection), — которые могут обеспечить более высокую производительность.

Эта распространённая ошибка часто возникает из-за непонимания стратегий загрузки данных в EF Core и недостаточного опыта оптимизации производительности при работе со сложными ORM-системами.

Источник: https://github.com/markjprice/tools-skills-net8/blob/main/docs/interview-qa/readme.md

День 2805. #ЧтоНовенького #NET11
Аргументы в Выражениях Коллекций в C#15
В C#15 реализовано точечное улучшение выражений создания коллекций: возможность передавать аргументы с помощью элемента `with(…)`, указываемого в начале выражения.

Если вы уже используете выражения создания коллекций из C#12, это нововведение устраняет распространённое неудобство: теперь можно передавать аргументы (характерные для конструкторов или фабричных методов) непосредственно внутри […].

Сравнение C# версий 12, 13 и 15
C#12 - Добавлены выражения создания коллекций ([…]) и spread-оператор (..):

int[] values = [1, 2, 3];
int[] all = [0, ..values, 4];

C#13 - Расширена поддержка params для разных типов коллекций (не только массивов) в параметрах методов:

csharp 
public void LogValues(params Span<int> numbers) 
{
 // …
}
LogValues(1, 2, 3); 

C#15 - Добавлен элемент with(…) в начало выражений создания коллекций

List<int> numbers = 
 [with(capacity: 100), 1, 2, 3, ..more];

with(…) предоставляет аргументы для создания коллекции, где это поддерживается (параметры конструктора, построитель Create(…), отдельные сигнатуры интерфейсов).
При этом with(…) должен быть первым элементом.

Практические примеры
1) Предварительное определение размера коллекций для обеспечения читаемости и ясности намерений

List<int> ids = [with(capacity: 256), ..sourceIds];

Это позволяет выполнить инициализацию в рамках одного выражения и делает ваш замысел очевидным.

2) Сценарии использования построителей коллекций
Для построителей коллекций C#15 поддерживает дополнительные параметры метода Create(…):

static MyCollection<T>
 Create(SomeOption option, ReadOnlySpan<T> items)
{
  // …
}

Использование:

Tags tags = [with(StringComparer.OrdinalIgnoreCase), "CSharp", "CSHARP", "csharp", "dotnet"];
Tags newTags = [with(), "CSharp", "CSHARP", "csharp", "dotnet"];
Tags oldTags = ["CSharp", "CSHARP", "csharp", "dotnet"];

[CollectionBuilder(typeof(Tags), nameof(Create))]
internal sealed class Tags(
  string[] values,
  StringComparer comparer)
 : HashSet<string>(values, comparer)
{
  public static Tags Create(
   StringComparer comparer,
   ReadOnlySpan<string> items)
    => new([.. items], comparer);

  public static Tags Create(ReadOnlySpan<string> items) 
   => new([.. items], StringComparer.OrdinalIgnoreCase);
}

Ограничения и нюансы
1. Если целевым типом является массив или span, использование with(…) невозможно.
2. Аргументы внутри with(…) не могут иметь тип dynamic.
3. Согласно замыслу, аргументы with(…) игнорируются при принятии решений о преобразовании или выводе типов (по аналогии с new(…)).
4. Действуют обычные правила выбора перегрузки конструктора или построителя. Если подходят несколько вариантов, возможна неоднозначность.

Почему важны аргументы выражений коллекций в C#15
C#15 улучшает инициализацию коллекций в одно выражение, обеспечивая:
- Более ясное выражение намерений (указание вместимости, опций, компараторов и т.д., где это поддерживается);
- Сокращение числа отдельных инструкций инициализации;
- Более чистый API для пользовательских построителей коллекций.

Источник: https://laurentkempe.com/2026/09/26/csharp-15-collection-expression-arguments/

День 2806. #ЗаметкиНаПолях
Типы Коллекций в .NET, Которые Стоит Попробовать. Начало
Большинство разработчиков ежедневно используют List<T> и Dictionary<TKey, TValue>. Однако в .NET есть и специализированные коллекции, способные сделать код быстрее, безопаснее и проще в сопровождении. Рассмотрим некоторые из них, о которых стоит знать каждому .NET-разработчику.

1. HashSet<T>
Многие разработчики используют List<T> для проверки наличия элемента.

if(users.Contains(id))

Проблема в том, что List.Contains() выполняет линейный поиск. HashSet<T> использует хэширование для гораздо более быстрого поиска:

var permissions =
 new HashSet<string>
 {
   "Read",
   "Write",
   "Delete"
 };
Console.WriteLine(
  permissions.Contains("Write"));

Где использовать:
- выявление дубликатов,
- проверка наличия прав доступа,
- быстрый поиск.

См. подробнее про HashSet

2. PriorityQueue<TElement,TPriority>
Нужно первым делом обработать элемент с наивысшим приоритетом?
Вместо того чтобы постоянно сортировать список, используйте PriorityQueue:

var queue = new PriorityQueue<string, int>();
queue.Enqueue("Low", 3);
queue.Enqueue("Medium", 2);
queue.Enqueue("High", 1);
while (queue.Count > 0)
  Console.WriteLine(queue.Dequeue());

// Вывод:
// High
// Medium
// Low

Где использовать:
- планировщики заданий,
- обработка задач,
- алгоритмы маршрутизации,
- поиск пути в системах ИИ,
- моделирование событий.

См. подробнее про PriorityQueue

3. ConcurrentDictionary<TKey,TValue>
Обычный словарь (Dictionary) не является потокобезопасным. Если несколько потоков будут одновременно читать и записывать данные, это неизбежно приведёт к возникновению исключений или нарушению целостности данных.
ConcurrentDictionary решает эту проблему:

using System.Collections.Concurrent;

var cache = new ConcurrentDictionary<int, string>();
Parallel.For(0, 1000, i =>
{
  cache.TryAdd(i, $"User {i}");
});
Console.WriteLine(cache.Count);

Почему не использовать блокировку?
Вместо:

lock(_lock)
{
  dictionary.Add(...);
}

Используйте:

cache.TryAdd(key, value);

- яснее,
- быстрее,
- безопаснее.

Где использовать:
- кэширование,
- фоновые сервисы,
- параллельная обработка.

См. также Использование потокобезопасных коллекций

Окончание следует…

Источник: https://medium.com/turbo-net/7-dotnet-collections-youre-probably-not-using-but-should-a76437aa6a62

🦈 Открытое собеседование на Middle C# | 6 октября, 19:00 МСК

Приглашаем на открытое собеседование: Senior C# разработчик проведёт его в прямом эфире. Можно посмотреть, как всё устроено изнутри, и понять, насколько ты готов к такому интервью.

Как это будет:
📂 Собеседует Александр Моргунов — Senior C# разработчик, 7+ лет в европейских высоконагруженных сервисах. Отвечает разработчик-доброволец;

📂 Всё как на настоящем собесе: Александр задаёт те вопросы и задачи, которые даёт кандидатам на своих интервью. Заранее их никто не знает;

📂 После каждого ответа Александр даст обратную связь: что прозвучало сильно, а что стоило раскрыть иначе. Так станет понятнее, на что обращают внимание на собесе;

📂 В конце можно задать любой вопрос.

Это бесплатно. Эфир проходит в рамках менторской программы от ШОРТКАТ для C# разработчиков, которые хотят повысить свой грейд, ЗП и прокачать скиллы.

Переходи в нашего бота, чтобы получить ссылку на эфир -> @shortcut_csharp_bot

Реклама.
О рекламодателе.

День 2807. #ЗаметкиНаПолях
Типы Коллекций в .NET, Которые Стоит Попробовать. Окончание
Начало

4. ReadOnlyDictionary<TKey,TValue>
Иногда требуется, чтобы потребители могли читать словарь, но не могли его изменять. ReadOnlyDictionary служит оболочкой для существующего словаря.

var dict = new Dictionary<int, string>
{
  [1] = "One",
  [2] = "Two"
};
var readOnly =
  new ReadOnlyDictionary<int, string>(dict);
Console.WriteLine(readOnly[1]);

Попытки добавить или удалить элементы через обёртку не допускаются. Это простой способ безопасного предоставления доступа к данным через API «только для чтения».

См. также ReadOnly-Коллекция не Является Неизменяемой

5. ImmutableArray<T>
Иногда требуется коллекция, которую никто не сможет случайно изменить.
Именно это и обеспечивает ImmutableArray<T>:

using System.Collections.Immutable;

ImmutableArray<string> roles =
[
  "Admin",
  "Manager",
  "Employee"
];
foreach (var role in roles)
  Console.WriteLine(role);

Попытка изменить объект создаёт новый экземпляр вместо модификации исходного. Благодаря этому код становится гораздо проще анализировать.

Где использовать:
- конфигурации;
- доменные модели;
- разделяемое (shared) состояние приложения.

См. также
- Неизменяемые стеки и очереди
- Неизменяемые списки
- Неизменяемые множества
- Неизменяемые словари

6. FrozenDictionary<TKey,TValue>
Класс FrozenDictionary, появившийся в .NET 8, предназначен для хранения данных, которые не изменяются после создания. После инициализации коллекция становится неизменяемой и высокооптимизированной для операций поиска. Если ваше приложение при запуске загружает конфигурационные данные, коды стран, категории товаров или любые другие наборы данных, предназначенные только для чтения, эта коллекция может значительно превзойти по производительности обычный Dictionary:

using System.Collections.Frozen;

var countries = new Dictionary<string, string>
{
  ["US"] = "United States",
  ["IN"] = "India",
  ["JP"] = "Japan"
};

FrozenDictionary<string, string> frozen =
  countries.ToFrozenDictionary();
Console.WriteLine(frozen["IN"]);

Зачем?
- более быстрый поиск,
- потокобезопасность после создания,
- оптимизированное размещение в памяти.

Где использовать:
- конфигурации,
- справочные данные,
- таблицы поиска (lookup tables),
- статические кэши.

См. подробнее о замороженных коллекциях

Итого
В следующий раз, когда вы захотите использовать List<T> или Dictionary<TKey, TValue>, остановитесь на мгновение и спросите себя:
Существует ли коллекция, которая лучше подходит для этой задачи? Вы удивитесь, как часто ответ будет утвердительным.
Современная платформа .NET предлагает специализированные коллекции практически для любого сценария. Изучение того, когда их следует применять, — это небольшое вложение усилий, которое может существенно повлиять на качество и производительность ваших приложений.
Иногда самые значительные улучшения достигаются не за счёт написания дополнительного кода, а благодаря выбору подходящей структуры данных.

Источник: https://medium.com/turbo-net/7-dotnet-collections-youre-probably-not-using-but-should-a76437aa6a62

День 2808. #Карьера
5 Навыков, Которые Помогут Быстрее Стать Сеньором. Начало
В ИТ есть секрет, о котором все знают, но редко говорят: годы опыта не делают вас сеньором автоматически. Быть им — не значит знать наизусть все методы стандартных библиотек или писать самые изощрённые алгоритмы. Это вопрос масштаба, влияния на проект и управления рисками. Джуны и мидлы сосредоточены на том, чтобы код просто работал. Сеньоры заботятся о жизнеспособности системы, эффективности команды и успехе бизнеса. Если вы хотите ускорить карьерный рост и преодолеть этот «потолок», нужно иногда отвлекаться от IDE. Вот неочевидные навыки, которые значительно ускорят ваш путь к позиции сеньора.

1. Системное мышление (выход за рамки «туннельного зрения» при выполнении задач)
Когда мидл-разработчик получает задачу, он изучает требования и реализует то, что просят. Когда задачу получает сеньор, он оценивает систему целиком и анализирует, как новый элемент впишется в общую картину.

Пример
Поступает задача: отправлять пользователям email-уведомление при сбросе пароля. Мидл-разработчик подключает библиотеку для работы с почтой и встраивает логику отправки прямо в метод ResetPassword. Сеньор понимает, что со временем приложению могут понадобиться и другие каналы связи: SMS, push-уведомления, маркетинговые рассылки. Вместо того чтобы жёстко «зашивать» логику отправки email в код, он отделяет основную бизнес-логику от системы уведомлений.

Почему это важно
Системное мышление помогает избежать накопления технического долга. Если фокусироваться только на текущей задаче, можно создать хрупкий монолитный функционал. Умение видеть общую картину гарантирует, что код будет масштабируемым, удобным для тестирования и готовым к будущим изменениям.

Как применять
Прежде чем написать хоть строчку кода, задайтесь вопросами: «Что произойдёт, если нагрузку на эту функцию нужно будет увеличить в 10 раз?» или «Если я внесу эти изменения, что ещё может сломаться?»

2. Бескомпромиссная расстановка приоритетов (искусство продуктивного «нет»)
Ваша задача — не писать код, а приносить пользу. Иногда лучший способ принести пользу — вообще не писать код.

Пример
Продакт-менеджер просит реализовать для MVP (запуск которого намечен через две недели) сложную карусель «Рекомендуемые товары». Джун сидит до трёх ночи, пытаясь создать хоть какой-то работающий алгоритм рекомендаций. Сеньор предлагает альтернативу: «Разработка собственного алгоритма займёт три спринта. Может, для MVP мы просто выберем из базы данных 5 самых популярных товаров? Это займёт два часа и позволит проверить гипотезу о поведении пользователей».

Почему это важно
Инженеры часто попадают в ловушку «невозвратных затрат», увлекаясь избыточным проектированием. Нам нравится решать сложные технические задачи, даже если бизнесу они пока не нужны.

Как применять
Относитесь к своему времени разработки как к бюджету. Всегда ищите самый простой и быстрый способ проверить бизнес-гипотезу. Обсуждайте и согласовывайте объём работ с продакт-менеджерами. Они будут уважать вас гораздо больше за то, что вы сэкономили время компании, чем за написание сложного алгоритма, которым никто не пользуется.

Окончание следует…

Источник: https://medium.com/skillstuff/5-skills-that-will-make-you-a-senior-developer-faster-f4d5dfdf68f2

День 2809. #Карьера
5 Навыков, Которые Помогут Быстрее Стать Сеньором. Окончание
Начало

3. Эмпатия в коде (написание «скучных» решений)
«Хитроумный» код — враг удобного в сопровождении кода. Если вы тратите пять минут на написание кода в одну строку, а вашему коллеге требуется час, чтобы его расшифровать, — значит, вы не справились с ролью старшего инженера.

Пример
Вам нужно отфильтровать список пользователей, преобразовать их данные и суммировать общую стоимость их покупок. Вы используете цепочку вызовов LINQ-функции, перегруженную вложенными тернарными операторами, — просто потому, что это выглядит эффектно и умещается всего в две строки.

Почему это важно
Опытные разработчики пишут код с расчётом на того, кто будет его поддерживать — часто это они сами, но спустя полгода, в два часа ночи, когда система вышла из строя. Код читают в десять раз чаще, чем пишут.

Как применять
Отдавайте приоритет читаемости, а не краткости. Используйте понятные имена переменных; если логика становится сложной, предпочитайте стандартные циклы запутанным функциям высшего порядка; пишите комментарии, объясняющие *почему* было принято то или иное решение, а не *что именно* делает код.

4. Мастерское владение инструментами мониторинга и отладки
Мидл-разработчик может исправить ошибку, имея на руках стек-трейс. Сеньор способен исправить ошибку, даже если единственная информация — это жалоба клиента в Twitter о том, что «сайт сломался».

Пример
Система выходит из строя. Мидл-разработчик лихорадочно кликает по элементам приложения, пытаясь воспроизвести ошибку локально. Сеньор открывает дашборд, проверяет метрики задержек, фильтрует структурированные логи по конкретному trace_id, находит проблемный SQL-запрос и выпускает исправление за 10 минут.

Почему это важно
Нужно понимать, как правильно инструментировать приложение, чтобы в случае сбоя (а он неизбежен) система точно указывала, где именно возникла проблема.

Как применять
Изучите три столпа наблюдаемости: логи, метрики и трассировки. Перестаньте использовать простые строковые логи и перейдите на структурированное JSON-логирование с передачей контекста (ID пользователей, ID запросов). Научитесь пользоваться инструментами мониторинга вашего облачного провайдера.

5. Роль «мультипликатора эффективности»
Это ключевая характеристика сеньор-инженера. Эффективность мидла оценивается по его личному вкладу. Эффективность сеньора – по результатам работы всей команды.

Пример
В команде есть блестящий «10x-инженер», который работает изолированно, не делится знаниями и постоянно переписывает пул-реквесты джунов, не объясняя причин. Он выдает огромные объёмы кода, но общая скорость работы команды не растёт. Настоящий сеньор тратит 30% своего времени на то, чтобы помогать коллегам преодолевать препятствия в работе. Он пишет качественную документацию, проводит короткие сессии парного программирования и оставляет конструктивные, обучающие комментарии к пул-реквестам.

Почему это важно
Если вы — единственный человек, понимающий, как работает конвейер развёртывания, вы не старший инженер, а «единая точка отказа». Компании повышают тех, кто помогает окружающим становиться лучше.

Как применять
В следующий раз, когда джун задаст вопрос, не просто давайте готовый ответ и не исправляйте ошибку за него. Укажите на нужный файл, покажите, как пользоваться отладчиком, и направьте коллегу к решению. Документируйте сложные или неочевидные участки кодовой базы. Оставляйте код в лучшем состоянии, чем он был до вас.

Итого
Стать сеньором — это не результат мгновенного решения HR-отдела в день трёхлетия вашей работы в компании. Это фундаментальная смена мышления.
Вы переходите от вопроса «Как мне это реализовать?» к вопросам: «Стоит ли это вообще делать? Как система может выйти из строя? Кто будет её поддерживать?». Развивайте системное мышление, пишите читаемый код, взаимодействуйте с продуктовыми командами и помогайте расти окружающим вас разработчикам. Должность станет естественным следствием такого подхода.

Источник: https://medium.com/skillstuff/5-skills-that-will-make-you-a-senior-developer-faster-f4d5dfdf68f2