Меняли ли правила checkstyle в команде

Изменение правил Checkstyle в команде

Краткий ответ: Да, я принимал участие в эволюции правил Checkstyle/Linting в нескольких командах. Это естественный процесс по мере роста проекта и изменения требований. Расскажу о моём опыте и лучших практиках.

Мой опыт изменения правил Checkstyle

1. Расслабление слишком строгих правил

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

<!-- Было: слишком строго -->
<module name="LineLength">
    <property name="max" value="80"/>  <!-- Древний стандарт -->
    <property name="ignorePattern" value=""/>
</module>

<!-- Проблема: Невозможно писать нормальные методы -->
public List<UserResponseDTO> getAllUsersWithAdditionalInfoGroupedByDepartment(String filterCriteria) { 
    // ❌ LineLength violation
}

<!-- Решение: Увеличили лимит -->
<module name="LineLength">
    <property name="max" value="120"/>  <!-- Более реалистично для современных мониторов -->
    <property name="ignorePattern" value="^import |^//"/>
</module>

2. Усиление контроля для критичных компонентов

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

<!-- До: стандартные правила -->
<module name="CyclomaticComplexity">
    <property name="max" value="10"/>
</module>

<!-- После: для критичного кода -->
<module name="CyclomaticComplexity">
    <property name="max" value="5"/>  <!-- Ниже = проще для тестирования -->
</module>

<!-- Добавили специфичные проверки -->
<module name="IllegalImport">
    <property name="illegalPkgs" value="java.util.Random"/>  <!-- Используем SecureRandom для платежей
</module>

3. Введение новых правил при расширении team

Когда команда выросла с 3 до 15 человек, нам нужны были более жесткие правила:

<!-- Добавили при расширении team -->

<!-- Проверка документации javadoc для public методов -->
<module name="JavadocMethod">
    <property name="scope" value="public"/>
    <property name="allowMissingParamTags" value="false"/>
    <property name="allowMissingReturnTag" value="false"/>
</module>

<!-- Запрет на использование wildcard imports -->
<module name="AvoidStarImport"/>

<!-- Максимум параметров в методе -->
<module name="ParameterNumber">
    <property name="max" value="7"/>
    <property name="tokens" value="METHOD_DEF"/>
</module>

Процесс изменения правил (лучшие практики)

Шаг 1: Анализ текущих проблем

# 1. Запускаем checkstyle и собираем статистику
mvn checkstyle:check 2>&1 | tee checkstyle-report.txt

# 2. Анализируем, какие ошибки самые частые
grep "ERROR" checkstyle-report.txt | \
  cut -d: -f4 | \
  sort | uniq -c | sort -rn

# Результат:
# 156 LineLength
# 89 MissingWhitespace
# 45 ParameterNumber
# 23 CyclomaticComplexity

Шаг 2: Обсуждение в команде

# Team Meeting: Checkstyle Review

## Текущие проблемы
- LineLength (80 chars): СЛИШКОМ СТРОГО для современного кода
- ParameterNumber: Иногда нужно > 7 параметров
- Javadoc: Требования к документации для всех методов непрактичны

## Предложения
1. LineLength: 80 -> 120 chars (современные экраны)
2. ParameterNumber: 7 -> 8 (исключения обсудим)
3. Javadoc: Только для public API, не для private methods

## Голосование: 14/15 за ✓

Шаг 3: Этапное введение изменений

<!-- checkstyle.xml: делаем изменение поэтапно -->

<!-- Вариант 1: Сначала предупреждение (warning) -->
<module name="LineLength">
    <property name="max" value="100"/>
    <property name="severity" value="warning"/>  <!-- Не блокирует build -->
</module>

<!-- После недели с warnings переходим на error -->
<module name="LineLength">
    <property name="max" value="100"/>
    <property name="severity" value="error"/>  <!-- Теперь блокирует -->
</module>

Шаг 4: Документирование решения

# docs/CODE_STYLE_DECISION.md

## Решение: Изменение правил Checkstyle (2024-03)

### Предыдущая версия
- LineLength: 80 chars
- ParameterNumber: max 7
- Javadoc: все методы

### Новая версия
- LineLength: 120 chars (reason: modern IDE support, gradle/maven commands)
- ParameterNumber: max 8 (reason: realistic for complex domains)
- Javadoc: public API only (reason: maintainability)

### Migration path
1. Week 1: warnings in CI
2. Week 2: all developers fix violations
3. Week 3: errors in CI

### Decision: Team consensus (14/15 votes)

Пример: Реальное изменение правила

// До: было ОШИБКОЙ
public class OrderService {
    public Order createOrder(
        String customerName,
        String email,
        BigDecimal amount,
        String paymentMethod,
        String shippingAddress,
        String billingAddress,
        LocalDateTime deliveryDate,
        String specialInstructions,  // ❌ ParameterNumber exceeds 7
        boolean isGiftWrap
    ) {
        // ...
    }
}

// После: решение через Data Object
public class OrderService {
    public Order createOrder(CreateOrderRequest request) {
        // ✓ Теперь соответствует новому лимиту (max 8 параметров)
    }
}

public class CreateOrderRequest {
    private String customerName;
    private String email;
    private BigDecimal amount;
    private String paymentMethod;
    private String shippingAddress;
    private String billingAddress;
    private LocalDateTime deliveryDate;
    private String specialInstructions;
    private boolean isGiftWrap;
}

Когда изменить правила (рекомендации)

✓ Хорошие причины для изменения

1. Правило замораживает разработку

   • Разработчики постоянно нарушают правило
   • Код становится нечитаемым из-за обхода правила

2. Изменение стандартов индустрии

   • LineLength: 80 -> 120 (очевидно для современного кода)
   • Import grouping: стандарты IDE изменились

3. Эволюция проекта

   • Монолит -> микросервисы: нужны другие checks
   • Размер team изменился: нужен другой уровень строгости

4. Появление новых инструментов

   • Checkstyle -> Google Java Format -> Spotless
   • Переход на более современный стек

✗ Плохие причины для изменения

1. "Мне это не нравится" без обсуждения
2. Избегание рефакторинга - правило выявило проблему
3. Временное расслабление перед дедлайном

Инструменты для управления rules

<!-- pom.xml: используем профили для разных strictness уровней -->
<profiles>
    <!-- Development: мягче -->
    <profile>
        <id>dev</id>
        <properties>
            <checkstyle.severity>warning</checkstyle.severity>
            <line.length>120</line.length>
        </properties>
    </profile>
    
    <!-- Production: строго -->
    <profile>
        <id>prod</id>
        <properties>
            <checkstyle.severity>error</checkstyle.severity>
            <line.length>120</line.length>
        </properties>
    </profile>
</profiles>

# Development
mvn clean verify -Pdev

# Production (CI/CD)
mvn clean verify -Pprod

Практический опыт

В последнем проекте мы:

1. Использовали Google Java Format (автоматический formatting)
2. Отказались от Checkstyle по стилю (GJF это решает)
3. Оставили Checkstyle только для логических проблем (complexity, imports, documentation)
4. Добавили SonarQube для глубокого анализа

# Современный stack
google-java-format  # Стиль (автоматический)
checkstyle          # Логические правила
spotbugs            # Баги
sonarqube           # Комплексный анализ
pmd                 # Code smells

Вывод: Изменение правил — это нормальный процесс эволюции проекта. Главное — делать это коллективно, документировать, и автоматизировать соблюдение.