Какие ключевые свойства проекта при его выборе

Ключевые свойства проекта при его выборе

Когда Java Developer выбирает проект для работы, нужно оценить много факторов — от технического стека до качества кода и перспектив развития. Вот что должен анализировать профессиональный разработчик.

1. Качество архитектуры

Задача: Понять, построен ли проект на здоровой основе

Индикаторы хорошей архитектуры:

// ✅ Слоистая архитектура (Layered Architecture)
// domain/ → application/ → infrastructure/ → presentation/

// domain/ — бизнес-логика, независима от фреймворков
public class UserService {
    private final UserRepository repository;
    
    public void createUser(CreateUserRequest request) {
        User user = new User(request.getName(), request.getEmail());
        repository.save(user);
    }
}

// application/ — use cases
@Service
public class CreateUserUseCase {
    private final UserService userService;
    
    public UserDTO execute(CreateUserRequest request) {
        userService.createUser(request);
        return new UserDTO(...);
    }
}

// infrastructure/ — базы данных, API клиенты
@Repository
public class JpaUserRepository implements UserRepository {
    @Autowired
    private JpaUserEntity jpaUserEntity;
    
    @Override
    public void save(User user) {
        // Сохранение в БД
    }
}

// presentation/ — HTTP контроллеры
@RestController
@RequestMapping("/api/users")
public class UserController {
    @Autowired
    private CreateUserUseCase createUserUseCase;
    
    @PostMapping
    public ResponseEntity<UserDTO> create(@RequestBody CreateUserRequest request) {
        return ResponseEntity.ok(createUserUseCase.execute(request));
    }
}

Вопросы для оценки:

• Следует ли проект SOLID принципам?
• Зависимости только вниз по слоям? (Нет обратных зависимостей)
• Используется ли Dependency Injection?
• Есть ли четкое разделение ответственности?
• Domain layer полностью независим от Spring/Hibernate?

2. Покрытие тестами (Test Coverage)

Задача: Убедиться, что проект поддерживаемый

Минимальные требования:

• Unit тесты: 70-80% покрытие
• Integration тесты: критические flow'ы
• E2E тесты: key user journeys

// Проверить покрытие
// mvn clean verify jacoco:report
// target/site/jacoco/index.html

// ✅ Хороший тест
@Test
public void testCreateUserWithValidData() {
    // Arrange
    CreateUserRequest request = new CreateUserRequest("john@example.com", "John");
    
    // Act
    UserDTO result = createUserUseCase.execute(request);
    
    // Assert
    assertNotNull(result);
    assertEquals("john@example.com", result.getEmail());
    assertTrue(userRepository.findByEmail("john@example.com").isPresent());
}

// ❌ Плохой тест (не проверяет важное)
@Test
public void testUserExists() {
    User user = new User();
    assertTrue(user != null);
}

Как проверить перед выбором проекта:

# Посмотреть покрытие
cd /path/to/project
mvn clean verify
open target/site/jacoco/index.html

# Количество тестов
find . -name "*Test.java" -o -name "*Tests.java" | wc -l

# Ratio тестов к production коду
find src/main -name "*.java" | wc -l
find src/test -name "*.java" | wc -l

3. Зависимости и их версии

Задача: Убедиться, что проект на актуальных версиях

<!-- ✅ Хорошо: актуальные версии -->
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
    <version>3.2.0</version>  <!-- Latest LTS -->
</dependency>

<dependency>
    <groupId>org.postgresql</groupId>
    <artifactId>postgresql</artifactId>
    <version>42.6.0</version>
</dependency>

<!-- ❌ Плохо: устаревшие версии -->
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
    <version>1.5.0</version>  <!-- Поддержка закончилась в 2018 году!
</dependency>

Проверить уязвимости:

# OWASP Dependency Check
mvn dependency-check:check

# Проверить в pom.xml
mvn dependency:tree

Риски с версиями:

• Устаревшие версии = нет security patches
• Новые версии = могут быть нестабильны (выбирать LTS)
• Конфликты между зависимостями

4. Документация

Задача: Понять, документирован ли проект

Хорошая документация содержит:

README.md
  - Описание проекта
  - Требования (Java версия, БД)
  - Инструкции по запуску (make run, docker-compose up)
  - API документация (Swagger, OpenAPI)
  - Примеры использования

docs/
  - Architecture Decision Records (ADRs)
  - Database schema
  - API endpoints
  - Setup guide
  - Contributing guide

Признаки плохой документации:

• README из одной строки
• Комментарии в коде являются единственной документацией
• Никто не знает, как запустить проект
• Архитектурные решения не задокументированы

5. CI/CD pipeline

Задача: Убедиться, что проект автоматизирован

# ✅ Хороший CI/CD (GitHub Actions)
name: Build & Test

on: [push, pull_request]

jobs:
  build:
    runs-on: ubuntu-latest
    
    steps:
      - uses: actions/checkout@v3
      
      - name: Set up JDK
        uses: actions/setup-java@v3
        with:
          java-version: '21'
      
      - name: Lint
        run: mvn spotbugs:check pmd:check
      
      - name: Build
        run: mvn clean package
      
      - name: Test
        run: mvn test jacoco:report
      
      - name: Deploy
        if: github.ref == 'refs/heads/main'
        run: ./deploy.sh

Проверяемые элементы:

• Тесты запускаются автоматически
• Линтинг проверяется перед merge
• Build артефакты создаются
• Security checks (SAST)
• Coverage отчеты

6. Код смелл (Code Smells)

Задача: Выявить признаки плохого кода

// ❌ Code smells

// Gigantic class (более 500 строк)
public class UserService {
    // TODO: 50+ методов
    // TODO: 10+ зависимостей
}

// Feature Envy (методу нужно слишком много информации о другом объекте)
public void updateUser(User user) {
    user.setName("new name");
    user.setEmail("new@example.com");
    user.setPhone("123-456");
    // Лучше: user.update(new UserData(...))
}

// Long Parameter List
public void createOrder(String name, String email, String phone, 
                        String address, String city, String zipcode,
                        String cardNumber, String cvv, LocalDate expires) {
    // Слишком много параметров! Использовать DTO
}

// Duplicated Code
public void logError(String message) {
    System.err.println("[ERROR] " + message);
}
public void logWarning(String message) {
    System.err.println("[WARN] " + message);
}
// Лучше использовать логгер

// Magic Numbers
public void validateAge(int age) {
    if (age > 18) {  // Что это за 18?
        // ...
    }
}

Как проверить:

# SonarQube анализ
mvn sonar:sonar

# PMD для code smells
mvn pmd:check

# SpotBugs для потенциальных ошибок
mvn spotbugs:check

7. Производительность и масштабируемость

Задача: Убедиться, что архитектура готова к росту

Вопросы для оценки:

// Есть ли caching?
@Cacheable("users")
public User findById(Long id) {
    return userRepository.findById(id);
}

// Есть ли индексы в БД?
@Entity
@Table(indexes = @Index(columnList = "email"))
public class User { ... }

// Есть ли пагинация для больших результатов?
public Page<User> findAll(Pageable pageable) {
    return userRepository.findAll(pageable);
}

// Используется ли асинхронность где нужна?
@Async
public CompletableFuture<String> generateReport() {
    // Long-running operation
}

// Есть ли микросервисная архитектура для масштабирования?
// Spring Cloud, Service Discovery, Load Balancing

8. Team culture и процессы

Задача: Убедиться, что команда здоровая

Индикаторы здоровой команды:

• Code Review практика
• Pair Programming
• Knowledge sharing
• Отсутствие героев (один человек знает всё)
• Open communication
• Continuous learning

Как проверить в репозитории:

# Есть ли Code Review (PR reviews)?
git log --all --grep="Reviewed-by" | wc -l

# Кто наиболее активно коммитит? (опасно если один человек)
git log --pretty=format:%an | sort | uniq -c | sort -rn

# Регулярны ли коммиты? (признак активной разработки)
git log --oneline | head -20

9. Dependency Management

Задача: Убедиться, что зависимостей правильное количество

# Слишком много зависимостей (>50) = сложность
mvn dependency:tree | wc -l

# Есть ли конфликты версий?
mvn dependency:tree

# Есть ли исключения (exclusions)?
# Это признак проблем с версионированием

10. Business metrics

Задача: Понять жизнеспособность проекта

• Стабильность: Есть ли срывы SLA?
• Используемость: Сколько пользователей?
• ROI: Приносит ли проект доход?
• Стратегия: Компания инвестирует в проект?

Checklist при выборе проекта

✅ Архитектура:
  - Слоистая архитектура
  - SOLID принципы
  - Dependency Injection
  - Слабая связанность (low coupling)

✅ Тесты:
  - Coverage > 70%
  - Unit + Integration + E2E
  - CI/CD с автоматическими тестами

✅ Code Quality:
  - SonarQube / PMD clean
  - Нет code smells
  - Понятные имена переменных
  - Документированный код

✅ Зависимости:
  - Актуальные версии (LTS)
  - Нет уязвимостей
  - Управляемое количество

✅ Документация:
  - README с инструкциями
  - Architecture docs
  - API документация
  - Решения задокументированы

✅ DevOps:
  - Работающий CI/CD
  - Автоматизированный deploy
  - Monitoring & Logging
  - Disaster recovery plan

✅ Team:
  - Code Review практика
  - Несколько опытных разработчиков
  - Knowledge sharing
  - Четкий onboarding

✅ Business:
  - Стабильное финансирование
  - Четкая стратегия
  - Растущий или стабильный
  - Хорошие перспективы

На собеседовании

Покажи, что ты выбираешь проекты осознанно, учитывая:

1. Технические факторы — архитектура, тесты, качество
2. Практические факторы — документация, CI/CD, зависимости
3. Человеческие факторы — команда, культура, обучение
4. Бизнес факторы — ROI, стратегия, стабильность

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