День 2632. #МоиИнструменты #PG
Инструменты Оптимизации Запросов в PostgreSQL. Часть 6

6. SQLFluff (SQL-линтер для производительности)
Что даёт: выявляет антипаттерны производительности до того, как запросы попадут в прод.
Зачем нужен: Большинство проблем с производительностью SQL возникают из-за распространённых ошибок: SELECT *, ненужные DISTINCT, отсутствие WHERE, неэффективные соединения. SQLFluff выявляет их на этапе разработки, до того, как они вызовут проблемы в продакшене.
Установка:

pip install sqlfluff

# Создаём конфиг
cat > .sqlfluff <<EOF
[sqlfluff]
dialect = postgres
templater = dbt
[sqlfluff:rules:L042]
# Запрет SELECT * в проде
select_
_targets = qualified
[sqlfluff:rules:L045]
# Обязательные алиасы полей
aliasing = explicit
[sqlfluff:rules:L052]
# Требование явных объединений
join_types = explicit
EOF

Использование
1. Линтинг SQL-файлов:

sqlfluff lint models/*.sql

Пример вывода:

== [models/orders.sql] FAIL
L:   5 | P:   8 | L042 | SELECT * is not allowed in production.
L:  12 | P:  15 | L031 | Avoid DISTINCT where possible (use GROUP BY).
L:  18 | P:   1 | L044 | Query is missing WHERE clause (full table scan).
L:  23 | P:  22 | L052 | JOIN should specify type (INNER, LEFT, etc.).

2. Автоматические исправления:

sqlfluff fix models/*.sql

До SQLFluff:

SELECT * FROM orders o
JOIN customers c ON o.customer_id = c.id
WHERE order_date > '2024-01-01';

Проблемы:
1. SELECT * (возвращает ненужные поля);
2. Неявное объединение (неясное намерение);
3. Сравнение даты без явного приведения типа.

После SQLFluff:

SELECT 
  o.order_id,
  o.order_date,
  o.total,
  c.customer_name
FROM orders AS o
INNER JOIN customers AS c 
  ON o.customer_id = c.id
WHERE o.order_date > CAST('2024-01-01' AS DATE);

Когда использовать
- dbt-проекты (отлично интегрируется);
- Несколько инженеров, пишущих SQL-запросы (обеспечение согласованности);
- Предотвращение распространённых ошибок;
- Конвейер CI/CD для SQL.

Когда отказаться
- Разработчик-одиночка (меньшая ценность);
- ad-hoc запросы (избыточно);
- Нестандартный диалект SQL (ограниченная поддержка).

Скрытая функция
Пользовательские правила для антипаттернов в вашей команде:

# custom_rules/no_cross_joins.py
from sqlfluff.core.rules import BaseRule, LintResult
class Rule_Custom_NoCrossJoin(BaseRule):
    """Запрет CROSS JOIN (почти всегда необязательны)."""
    
    def _eval(self, segment, **kwargs):
        if segment.is_type("join_clause"):
            if "CROSS" in segment.raw_upper:
                return LintResult(
                    anchor=segment,
                    description="Найден CROSS JOIN. Почти всегда необязателен.",
                    fixes=[...]  # Опционально: предложение исправления
                )

Добавить в .sqlfluff.

С осторожностью
Слишком агрессивный линтинг убивает продуктивность:

# Слишком строго (инженеры возненавидят)
sqlfluff lint --rules all
# Лучше начать с критических правил
sqlfluff lint --rules L042,L044,L052

Постепенно добавляйте правила со временем. Соблюдайте баланс между отловом проблем и сопротивлением разработчиков.

Источник: https://medium.com/@reliabledataengineering/15-sql-optimization-tools-that-make-queries-10x-faster-8629ac451d97

День 2633. #TipsAndTricks
Вызываем Файлы из Репозитория Действий в GitHub Actions
GitHub Actions позволяет создавать многократно используемые действия. Один из самых простых способов сделать это — использовать составные действия (Composite Actions), которые позволяют объединять несколько шагов в одно действие. Это уменьшает дублирование кода в ваших рабочих процессах.

При создании составного действия вам может потребоваться сослаться на файлы, хранящиеся в репозитории действий, например, на скрипт PowerShell или Bash.

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

Для доступа к файлам из репозитория действий используйте контекстную переменную github.action_path, которая содержит путь к каталогу, где находится ваше действие.

Вот пример того, как использовать её в файле action.yml:

name: 'My Composite Action'
description: 'An example'
runs:
  using: "composite"
  steps:
    - name: Run script
      run: ${{ github.action_path }}/script.sh
      shell: bash

В этом примере файл script.sh находится в корневом каталоге репозитория действий. Использование ${{ github.action_path }}/script.sh гарантирует, что исполнитель выполнит скрипт из правильного места.

Дополнительные ресурсы:
- Контексты GitHub - github.action_path
- Создание составного действия

Источник: https://www.meziantou.net/accessing-files-from-the-action-repository-in-a-github-composite-action.htm

День 2634. #TipsAndTricks #Git
Команды Git, Которые Я Запускаю Перед Чтением Кода
Автор оригинала: Ally Piechowski

Я занимаюсь аудитом кодовых баз моих клиентов. Первое, что я обычно делаю, когда берусь за новую кодовую базу, открываю терминал и запускаю несколько команд Git. Я хочу понять, кто основные авторы, где сосредоточены проблемы, уверенно ли команда выпускает продукт или ходит по минному полю.

1. Что меняется чаще всего

git log --format=format: --name-only --since="1 year ago" | sort | uniq -c | sort -nr | head -20

20 самых часто изменяемых файлов за последний год. Файл, находящийся вверху списка, почти всегда тот, о котором говорят: «К нему все боятся прикасаться».

Высокая активность в файле - иногда это просто активная разработка. Но если авторов много — это явный признак проблемы. Это файл, где каждое изменение — это исправление исправления. Я беру 5 файлов из этого списка и сопоставляю их с командой поиска ошибок (см. п. 3). Файл с высокой активностью и большим количеством ошибок — это основной источник риска.

2. Кто авторы

git shortlog -sn --no-merges

Авторы по количеству коммитов. Если на одного человека приходится 60%+, это ваш «автобусный фактор». Если он ушёл полгода назад, это кризис. Если ведущий автор из списка не появляется в течение 6 месяцев (git shortlog -sn --no-merges --since="6 months ago"), я немедленно сообщаю об этом клиенту.

Я также смотрю на хвост. 30 авторов, но только 3 были активны в течение последнего года. Т.е. люди, которые создали эту систему, не те, кто её поддерживает.

Замечание: рабочие процессы объединения коммитов сжимают информацию об авторстве. Если команда объединяет каждый пул-реквест в один коммит, этот результат отражает, кто объединил, а не кто написал. Стоит уточнить стратегию объединения, прежде чем делать выводы.

3. Места ошибок

git log -i -E --grep="fix|bug|broken" --name-only --format='' | sort | uniq -c | sort -nr | head -20

Та же структура, что и у 1й команды, но отфильтрована по коммитам с ключевыми словами, связанными с ошибками. Файлы, которые появляются в обоих списках, — это код с самым высоким риском: они постоянно ломаются и постоянно исправляются, но никогда не исправляются должным образом.

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

4. Проект ускоряется или умирает?

git log --format='%ad' --date=format:'%Y-%m' | sort | uniq -c

Количество коммитов по месяцам. Стабильный ритм — это хорошо. Но что, если количество коммитов падает в 2 раза за месяц? Обычно - кто-то ушёл. Снижение в течение 6-12 месяцев говорит о том, что команда теряет темп. Периодические всплески, за которыми следуют спокойные месяцы, означают, что команда работает над релизами партиями, а не выпускает их непрерывно.

5. Как часто «тушат пожары»?

git log --oneline --since="1 year ago" | grep -iE 'revert|hotfix|emergency|rollback'

Частота откатов и хотфиксов. Несколько откатов за год нормально. Каждые пару недель - команда не доверяет своему процессу развёртывания. Это свидетельство более глубокой проблемы: ненадёжные тесты, отсутствие приёмочных тестов или конвейер развертывания, который усложняет откаты. Отсутствие результатов – сигнал, что либо команда стабильна, либо никто не пишет подробные сообщения о коммитах.

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

Источник: https://piechowski.io/post/git-commands-before-reading-code/

День 2635. #Карьера
Приём Повышения Продуктивности, Который Используют Сеньоры. Начало
В начале своей карьеры я думал, что продуктивность означает работать усерднее всех остальных. Больше часов. Больше кода. Больше закрытых задач. Если я выпускал пять новых функций за неделю, я чувствовал себя продуктивным. Но происходило что-то странное. Самые уважаемые инженеры в моей команде — те, к кому все обращались при инцидентах — казались совсем не занятыми. Они не писали код постоянно. Они не спешили закрывать задачи. Иногда они даже уходили раньше остальных. И всё же каким-то образом они всегда были самыми эффективными. Мне потребовались годы, чтобы понять, какой приём они используют.

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

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

Секрет повышения продуктивности
Опытные инженеры тратят больше времени на размышления, чем на написание кода.

Не потому, что они ленивы. Потому что они знают, что один час размышлений может сэкономить недели работы. Когда возникает новая проблема, джуны часто сразу переходят к реализации. Сеньоры делают паузу. Они задают вопросы:
- Действительно ли это проблема?
- Есть ли более простое решение?
- Можем ли мы устранить проблему, вместо того чтобы её решать?
Именно в этой паузе кроется настоящая продуктивность.

Почему слишком быстрое написание кода опасно
Многие руководства по повышению продуктивности призывают разработчиков работать быстро. Но опытные инженеры знают, что скорость может нанести долгосрочный ущерб. Каждая строка кода вносит:
- поддержку в будущем,
- потенциальные ошибки,
- увеличение сложности,
- увеличение времени на отладку.
Опытные инженеры относятся к коду как к обузе, а не как к достижению.

Прежде чем что-либо писать, они задают себе простой вопрос: «Действительно ли нам нужен этот код?» Иногда ответ отрицательный. И когда ответ отрицательный, прирост продуктивности огромен.

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

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

Источник: https://medium.com/@optimzationking2/the-productivity-trick-that-senior-engineers-use-but-never-talk-about-5549af0078f9

День 2636. #Карьера
Приём Повышения Продуктивности, Который Используют Сеньоры. Окончание
Начало

Глубокая работа важнее постоянной активности
Ещё одна привычка, повышающая продуктивность — глубокая работа. Сеньоры избегают постоянных отвлечений. Они выделяют время для непрерывного обдумывания. Они знают, что сложные проблемы требуют длительных периодов сосредоточенности. Во многих командах продуктивность разрушается из-за:
- бесконечных сообщений в Slack,
- плотного графика совещаний,
- постоянного переключения контекста.
Старшие инженеры учатся защищать своё внимание. Не потому, что им не нравится сотрудничество. Потому что сложные инженерные проблемы требуют непрерывного обдумывания.

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

Реальный показатель производительности
Большинство команд измеряют производительность, используя такие показатели, как:
- выполненные задачи,
- стори-пойнты,
- смерженные пул-реквесты,
- коммиты в неделю.

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

Почему об этом приёме редко говорят
Этот приём повышения продуктивности незаметен. Размышления не отражаются в метриках. Упрощение системы не выглядит впечатляюще на панели мониторинга. Удаление кода редко приветствуется. Но за месяцы и годы такой образ мышления создаёт огромные различия между инженерами. Самые продуктивные разработчики — это не те, кто печатает быстрее всех. Это те, кто принимает лучшие решения ещё до того, как что-либо напечатает.

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

1. Делайте паузу перед написанием кода
Потратьте время на глубокое понимание проблемы. Часто первое решение не является лучшим.

2. Сократите ненужную работу
Ищите возможности для упрощения, а не для добавления новых функций.

3. Защищайте свою концентрацию
Выделите время для глубокого размышления. Сложные инженерные задачи редко решаются за 5 минут.

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

Источник: https://medium.com/@optimzationking2/the-productivity-trick-that-senior-engineers-use-but-never-talk-about-5549af0078f9

День 2637. #TipsAndTricks
Программно Подавляем Предупреждения Анализатора Roslyn
Анализаторы Roslyn отлично подходят для обеспечения соблюдения стандартов кодирования и поиска ошибок. Однако иногда они могут ложно срабатывать или выдавать предупреждения, которые вы хотите игнорировать в определённых контекстах. Вы можете подавить эти предупреждения с помощью директив #pragma или атрибутов [SuppressMessage], но оба подхода требуют изменения исходного кода.

DiagnosticSuppressor — компонент Roslyn, который подавляет диагностические сообщения, сообщаемые другими анализаторами или компилятором. В отличие от обычного анализатора, он выдаёт новых диагностических сообщений, а проверяет существующие и решает, следует ли их подавить. Это особенно полезно, когда вам нужно контекстно-зависимое подавление без загромождения кода.

Для реализации DiagnosticSuppressor необходимо:
1. Создать класс, наследующий от DiagnosticSuppressor;
2. Декорировать класс с помощью [DiagnosticAnalyzer(LanguageNames.CSharp)];
3. Определить SuppressionDescriptor для каждого правила, которое вы хотите подавить;
4. Переопределить SupportedSuppressions, чтобы возвращать поддерживаемые дескрипторы;
5. Переопределить ReportSuppressions, чтобы реализовать логику подавления.

Пример
Допустим, вы используете Newtonsoft.Json для сериализации классов. Правило анализатора CA1507 предлагает заменить строковые литералы выражениями nameof. Однако, когда вы используете атрибут [JsonProperty("propertyName")], анализатор помечает строковый литерал как нарушение CA1507. Но в этом сценарии вам может быть удобнее использовать строку, т.к. это имя свойства JSON является частью контракта API и должно оставаться неизменным, даже если вы переименуете свойство C#.

Вот как можно реализовать подавитель для этого сценария:

using Microsoft.CodeAnalysis;
using Microsoft.CodeAnalysis.CSharp.Syntax;
using Microsoft.CodeAnalysis.Diagnostics;
using System.Collections.Immutable;

namespace Analyzer.Suppressors;

[DiagnosticAnalyzer(LanguageNames.CSharp)]
public sealed class CA1507Suppressor : DiagnosticSuppressor
{
  // Определяем правило подавления
  private static readonly
   SuppressionDescriptor RuleJsonProperty = new(
    id: "EXAMPLE0001", // ID «подавителя»
    suppressedDiagnosticId: "CA1507", // ID правила
    justification: "Suppress CA1507 on methods decorated with a [Newtonsoft.Json.JsonPropertyAttribute]."
   );

  // Регистрируем подавление
  public override ImmutableArray<SuppressionDescriptor>
   SupportedSuppressions => [RuleJsonProperty];

  public override void ReportSuppressions(
   SuppressionAnalysisContext ctx)
  {
    // Проверяем правила диагностики
    foreach (var diag in ctx.ReportedDiagnostics)
    {
      // Получаем локацию диагностики и синтаксическое дерево
      var location = diag.Location;
      var tree = location?.SourceTree;
      if (tree is null)
        continue;

      // Находим ноду в дереве
      var root = tree.GetRoot(ctx.CancellationToken);
      var node = root.FindNode(location!.SourceSpan);
      if (node is null)
        continue;

      var parent = node.FirstAncestorOrSelf<AttributeSyntax>();
      if (parent is null)
        continue;

      var semanticModel = ctx.GetSemanticModel(tree);
      var info = semanticModel.GetSymbolInfo(parent, ctx.CancellationToken);

      if (info.Symbol is not IMethodSymbol mtdSymb)
        continue;

      // Проверяем, что тип атрибута Newtonsoft.Json.JsonPropertyAttribute
      var attrType = ctx.Compilation.GetTypeByMetadataName(
       "Newtonsoft.Json.JsonPropertyAttribute");

      if (attrType is null)
        continue;

      if (mtdSymb.ContainingType.Equals(attrType, SymbolEqualityComparer.Default))
      {
        // Подавляем
        var suppr = Suppression.Create(RuleJsonProperty, diag);
        ctx.ReportSuppression(suppr);
      }
    }
  }
}

Источник: https://www.meziantou.net/suppressing-roslyn-analyzer-warnings-programmatically-using-diagnosticsuppressor.htm

День 2638. #МоиИнструменты #PG
Инструменты Оптимизации Запросов в PostgreSQL. Часть 7

7. pghero (Панель Управления Производительностью Postgres)
Что даёт: простой мониторинг производительности PostgreSQL для команд без выделенных администраторов баз данных.
Язык: Ruby.
Поддержка: очень активная.

Зачем нужен
Большинство инструментов мониторинга сложны и дороги. pghero предоставляет 80% функциональности в простом веб-интерфейсе: медленные запросы, отсутствующие индексы, раздувание таблиц, проблемы с подключением — всё на одной панели мониторинга.

Установка
1. Docker (самая простая)

docker run -ti -e DATABASE_URL=postgres://user:pass@host:5432/dbname \
  -p 8080:8080 ankane/pghero

2. Для Rails

gem install pghero
pghero config:set DATABASE_URL=postgres://…
pghero server

За чем можно наблюдать
1. Медленные запросы (последние 24 часа):
SELECT … FROM orders JOIN … (avg: 45s, 234 calls)
→ Missing index on orders(customer_id, order_date)

UPDATE inventory … (avg: 12s, 5,432 calls)
→ Long-running, blocking other queries

2. Отсутствующие индексы:
- orders.customer_id (queries: 1,234/day, est. speedup: 100x)
- customers.email (queries: 456/day, est. speedup: 50x)

3. Раздувание таблиц:
- orders: 35% bloat (recommend VACUUM)
- customer_events: 62% bloat (recommend VACUUM FULL)

4. Проблемы с соединением:
- Max connections: 100
- Current: 87 (87% utilization) ⚠️
- Idle in transaction: 12 (potential locks)

5. Использование индексов:
- idx_orders_date: 2.3M scans/day ✅
- idx_orders_legacy: 0 scans/day (unused, consider dropping)

Когда использовать
- PostgreSQL в продакшене;
- нет выделенного администратора баз данных;
- нужен простой мониторинг;
- нужны действенные рекомендации (а не просто метрики).

Когда отказаться
- необходим мониторинг разных БД (pghero работает только с PostgreSQL);
- необходим подробный исторический анализ (pghero отображает текущее состояние + 24 часа);
- уже есть комплексный мониторинг (Datadog и т. д.).

Скрытая функция
Визуализация плана запроса. В pghero щёлкните на любой медленный запрос. Отобразится:
1. Текст запроса;
2. План выполнения (визуальный);
3. Рекомендуемые индексы;
4. Предложение по изменению запроса;
5. Создание индекса одним щелчком (генерирует DDL).

С осторожностью
Запросы pghero могут быть дорогими на больших базах данных. Настройка, чтобы снизить нагрузку:

# config/pghero.yml
databases:
  primary:
    url: <%= ENV["DATABASE_URL"] %>
    # Снижение частоты запросов
    slow_query_ms: 1000  # Только запросы длиннее 1с
    slow_query_calls: 10  # Только 10+ вызовов
    # Выключение дорогих проверок
    index_bloat: false  # Медленно на БД в 1TB+

Источник: https://medium.com/@reliabledataengineering/15-sql-optimization-tools-that-make-queries-10x-faster-8629ac451d97

День 2639. #ЗаметкиНаПолях
Первичные Конструкторы для Внедрения Зависимостей. Начало
Когда в C# 12 внедрили первичные конструкторы в классах, это было встречено скептически. Неявное изменяемое поле вместо явного поля только для чтения? Это казалось обменом безопасности на удобство. Но практика показала, что они значительно сокращают количество шаблонного кода в сервисных классах, а ловушка, которой все опасались, становится управляемой, если вы о ней знаете.

Классы сервисов
Вот как раньше выглядели классы сервисов:

public class OrderService
{
  private readonly IOrderRepository _repo;
  private readonly ILogger<OrderService> _logger;

  public OrderService(
   IOrderRepository repo,
   ILogger<OrderService> logger)
  {
    _repo = repo;
    _logger = logger;
  }

  public async Task<Order?> GetAsync(Guid id)
  {
    _logger.LogInformation("Получаем заказ {OrderId}", id);
    return await _repo.GetByIdAsync(id);
  }
}

И как теперь:

public class OrderService(
 IOrderRepository repo,
 ILogger<OrderService> logger)
{
  public async Task<Order?> GetAsync(Guid id)
  {
    logger.LogInformation("Получаем заказ {OrderId}", id);
    return await repo.GetByIdAsync(id);
  }
}

Объявления полей, тело конструктора, присваивания — всё исчезло. Параметры перехватываются и становятся доступны во всём теле класса.

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

Создание сущностей (с оговоркой)
Можно использовать первичные конструкторы для сущностей предметной области и объектов-значений, где необходимо обеспечить обязательность параметров во время создания:

public class Order(Guid customerId, Money total)
{
  public Guid Id { get; } = Guid.NewGuid();
  public Guid CustomerId { get; } = customerId;
  public Money Total { get; } = total;
  public OrderStatus Status { get; private set; }
    = OrderStatus.Pending;
  public DateTime CreatedAt { get; }
    = DateTime.UtcNow;

  public void Confirm()
  {
    if (Status != OrderStatus.Pending)
    {
      throw new InvalidOperationException(
       $"Нельзя подтвердить заказ в статусе {Status}.");
    }

    Status = OrderStatus.Confirmed;
  }
}

Создать заказ без customerId и total невозможно. Первичный конструктор делает это ограничение видимым на уровне объявления типа.

Обратите внимание на ключевое отличие от шаблона класса сервиса: параметры первичного конструктора присваиваются свойствам с инициализаторами (= customerId). Это важно, и это приводит к самой большой проблеме первичных конструкторов.

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

Источник: https://www.milanjovanovic.tech/blog/why-i-switched-to-primary-constructors-for-di-in-csharp

День 2640. #ЗаметкиНаПолях
Первичные Конструкторы для Внедрения Зависимостей. Окончание
Начало

Ловушка, которая отталкивает многих
Параметры первичного конструктора не являются полями только для чтения. Когда вы используете параметр первичного конструктора непосредственно в теле класса (как мы делали в классе сервиса), компилятор захватывает его как изменяемую переменную. За кулисами не генерируется поля только для чтения.

Т.е. вы можете изменить значение параметра:

public class OrderService(
 IOrderRepository repo,
 ILogger<OrderService> logger)
{
  // …
  
  public void SomeOtherMethod()
  {
    repo = null!;
    logger = null!;
  }
}

Этот код компилируется без ошибок и предупреждений. Если вам необходимы гарантии неизменяемости, явно присвойте параметр полю только для чтения:

public class OrderService(
 IOrderRepository repo,
 ILogger<OrderService> logger)
{
  private readonly IOrderRepository _repo = repo;
  private readonly ILogger<OrderService> _logger = logger;
  
  // …
}

Но теперь мы потеряли большую часть преимуществ первичных конструкторов. Мы вернулись к объявлениям полей и присваиваниям, только с другим синтаксисом.

На практике вряд ли вы столкнётесь с этой проблемой в классе сервиса, получаемого из DI. Маловероятно, что вы случайно измените значение logger посреди метода. Но это может создать проблемы в классах сущностей или объектов-значений, где неизменяемость действительно важна. Это единственное место, где по-прежнему стоит проявлять осторожность.

Где использовать традиционные конструкторы
Вот случаи, когда стоит придерживаться традиционного подхода:

1. Сложная логика валидации
Если нужно проверять параметры перед их присваиванием, понадобится тело конструктора:

public class EmailAddress
{
  private readonly string _value;

  public EmailAddress(string value)
  {
    if (string.IsNullOrWhiteSpace(value)
        || !value.Contains('@'))
      throw new ArgumentException(
        "Неверный email.", nameof(value));
    
    _value = value;
  }
}

Первичные конструкторы не позволяют разместить логику валидации до выполнения тела класса.

2. Множественные перегрузки конструкторов
Первичные конструкторы поддерживают одну сигнатуру конструктора. Если вам нужны перегрузки, придётся связывать обычные конструкторы с помощью this(…), что быстро приводит к беспорядку.

3. Слишком много параметров
Как только вы достигнете 5 и более зависимостей, строка первичного конструктора станет трудночитаемой. Хотя, тогда класс, вероятно, будет иметь слишком много обязанностей, и рефакторинг будет лучшим решением, чем ухищрения с форматированием.

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

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

Источник: https://www.milanjovanovic.tech/blog/why-i-switched-to-primary-constructors-for-di-in-csharp

День 2641. #ЗаметкиНаПолях
Паттерн «Интерпретатор» в .NET. Начало
Когда бизнес-правила похоронены в цепочках if-else.

Система скидок начиналась с простого: 10% на заказы свыше $100. Одно условие, одно правило. Затем отдел маркетинга захотел: "20% для VIP-клиентов И заказом свыше $200." Затем: "Бесплатную доставку товаров категории "Электроника" ИЛИ за заказ свыше $500." И т.д., и т.п.

Теперь метод предоставления скидок — это 150 строк вложенных условных операторов, к которым никто не хочет прикасаться:

public decimal CalculateDiscount(
 Order order, Customer customer)
{
  if (customer.IsVip && order.Total > 200)
    return order.Total * 0.20m;
  else if (order.Total > 100)
    return order.Total * 0.10m;
  else if (order.Items.Any(i => i.Category == "Electronics") || order.Total > 500)
    order.Shipping = 0;
  
  // … ещё 20 условий

  return order.Total;
}

Каждое новое правило требует модификации кода, повторного развёртывания и тестирования всей цепочки. Маркетинг не может обновлять правила без участия разработчиков. А логика совершенно непрозрачна — никто не может прочитать её и понять весь набор правил.

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

Паттерн «Интерпретатор»
Паттерн «Интерпретатор» определяет грамматику для языка и предоставляет интерпретатор, который оценивает выражения на этом языке. Каждое правило в грамматике - класс. Сложные правила компонуются из простых.

Определим интерфейс выражений и атомарные выражения:

// Контекст - данные, которые будут оцениваться в выражениях
public class RuleContext(Order order, Customer customer)
{
  public Order Order { get; } = order;
  public Customer Customer { get; } = customer;
}
 
// Абстрактное выражение
public interface IExpression
{
  bool Interpret(RuleContext ctx);
}
 
// Окончательные выражения: атомарные условия
public class OrderTotalGreaterThan(decimal threshold)
  : IExpression
{
  public bool Interpret(RuleContext ctx)
      => context.Order.Total > threshold;
}

public class CustomerIsVip : IExpression
{
  public bool Interpret(RuleContext ctx)
      => context.Customer.IsVip;
}

public class OrderContainsCategory(string category)
 : IExpression
{
  public bool Interpret(RuleContext ctx)
    => ctx.Order.Items.Any(i =>
      i.Category.Equals(category, 
       StringComparison.OrdinalIgnoreCase));
}

// …

Теперь нетерминальные выражения – логические действия:

// И
public class AndExpression(IExpression left, IExpression right)
 : IExpression
{
  public bool Interpret(RuleContext ctx)
    => left.Interpret(ctx) && right.Interpret(ctx);
}

// ИЛИ
public class OrExpression(IExpression left, IExpression right)
 : IExpression
{
  public bool Interpret(RuleContext ctx)
    => left.Interpret(ctx) || right.Interpret(ctx);
}

// НЕ
public class NotExpression(IExpression expression)
 : IExpression
{
  public bool Interpret(RuleContext ctx)
      => !expression.Interpret(ctx);
}

Составляем правила из выражений:

// VIP-клиент и заказ > $200
var vipHighValueRule = new AndExpression(
  new CustomerIsVip(),
  new OrderTotalGreaterThan(200));

var ctx = new RuleContext(order, customer);

if (vipHighValueRule.Interpret(ctx))
  discount = 0.20m;

Правила — это компонуемые структуры данных. Вы можете хранить их, сериализовать и создавать из конфигурации.

Почему это лучше
1. Правила — это данные, а не код. Вы можете хранить определения правил в БД и создавать деревья выражений во время выполнения. Для новых правил не требуется повторное развёртывание.
2. Компонуемость. Операторы И, ИЛИ и НЕ объединяют любые выражения. Сложные правила строятся из простых, протестированных компонентов.
3. Тестируемость. Каждое выражение представляет собой отдельный класс с одним методом. Тестируйте OrderTotalGreaterThan независимо от всего остального.

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

Источник: https://thecodeman.net/posts/interpreter-pattern-in-dotnet

День 2642. #ЗаметкиНаПолях
Паттерн «Интерпретатор» в .NET. Расширенное использование
Начало

1. Создание правил из конфигурации
Парсим правила из JSON или БД:

public class RuleEngine
{
  public IExpression BuildFromConfig(
   RuleDefinition def) => def.Type switch
   {
     "OrderTotalGreaterThan" =>
       new OrderTotalGreaterThan(
        def.GetParam<decimal>("threshold")),
     "CustomerIsVip" =>
       new CustomerIsVip(),
     "OrderContainsCategory" =>
       new OrderContainsCategory(
        def.GetParam<string>("category")),
     "AND" =>
       new AndExpression(
        BuildFromConfig(def.Left!),
        BuildFromConfig(def.Right!)),
     "OR" =>
       new OrExpression(
        BuildFromConfig(def.Left!),
        BuildFromConfig(def.Right!)),
     "NOT" =>
       new NotExpression(BuildFromConfig(def.Left!)),
     _ => throw new InvalidOperationException(
            $"Неизвестный тип: {def.Type}")
   };
}

Определение правила в JSON:

{
  "type": "AND",
  "left": { "type": "CustomerIsVip" },
  "right": { "type": "OrderTotalGreaterThan", "params": { "threshold": 200 } }
}

Теперь отдел маркетинга может определять правила в UI панели управления. RuleEngine анализирует и оценивает их без изменения кода.

2. Парсинг выражений для вычисляемых полей
Аналогично можно создавать математические выражения:

public interface IMathExpression
{
  decimal Evaluate(Dictionary<string, decimal> variables);
}

public class NumberLiteral(decimal value)
  : IMathExpression
{
  public decimal Evaluate(Dictionary<string, decimal> variables)
    => value;
}

public class Variable(string name)
  : IMathExpression
{
  public decimal Evaluate(Dictionary<string, decimal> variables)
    => variables[name];
}

public class Multiply(IMathExpression left, IMathExpression right)
  : IMathExpression
{
  public decimal Evaluate(Dictionary<string, decimal> variables)
      => left.Evaluate(variables) * right.Evaluate(variables);
}
 
// Выражение: price * quantity * (1 - discount)
var totalExpr = new Multiply(
 new Multiply(new Variable("price"), new Variable("quantity")),
 new Subtract(new NumberLiteral(1), new Variable("discountRate")));
 
var vars = new Dictionary<string, decimal>
{
  ["price"] = 29.99m, ["quantity"] = 3, ["discount"] = 0.10m
};
 
var total = totalExpr.Evaluate(vars); // 80.973

Когда не использовать
1. Для сложных правил. Если нужны циклы, функции или сложный синтаксис, используйте подходящий генератор парсеров (ANTLR) или существующий скриптовый движок (Roslyn, Lua). Паттерн «Интерпретатор» плохо масштабируется для сложных языков.

2. Важна производительность. Каждый вызов Interpret() проходит по дереву выражений. Для часто используемых путей с миллионами вычислений скомпилированные выражения (Expression<T>.Compile()) на порядки быстрее.

3. Правила редко меняются. Если правила стабильны и меняются раз в год, затраты на создание интерпретатора не оправданы. Просто пишите условия напрямую.

«Интерпретатор» избыточен?
Для 3-4 фиксированных условий — да. Просто используйте if-else. Паттерн особенно эффективен, когда у вас более 20 правил, которые регулярно меняются и позволяют создавать комбинации без перекомпиляции кода.

Альтернативы
Для оценки во время выполнения деревья выражений C# Expression<T> компилируются в IL. Для простой оценки правил может подойти словарь делегатов или паттерн «Стратегия».

Источник: https://thecodeman.net/posts/interpreter-pattern-in-dotnet

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

31. Паттерн MVC
«Расскажите, что такое паттерн MVC и как вы его реализовали в своих проектах? Приведите пример того, как вы использовали MVC.»

Хороший ответ
Паттерн MVC (Model-View-Controller) — это принцип проектирования, который разделяет приложение на три взаимосвязанных компонента. Такое разделение помогает управлять сложностью, способствует организации кода и поддерживает масштабируемость:
1. Модель - слой данных и бизнес-логики приложения. Она отвечает за хранение данных, их обработку и определение бизнес-правил.
2. Представление - обрабатывает отображение данных, получая модель от контроллера. Оно только отображает информацию пользователю и отправляет команды пользователя контроллеру.
3. Контроллер - выступает в качестве посредника между моделью и представлением, получая данные из модели и решая, какое представление отображать.

В своих проектах я использовал паттерн MVC, чтобы обеспечить надлежащее разделение задач, что упрощает поддержку и расширение приложения. Например:

// Модель
public class Product
{
  public int Id { get; set; }
  public string Name { get; set; }
  public decimal Price { get; set; }
}

// Контроллер
public class ProductsController : Controller
{
  private readonly IProductRepo _repo;

  public ProductsController(IProductRepo repo)
  {
    _repo = repo;
  }

  public async Task<IActionResult> Index()
  {
    var products = await _repo.GetAllAsync();
    // Передаём модель в представление
    return View(products);
  }
}

// Представление (Index.cshtml)
@model IEnumerable<Product>
<h2>Продукты</h2>
<ul>
@foreach(var product in Model)
{
  <li>@product.Name - $@product.Price</li>
}
</ul>

В этом примере ProductsController получает данные о продуктах, используя репозиторий IProductRepo, который абстрагирует логику доступа к данным. Полученные данные затем передаются в представление Index, которое отвечает за отображение информации о продуктах. Такое разделение позволяет вносить изменения в модель БД или бизнес-логику, не затрагивая логику представления, и наоборот, тем самым соблюдая принцип единственной ответственности.

Такой подход не только делает архитектуру яснее, но и повышает тестируемость приложения. Каждый компонент может быть протестирован независимо, что крайне важно для поддержания высокого качества кода по мере масштабирования приложения.

Часто встречающийся плохой ответ
«MVC — это просто обеспечение наличия моделей, представлений и контроллеров в проекте. Нужно поместить HTML-код в представления, код получения из БД в модели и использовать контроллеры для связи всего этого».

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

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

- Непонимание лучших практик в архитектуре MVC, таких как размещение бизнес-логики вне контроллеров и представлений.

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

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

День 2644. #ЧтоНовенького
Первые Очертания Visual Studio 2027
Мадс Кристенсен из Microsoft на конференции VSLive! в Лас-Вегасе (плейлист докладов, кстати, вот тут) рассказал, что нового будет в Visual Studio 2027.

Модель непрерывного выпуска
Вместо того чтобы позиционировать 2027 как традиционную новую основную версию, которая выходит как отдельный продукт, представленная на VSLive! дорожная карта описывает более стабильное ежемесячное развитие с появлением новых возможностей по ходу.

Т.е. Microsoft переводит VS на модель непрерывного выпуска. Стабильный канал General Availability получает ежемесячные обновления, а канал Insider развивается - еженедельные, предоставляя разработчикам ранний доступ к функциям. Так переход от VS 2026 к VS 2027 – это обновление существующей среды на месте, а не переустановка, и он будет скорей последовательностью непрерывных обновлений, а не единым релизом. Теперь командам разработки не придётся планировать миграцию инструментов отдельно от обычных циклов обновлений. Поэтапные обновления также приблизят IDE к темпам изменений в рабочих процессах разработки .NET и C# (VS 2027 обещают выпустить вместе с релизом новой версии .NET в ноябре).

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

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

В демонстрации новой возможности VS «Профилирование с помощью Copilot» Copilot запустил модульный тест для популярной библиотеки QR Coder в профилировщике, установил базовый уровень производительности, проанализировал полученную трассировку, выявил ресурсоёмкие пути в коде (в частности, вычисления с плавающей запятой), предложил оптимизации, пересобрал проект, повторно запустил тест для подтверждения корректности и измерил результирующее улучшение производительности примерно на 63%.

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

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

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

Источник: https://visualstudiomagazine.com/articles/2026/04/17/at-vslive-mads-k-lets-the-cat-out-of-the-bag-on-visual-studio-2027.aspx

День 2645. #ЗаметкиНаПолях
Тестовая Пирамида — Ложь (и Что Делать Вместо Этого). Начало
Автор оригинала: Milan Jovanović

Наверное, никогда мои проекты не имели канонической тестовой пирамиды, как на рисунке ниже. Широкое основание модульных тестов, узкое середина интеграционных тестов, крошечный кусочек сквозных тестов на вершине. Я согласно кивал на конференциях, но делал по-своему.

Откуда взялась пирамида
Пирамида была популяризирована Майком Коном в 2009 году, когда интеграционные тесты означали общий сервер БД, нестабильный CI и 20-минутные сборки. Модульные тесты с моками были прагматичным компромиссом.

Этот мир ушёл в прошлое. С помощью Testcontainers можно быстро запустить PostgreSQL, Redis и RabbitMQ в новом контейнере для каждого тестового класса. Aspire Test Host идёт ещё дальше, подключая весь граф вашего приложения. Аргумент о том, что реальные зависимости слишком затратны, по сути, больше не актуален. Но рекомендации не обновились.

Ошибка, которая меня убедила
Пару лет назад у меня был сервис с 94% покрытием модульными тестами. Все тесты были «зелеными». Но в один прекрасный день пользователь сообщил, что удаление учётной записи на самом деле не приводит к удалению его данных. Метод был проще некуда:

public async Task Handle(DeleteAccountCommand command, CancellationToken ct)
{
  var account = await _repo.GetByIdAsync(command.AccountId, ct);
  account.MarkAsDeleted();
}

Да, в нём забыли вызвать SaveChangesAsync(). И тест для этого случая просто не был написан. Можно проверить, был ли вызван SaveChangesAsync в методе с помощью мока. Но в кодовой базе, где этот тест — один из сотен тестов обработчиков, каждый со своей настройкой мока и своим списком проверок, про это просто забыли. И покрытие тестами показывало, что всё в порядке.

Один интеграционный тест с реальной БД обнаружил бы это в миг. В этом суть: чем меньше инвариантов ваш стиль тестирования заставляет вас запоминать, тем меньше ошибок проскальзывает.

В чём на самом деле хороши модульные тесты
Модульные тесты оправдывают себя, когда логика нетривиальна, чиста (без операций ввода-вывода, без асинхронности, без случайности) и сложна для проверки от начала до конца. Это вариантов кода вроде объектов-значений и сложных моделей домена, расчётов цен и налогов, парсеров, мапперов, сериализаторов и т.п.

Заметили, чего нет в этом списке? Сервисов, обработчиков, контроллеров, репозиториев, инфраструктуры. Они находятся на стыке модулей, и именно в этом стыке и кроются настоящие ошибки.

Что же делать вместо этого?

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

Источник: https://www.milanjovanovic.tech/blog/the-test-pyramid-is-a-lie-and-what-i-do-instead

День 2646. #ЗаметкиНаПолях
Тестовая Пирамида — Ложь (и Что Делать Вместо Этого). Окончание
Начало

Что делать вместо тестовой пирамиды
Вот структура тестов для типичного сервиса .NET или модульного монолита.

Уровень 1: Тонкая база модульных тестов (15-25% тестов)
Вся логика домена. Никаких контейнеров или моков. Микросекунды на тест. Для этого и существуют модульные тесты. Если модульному тесту нужен мок, то он будет на уровне интеграции.

[Fact]
public void Confirm_WhenPending_TransitionsToConfirmed()
{
  var order = Order.Create(
   CustomerId.New(), Money.Usd(100));

  order.Confirm();

  order.Status.Should()
   .Be(OrderStatus.Confirmed);
  
  order.DomainEvents.Should()
   .ContainSingle(e => e is OrderConfirmedEvent);
}

Уровень 2: Толстый средний слой интеграционных тестов (60-70%)
Все обработчики команд и запросов, все конечные точки HTTP, все потребители сообщений тестируются на реальной инфраструктуре внутри тестовых контейнеров. В модульном монолите именно здесь проверяется корректность взаимодействия модулей друг с другом через их публичные API.

public class DeleteAccountTests(
 IntegrationTestWebAppFactory factory)
  : BaseIntegrationTest(factory)
{
  [Fact]
  public async Task DeleteAccount_MarksAccountDeleted()
  {
    var acc = await CreateAccountAsync();

    var resp = await HttpClient
     .DeleteAsync($"/accounts/{acc.Id}");

    resp.StatusCode.Should().Be(HttpStatusCode.NoContent);

    var stored = await DbContext.Accounts
      .IgnoreQueryFilters()
      .SingleAsync(a => a.Id == acc.Id);

    stored.IsDeleted.Should().BeTrue();
  }
}

Эти тесты проверяют слой HTTP, маршрутизацию, привязку модели, авторизацию, обработчики, контексты, EF Core и PostgreSQL. Они доказывают то, что вас действительно интересует: когда я вызываю эту конечную точку, строка в базе изменяется. И это происходит без необходимости кому-либо помнить о вызове SaveChangesAsync и проверке, вызывается ли он.

Уровень 3: Небольшое количество сквозных тестов (<10%)
Только те потоки, где скрытый сбой может представлять коммерческую проблему или проблему соответствия требованиям. Регистрация, оплата, возврат средств, сброс пароля, двухфакторная аутентификация. Они медленные и иногда нестабильные, но они выявляют тот единственный режим отказа, который все остальные тесты пропускают: система в целом продолжает работать.

Уровень 0: Архитектурные и контрактные тесты
Часто забываются, но они являются частью набора тестов. Архитектурные тесты обеспечивают соблюдение разделения на слои и границ модулей. Контрактные тесты проверяют, что схемы сообщений и формат API не меняются. Они выполняются за миллисекунды и выявляют ошибки типа «через шесть месяцев кто-то сломает это, не заметив».

Полученная форма больше напоминает ромб, чем пирамиду. Толстая середина — это намеренное решение. Именно отсюда и берётся уверенность в тестах.

Обычные возражения
«Интеграционные тесты медленные». Мой типичный набор интеграционных тестов выполняется за 2-4 минуты в CI с повторным использованием Testcontainers и распараллеливанием тестовых классов. Медленнее, чем модульные тесты? Да. Но быстрее, чем обнаружение ошибки в продакшене.

«Моки хороши, если вы дисциплинированы». Возможно. Но в каждой крупной кодовой базе, которую я проверял и которая сильно полагалась на моки, была одна и та же патология: тесты проходят после рефакторинга, даже если рефакторинг сломал продакшен. Это не проблема дисциплины. Это неправильное использование инструмента.

Итого
Пирамида тестирования была хорошим советом для инфраструктуры 2009 года, но является плохим советом для инфраструктуры 2026 года. Testcontainers и Aspire изменили экономику, и самый быстрый цикл обратной связи, который по-прежнему сообщает правду, теперь — это интеграционный тест с реальными зависимостями. Модульные тесты по-прежнему должны быть сосредоточены на чистой логике предметной области. Всё, что переходит через границы модулей, должно быть на уровне интеграции.

Источник: https://www.milanjovanovic.tech/blog/the-test-pyramid-is-a-lie-and-what-i-do-instead

День 2647. #ProjectManagement
Как Проваливаются Разработчики ПО. Начало
«Разработчики ПО терпят неудачу двумя способами: они либо делают продукт не так, либо делают не тот продукт».

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

1. Неправильная разработка продукта
Техническое исполнение неверное. Требования могли быть поняты правильно, но реализация была ошибочной. Например:
- Ошибки, вызывающие некорректное поведение;
- Низкая производительность, делающая ПО непригодным;
- Уязвимости безопасности, подвергающие пользователей риску;
- Хрупкая архитектура, которая затрудняет обслуживание или расширение системы;
- Код настолько сложный или запутанный, что никто не может безопасно его изменить.
Про эти неудачи мы чаще всего говорим. Проверки кода, автоматизированное тестирование, статический анализ и конвейеры CI/CD, существуют в первую очередь для того, чтобы выявлять и предотвращать подобные неудачи.

2. Создание неправильного продукта
Техническое исполнение может быть безупречным, но ПО не решает нужную проблему. Продукт компилируется, запускается и может работать без проблем. Но есть признаки того, что вы создали не то, что нужно:
- Решает проблему, с которой на самом деле никто не сталкивается;
- Решает проблему, которая никому на самом деле не важна;
- Решает вчерашнюю проблему, а не сегодняшнюю;
- Предоставляет функции, которые запрашивали пользователи, но не то, что им действительно было нужно;
- Делает неверные предположения о том, как должно быть реализовано решение.
Это более тонкий и часто более дорогостоящий случай. Прекрасно разработанное, безошибочное и производительное приложение может не приносить никакой пользы, потому что оно изначально решает не ту проблему. Все усилия потрачены впустую.

Вся концепция agile-разработки, методология бережливого стартапа и такие практики, как маппинг пользовательских историй и постоянная обратная связь с клиентами, существуют в основном для борьбы с этим вторым типом ошибок. И, к сожалению, автоматизировать это не так просто. Нет компилятора, набора модульных тестов или линтера, которые бы сказали, что ваше ПО соответствует тому, что хотел клиент. Такие практики, как разработка через приёмочные тесты (ATDD), безусловно, могут помочь, но они, как правило, требуют поддержки и усилий, выходящих далеко за рамки команды разработчиков.

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

Более опасная ошибка — успешный выпуск чего-то, что не нужно. А иногда и нежелательно. Это может создать у команды разработчиков ложное чувство успеха, которое затем приводит к ещё большему разочарованию, когда им приходится откатывать изменения или вносить серьёзные обновления. Почти всегда это ошибка в коммуникации, а не в навыках программистов, и усилия, необходимые для её исправления, обычно более масштабны, постоянны (нельзя просто добавить ещё один этап сборки) и, вероятно, затронут несколько команд внутри организации. И Scrum, и XP предполагают наличие в команде разработчиков эксперта в предметной области, представляющего заказчика, но организации редко нанимают такого специалиста. Чаще это делается кем-то не связанным с командой разработчиков, кому отводится дополнительная роль «владельца продукта» или «эксперта в предметной области», чтобы разработчики могли обращаться к нему с вопросами и, возможно, периодически встречаться, и его вряд ли можно считать полноценным членом команды.

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

Источник: https://ardalis.com/how-software-developers-fail/

День 2648. #ProjectManagement
Как Проваливаются Разработчики ПО. Продолжение
Начало

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

Агенты хорошо умеют создавать вещи неправильно
ИИ-агенты могут быстро генерировать большие объёмы неверного кода:
- Вносить скрытые уязвимости безопасности, которые трудно обнаружить при проверке кода;
- Писать код, который выглядит корректно, но имеет ошибки в крайних случаях;
- Исполнять заявленные требования, игнорируя подразумеваемые ограничения;
- Уверенно выдавать некорректные результаты («галлюцинации»).
Преимущество ИИ-агентов в скорости означает, что если контроль качества отсутствует, вы можете накопить гораздо больше технического долга и гораздо больше ошибок за то же время. Как никогда необходимы тесты, проверка кода (человеческая и автоматизированная) и надёжные конвейеры CI/CD. Быстрая поставка — это преимущество только в том случае, если то, что вы выпускаете, работает.

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

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

Поэтому навыки, помогающие командам создавать правильный продукт, важны как никогда:
1. Чёткие требования и пользовательские истории. Большинство агентов созданы для того, чтобы продолжать работу, пока не почувствуют, что решили проблему. Если у них нет всех деталей, они будут гадать. Так же, как часто делают люди, но без человеческого суждения и с гораздо большей скоростью.

2. Постоянная обратная связь от заинтересованных сторон. Агенты не могут присутствовать на митингах. Людям по-прежнему необходимо собирать и анализировать обратную связь и корректировать направление.

3. Экспертные знания в предметной области. Понимание того, почему необходима та или иная функция, помогает выявлять несоответствия до того, как они будут заложены в тысячи строк сгенерированного кода.

4. Продуктовое мышление. Способность задавать вопрос «Стоит ли вообще это делать?» — это (сегодня) уникальный человеческий навык, и его ценность постоянно растёт.

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

Источник: https://ardalis.com/how-software-developers-fail/

День 2649. #ProjectManagement
Как Проваливаются Разработчики ПО. Окончание
Начало
Продолжение

Эффект накопления
Стоимость создания неправильного продукта людьми ограничена скоростью человека. Команда за спринт может создать 10-15 функций. С ИИ-агентами та же команда теперь может создавать 10-15 функций в день. Если эти функции неверны, потери — и количество необходимых исправлений — кратно увеличиваются. Хуже того, большая кодовая база, полная неправильных функций, создает накопительную сложность: будущим агентам (и людям) придётся обходить все ошибки, которые были допущены. Агенты отлично следуют существующим шаблонам: большая кодовая база, полная неправильных функций, будет использована в качестве модели для следующей функции. Преимущество мощности ИИ-агентов делает их опасными, когда они делают не то.

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

1. Вкладывайте значительные усилия в требования и спецификации. Чем яснее и точнее входные данные для ИИ-агентов, тем лучше результаты. Расплывчатые требования, которые разработчик-человек мог бы разумно интерпретировать, будут реализованы агентом буквально — или, что ещё хуже, изобретательно.

2. Автоматизируйте контрольные точки качества. Код, сгенерированный ИИ, нуждается в автоматизированных тестах, проверке синтаксиса, сканировании безопасности и других проверках качества. Эти контрольные точки становятся основной защитой от ошибок при масштабировании. Их также гораздо проще создать с помощью ИИ-агентов, поэтому важно настроить их с самого начала.

3. Держите людей в курсе решений по продукту. Агенты могут ускорить выполнение, но они не могут заменить суждение о том, что нужно создавать. Менеджеры по продуктам, архитекторы и старшие разработчики должны активно участвовать в определении и проверке направления развития.

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

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

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

Итого
Разработчики и команды, которые преуспеют в эпоху ИИ-агентов, будут не просто теми, кто внедряет агентов раньше всех или наиболее агрессивно. Они будут теми, кто сочетает скорость ИИ с рассудительностью, знаниями в предметной области и ориентацией на клиента, что гарантирует создание правильного продукта правильным способом.

Быстрое движение имеет значение только в том случае, если вы движетесь в правильном направлении. Как гласит классическая цитата: «Мы заблудились, зато мы всех опережаем!»

Источник: https://ardalis.com/how-software-developers-fail/