Какие ожидания от программной инженерии

Мои ожидания от программной инженерии как дисциплины

С 10+ лет опыта в Java разработке я сформировал ясное понимание того, что должна представлять собой программная инженерия. Это не просто написание кода — это наука и искусство создания надёжных, масштабируемых и поддерживаемых систем. Вот мои ожидания и убеждения.

1. Научный подход вместо хаоса

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

// ❌ Подход "как повезёт"
public class Service {
    private List<Data> data = new ArrayList<>();
    private static Random random = new Random();
    
    public void process() {
        // Обрабатываем данные случайным образом?
        // Не понятно, что произойдёт при нагрузке
        // Нет тестов, нет гарантий
    }
}

// ✓ Инженерный подход
public class Service {
    private final DataRepository repository;  // Инъекция
    private final Logger logger;               // Логирование
    
    public void process(List<Data> items) throws DataProcessingException {
        // 1. Валидация входных данных
        validateInput(items);
        
        // 2. Обработка с явной обработкой ошибок
        for (Data item : items) {
            try {
                processItem(item);
            } catch (Exception e) {
                logger.error("Failed to process item: {}", item.getId(), e);
                // Либо retry, либо продолжаем
            }
        }
        
        // 3. Гарантированное завершение и логирование
        logger.info("Processing completed successfully");
    }
}

2. Тестируемость как обязательное требование

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

// ❌ Нетестируемый код
public class UserService {
    public void createUser(String name) {
        // Прямое обращение к БД
        Connection conn = DriverManager.getConnection("jdbc:...");
        // ...
        sendEmail(name); // Отправляем реальное письмо
    }
}
// Как тестировать? Только с реальной БД и почтой!

// ✓ Тестируемый код (Dependency Injection)
public class UserService {
    private final UserRepository repository;
    private final EmailService emailService;
    
    public UserService(UserRepository repository, EmailService emailService) {
        this.repository = repository;
        this.emailService = emailService;
    }
    
    public void createUser(String name) throws ValidationException {
        validateName(name);
        User user = repository.save(new User(name));
        emailService.sendWelcomeEmail(user.getEmail());
    }
}

// Легко тестировать
@Test
void shouldCreateUserAndSendEmail() {
    UserRepository mockRepository = mock(UserRepository.class);
    EmailService mockEmailService = mock(EmailService.class);
    
    UserService service = new UserService(mockRepository, mockEmailService);
    service.createUser("John");
    
    verify(mockRepository).save(any(User.class));
    verify(mockEmailService).sendWelcomeEmail(any());
}

3. Качество кода и архитектура

Ожидание: Код должен быть SOLID, DRY, KISS. Архитектура должна быть чистой и слоистой.

// Правильная архитектура: Domain → Application → Infrastructure

// Domain Layer (бизнес-логика)
public class User {
    private String email;
    private String passwordHash;
    
    public void changePassword(String newPassword) throws PasswordTooWeakException {
        if (newPassword.length() < 8) {
            throw new PasswordTooWeakException();
        }
        this.passwordHash = hash(newPassword);
    }
}

// Application Layer (use cases)
@Service
public class RegisterUserUseCase {
    private final UserRepository repository;
    private final EmailService emailService;
    
    public void execute(RegisterUserRequest request) {
        User user = new User(request.getEmail());
        user.changePassword(request.getPassword());
        repository.save(user);
        emailService.sendConfirmation(user.getEmail());
    }
}

// Infrastructure Layer (реализация)
@Repository
public class JpaUserRepository implements UserRepository {
    private final JpaRepository<UserEntity, Long> jpa;
    
    @Override
    public void save(User user) {
        jpa.save(UserEntity.from(user));
    }
}

// Presentation Layer (API)
@RestController
@RequestMapping("/api/v1/auth")
public class AuthController {
    private final RegisterUserUseCase registerUseCase;
    
    @PostMapping("/register")
    public void register(@RequestBody RegisterUserRequest request) {
        registerUseCase.execute(request);
    }
}

4. Документирование решений

Ожидание: Архитектурные решения должны быть задокументированы с обоснованием (ADR — Architecture Decision Records).

# ADR-001: Использование PostgreSQL вместо MongoDB

## Контекст
Нужно выбрать БД для нового сервиса с большим количеством реляционных данных.

## Решение
Выбрали PostgreSQL.

## Обоснование
- ACID гарантии важны для нашего domain
- Сложные joins требуют SQL
- MongoDB усложнит миграции в будущем

## Последствия
- Нужно больше оперативной памяти
- Развертывание проще (образцы конфигов)
- Команда лучше знает PostgreSQL

5. Мониторинг и наблюдаемость

Ожидание: Код должен быть observability-first. Мониторинг — не надстройка, а часть дизайна.

// ✓ Правильный подход
@Service
public class PaymentService {
    private static final MeterRegistry meterRegistry = new SimpleMeterRegistry();
    private static final Logger logger = LoggerFactory.getLogger(PaymentService.class);
    
    public void processPayment(Payment payment) {
        long startTime = System.currentTimeMillis();
        
        try {
            logger.info("Processing payment {} for user {}", 
                payment.getId(), payment.getUserId());
            
            validatePayment(payment);
            chargeCard(payment);
            savePayment(payment);
            
            long duration = System.currentTimeMillis() - startTime;
            meterRegistry.timer("payment.processing.time").record(duration, TimeUnit.MILLISECONDS);
            meterRegistry.counter("payment.success").increment();
            
            logger.info("Payment {} processed successfully in {}ms", 
                payment.getId(), duration);
            
        } catch (InsufficientFundsException e) {
            meterRegistry.counter("payment.failed.insufficient_funds").increment();
            logger.warn("Insufficient funds for payment {}", payment.getId());
            throw e;
            
        } catch (Exception e) {
            meterRegistry.counter("payment.failed.unknown").increment();
            logger.error("Payment {} failed with error", payment.getId(), e);
            // Retry logic
            throw new PaymentProcessingException(e);
        }
    }
}

6. Обработка ошибок как первоклассный гражданин

Ожидание: Обработка ошибок — не afterthought, а планируется с начала проектирования.

// ❌ Игнорирование ошибок
public void fetchData() {
    try {
        // какой-то код
    } catch (Exception e) {
        e.printStackTrace(); // Плохо!
    }
}

// ✓ Правильная обработка
public void fetchData() throws DataFetchException {
    try {
        // попытка загрузить данные
    } catch (TimeoutException e) {
        // Специфичная обработка
        logger.warn("Timeout fetching data, will retry");
        retryWithBackoff();
    } catch (ConnectionException e) {
        // Специфичная обработка
        logger.error("Cannot connect to data source", e);
        throw new DataFetchException("Service unavailable", e);
    } catch (Exception e) {
        // Непредвиденная ошибка
        logger.error("Unexpected error while fetching data", e);
        throw new DataFetchException("Internal error", e);
    }
}

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

Ожидание: Performance должна быть частью спецификации, не бонусом.

// ✓ Тестирование производительности
@BenchmarkMode(Mode.Throughput)
@Fork(2)
@State(Scope.Benchmark)
public class UserServiceBenchmark {
    private UserService service;
    
    @Benchmark
    public User findUserById() {
        return service.findUserById(1L);
    }
    
    @Benchmark
    public void createUser() {
        service.createUser(new CreateUserRequest("test@example.com"));
    }
}

// SLA: findUserById должно работать за < 50ms в 99 percentile
// createUser должна обрабатывать >= 1000 requests/sec

8. Безопасность по умолчанию

Ожидание: Security должна быть в core, не слой сверху.

// ✓ Подход
@RestController
public class UserController {
    
    @GetMapping("/users/{id}")
    @PreAuthorize("hasRole(ADMIN) or #id == authentication.principal.id")
    public UserDTO getUser(@PathVariable Long id) {
        // Явная проверка прав
        User user = userService.findById(id);
        return userMapper.toDTO(user);
    }
    
    @PostMapping("/users")
    @RateLimiter(limit = 10, period = "1m") // Защита от spam
    public UserDTO createUser(@Valid @RequestBody CreateUserRequest request) {
        // Валидация входных данных
        return userService.create(request);
    }
}

9. Масштабируемость как архитектурное требование

Ожидание: Архитектура должна позволять масштабирование без переписания кода.

// ✓ Event-Driven Architecture для масштабирования
@Service
public class OrderService {
    private final OrderRepository repository;
    private final ApplicationEventPublisher eventPublisher;
    
    public Order createOrder(CreateOrderRequest request) {
        Order order = repository.save(new Order(request));
        
        // Событие → другие сервисы могут слушать
        eventPublisher.publishEvent(new OrderCreatedEvent(order));
        
        return order;
    }
}

// Другой сервис может слушать независимо
@Service
public class NotificationService {
    @EventListener
    public void onOrderCreated(OrderCreatedEvent event) {
        sendNotificationToUser(event.getOrder());
    }
}

// Можно добавить другие слушатели без изменения OrderService

10. Практический коллаборативный процесс

Ожидание: Разработка должна быть итеративная с обратной связью.

1. Планирование (requirements, архитектура)
2. Design Review (обсуждение дизайна с командой)
3. Разработка (TDD)
4. Code Review (все изменения проходят review)
5. Тестирование (unit, integration, e2e)
6. Deploy staging (тестирование реальных условиях)
7. Production deploy (с мониторингом)
8. Retrospective (обсуждение, что нужно улучшить)

Итоговый Manifesto программной инженерии

✓ Качество над скоростью (в долгосрочной перспективе)
✓ Тестируемость обязательна
✓ Архитектура чистая и слоистая
✓ Мониторинг встроен в код
✓ Ошибки обрабатываются явно
✓ Документация актуальна
✓ Security by default
✓ Performance measured
✓ Масштабируемость продумана
✓ Коллаборация над одиночными решениями

✗ Хак вместо решения
✗ Нет тестов
✗ Копипаста кода
✗ Хардкод значений
✗ Игнорирование ошибок
✗ Разработка "в темноте" без мониторинга
✗ Переоптимизация на ранних стадиях
✗ Большие PR без review
✗ Быстрый deploy без мониторинга

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