sa-lessons/modules/module9/theory.md

Модуль 9: Управление командой и процессы

Содержание модуля

1. Техническое лидерство
2. Управление архитектурными процессами
3. Agile и архитектура
4. DevOps культура
5. Code Review и архитектурные ревью
6. Стандарты кодирования и инструменты
7. Управление техническим долгом
8. Коммуникация и презентации

---

Техническое лидерство

Роль технического лидера

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

Обязанности технического лидера

1. Техническое планирование

# Техническое планирование

## Архитектурное планирование
- Определение технической стратегии
- Выбор технологий и инструментов
- Планирование архитектурных изменений
- Оценка технических рисков

## Планирование разработки
- Разбиение задач на подзадачи
- Оценка сложности и времени
- Планирование зависимостей
- Координация между командами

2. Наставничество и развитие команды

Технический пример - Advanced Team Management System:

// Team Management Service
@Service
@Transactional
public class TeamManagementService {
    
    @Autowired
    private DeveloperRepository developerRepository;
    
    @Autowired
    private ProjectRepository projectRepository;
    
    @Autowired
    private SkillAssessmentService skillAssessmentService;
    
    // Создание команды для проекта
    public Team createTeamForProject(Long projectId, TeamCreationRequest request) {
        Project project = projectRepository.findById(projectId)
            .orElseThrow(() -> new ProjectNotFoundException("Project not found"));
        
        // Анализ требований проекта
        List<SkillRequirement> requirements = analyzeProjectRequirements(project);
        
        // Подбор команды
        List<Developer> teamMembers = selectTeamMembers(requirements, request.getTeamSize());
        
        // Создание команды
        Team team = Team.builder()
            .name(request.getTeamName())
            .project(project)
            .members(teamMembers)
            .lead(selectTeamLead(teamMembers))
            .createdDate(LocalDateTime.now())
            .status(TeamStatus.FORMING)
            .build();
        
        return teamRepository.save(team);
    }
    
    // Оценка навыков команды
    public TeamSkillAssessment assessTeamSkills(Long teamId) {
        Team team = teamRepository.findById(teamId)
            .orElseThrow(() -> new TeamNotFoundException("Team not found"));
        
        Map<String, SkillLevel> teamSkills = new HashMap<>();
        
        for (Developer developer : team.getMembers()) {
            Map<String, SkillLevel> developerSkills = skillAssessmentService.assessDeveloperSkills(developer.getId());
            
            for (Map.Entry<String, SkillLevel> entry : developerSkills.entrySet()) {
                String skill = entry.getKey();
                SkillLevel level = entry.getValue();
                
                // Агрегируем навыки команды
                teamSkills.merge(skill, level, (existing, newLevel) -> 
                    existing.getLevel() > newLevel.getLevel() ? existing : newLevel);
            }
        }
        
        return TeamSkillAssessment.builder()
            .teamId(teamId)
            .teamSkills(teamSkills)
            .assessmentDate(LocalDateTime.now())
            .build();
    }
    
    private List<SkillRequirement> analyzeProjectRequirements(Project project) {
        List<String> technologies = project.getTechnologies();
        List<SkillRequirement> requirements = new ArrayList<>();
        
        for (String technology : technologies) {
            requirements.add(SkillRequirement.builder()
                .skill(technology)
                .requiredLevel(SkillLevel.INTERMEDIATE)
                .requiredDevelopers(1)
                .priority(Priority.HIGH)
                .build());
        }
        
        return requirements;
    }
    
    private List<Developer> selectTeamMembers(List<SkillRequirement> requirements, int teamSize) {
        List<Developer> availableDevelopers = developerRepository.findAvailableDevelopers();
        
        return availableDevelopers.stream()
            .limit(teamSize)
            .collect(Collectors.toList());
    }
    
    private Developer selectTeamLead(List<Developer> teamMembers) {
        return teamMembers.stream()
            .max(Comparator.comparing(Developer::getExperience))
            .orElse(teamMembers.get(0));
    }
}

// Code Review Management System
@Service
public class CodeReviewManagementService {
    
    @Autowired
    private CodeReviewRepository codeReviewRepository;
    
    @Autowired
    private DeveloperRepository developerRepository;
    
    // Создание Code Review
    public CodeReview createCodeReview(CreateCodeReviewRequest request) {
        Developer author = developerRepository.findById(request.getAuthorId())
            .orElseThrow(() -> new DeveloperNotFoundException("Developer not found"));
        
        // Подбор ревьюеров
        List<Developer> reviewers = selectReviewers(author, request.getTechnologies());
        
        // Создание Code Review
        CodeReview review = CodeReview.builder()
            .title(request.getTitle())
            .description(request.getDescription())
            .author(author)
            .reviewers(reviewers)
            .pullRequestId(request.getPullRequestId())
            .status(CodeReviewStatus.PENDING)
            .createdDate(LocalDateTime.now())
            .build();
        
        return codeReviewRepository.save(review);
    }
    
    // Подбор ревьюеров на основе экспертизы
    private List<Developer> selectReviewers(Developer author, List<String> technologies) {
        List<Developer> availableReviewers = developerRepository.findAvailableReviewers();
        
        return availableReviewers.stream()
            .filter(reviewer -> !reviewer.equals(author))
            .filter(reviewer -> hasRequiredSkills(reviewer, technologies))
            .limit(3)
            .collect(Collectors.toList());
    }
    
    private boolean hasRequiredSkills(Developer developer, List<String> technologies) {
        Map<String, SkillLevel> skills = skillAssessmentService.assessDeveloperSkills(developer.getId());
        
        return technologies.stream()
            .allMatch(tech -> skills.containsKey(tech) && 
                skills.get(tech).getLevel() >= SkillLevel.INTERMEDIATE.getLevel());
    }
}

3. Принятие технических решений

# Процесс принятия технических решений

## 1. Анализ проблемы
- Понимание бизнес-требований
- Анализ технических ограничений
- Оценка влияния на существующую систему

## 2. Исследование решений
- Поиск альтернативных подходов
- Анализ преимуществ и недостатков
- Изучение лучших практик

## 3. Принятие решения
- Консультация с командой
- Документирование решения (ADR)
- Коммуникация решения стейкхолдерам

## 4. Реализация и мониторинг
- Планирование реализации
- Отслеживание прогресса
- Оценка результатов

Стили технического лидерства

1. Авторитарный лидер

Характеристики:

• Принимает решения единолично
• Четкие инструкции команде
• Быстрые решения

Когда использовать:

• Критические ситуации
• Опытная команда
• Четкие технические требования

2. Демократический лидер

Характеристики:

• Совместное принятие решений
• Учет мнения команды
• Коллективная ответственность

Когда использовать:

• Сложные технические задачи
• Инновационные проекты
• Развитие команды

3. Коучинговый лидер

Характеристики:

• Фокус на развитии команды
• Обучение и наставничество
• Долгосрочное развитие

Когда использовать:

• Новые члены команды
• Обучение новым технологиям
• Развитие экспертизы

---

Управление архитектурными процессами

Архитектурные процессы

1. Architecture Review Process

# Процесс архитектурного ревью

## Подготовка к ревью
1. **Создание архитектурной диаграммы**
   - C4 Model диаграммы
   - Sequence диаграммы
   - Deployment диаграммы

2. **Подготовка ADR**
   - Описание проблемы
   - Анализ решений
   - Обоснование выбора

3. **Анализ рисков**
   - Технические риски
   - Бизнес-риски
   - Планы митигации

## Проведение ревью
1. **Презентация (30 мин)**
   - Обзор архитектуры
   - Ключевые решения
   - Влияние на систему

2. **Обсуждение (30 мин)**
   - Вопросы и уточнения
   - Альтернативные решения
   - Детали реализации

3. **Принятие решения (15 мин)**
   - Голосование
   - Условия одобрения
   - Следующие шаги

2. Architecture Governance

# Architecture Governance Framework
architecture_governance:
  principles:
    - name: "Technology Standardization"
      description: "Use standardized technologies across the organization"
      enforcement: "Mandatory"
    
    - name: "Security by Design"
      description: "Security must be considered from the beginning"
      enforcement: "Mandatory"
    
    - name: "Scalability"
      description: "Systems must be designed for scalability"
      enforcement: "Recommended"

  review_process:
    triggers:
      - "New system development"
      - "Major system changes"
      - "Technology adoption"
    
    participants:
      - "Solution Architect"
      - "Technical Lead"
      - "Security Architect"
      - "Business Analyst"
    
    criteria:
      - "Alignment with principles"
      - "Technical feasibility"
      - "Business value"
      - "Risk assessment"

  compliance:
    monitoring:
      - "Regular architecture reviews"
      - "Code review checklists"
      - "Automated compliance checks"
    
    reporting:
      - "Monthly compliance reports"
      - "Quarterly architecture health checks"
      - "Annual architecture assessment"

Непрерывная архитектура

1. Architecture as Code

# Architecture Definition
architecture:
  version: "1.0"
  name: "E-commerce Platform"
  
  components:
    - name: "User Service"
      type: "microservice"
      technology: "Java Spring Boot"
      responsibilities:
        - "User management"
        - "Authentication"
        - "Authorization"
      interfaces:
        - "REST API"
        - "Event publishing"
    
    - name: "Order Service"
      type: "microservice"
      technology: "Java Spring Boot"
      responsibilities:
        - "Order processing"
        - "Order state management"
        - "Order history"
      interfaces:
        - "REST API"
        - "Event consumption"
        - "Event publishing"

  relationships:
    - from: "User Service"
      to: "Order Service"
      type: "synchronous"
      protocol: "HTTP/REST"
      purpose: "User validation for orders"
    
    - from: "Order Service"
      to: "Payment Service"
      type: "asynchronous"
      protocol: "Events"
      purpose: "Payment processing"

  quality_attributes:
    - name: "Performance"
      target: "95% of requests < 200ms"
      measurement: "Response time monitoring"
    
    - name: "Availability"
      target: "99.9% uptime"
      measurement: "Uptime monitoring"
    
    - name: "Scalability"
      target: "Handle 10,000 RPS"
      measurement: "Load testing"

2. Architecture Evolution

# Процесс эволюции архитектуры

## 1. Мониторинг архитектуры
- Отслеживание метрик качества
- Анализ технического долга
- Обратная связь от команды

## 2. Идентификация проблем
- Производительность
- Масштабируемость
- Поддерживаемость
- Безопасность

## 3. Планирование изменений
- Приоритизация проблем
- Разработка решений
- Планирование миграции

## 4. Реализация изменений
- Поэтапная миграция
- Тестирование изменений
- Мониторинг результатов

---

Agile и архитектура

Принципы Agile архитектуры

1. Emergent Architecture

Принцип: Архитектура возникает в процессе разработки, а не планируется заранее.

# Emergent Architecture Process

## Итерация 1: MVP
- Простая монолитная архитектура
- Основной функционал
- Быстрый вывод на рынок

## Итерация 2: Масштабирование
- Добавление кэширования
- Оптимизация производительности
- Улучшение пользовательского опыта

## Итерация 3: Микросервисы
- Выделение критических сервисов
- Независимое развертывание
- Улучшение надежности

## Итерация 4: Оптимизация
- Полная микросервисная архитектура
- Автоматизация процессов
- Продвинутый мониторинг

2. Architecture Sprints

# Architecture Sprint Planning

## Sprint 0: Architecture Foundation
- Определение архитектурных принципов
- Выбор технологического стека
- Создание базовой инфраструктуры

## Sprint 1-N: Feature Development
- Разработка функциональности
- Архитектурные рефакторинги
- Улучшение качества кода

## Sprint N+1: Architecture Review
- Анализ архитектуры
- Планирование улучшений
- Техническое планирование

Практики Agile архитектуры

1. Architecture Decision Records in Agile

# ADR в Agile процессе

## Еженедельные ADR ревью
- Обсуждение новых решений
- Обновление существующих ADR
- Планирование архитектурных изменений

## Sprint Planning с ADR
- Учет архитектурных решений в планировании
- Оценка влияния на архитектуру
- Планирование архитектурных задач

## Retrospective с архитектурным фокусом
- Анализ архитектурных проблем
- Планирование улучшений
- Обучение команды

2. Architecture Testing in Agile

// Архитектурные тесты в Agile
@ArchTest
static final ArchRule layeredArchitecture = layeredArchitecture()
    .layer("Controller").definedBy("..controller..")
    .layer("Service").definedBy("..service..")
    .layer("Repository").definedBy("..repository..")
    .whereLayer("Controller").mayNotBeAccessedByAnyLayer()
    .whereLayer("Service").mayOnlyBeAccessedByLayers("Controller")
    .whereLayer("Repository").mayOnlyBeAccessedByLayers("Service");

@ArchTest
static final ArchRule noClassesShouldUseJodaTime = 
    noClasses().should().dependOnClassesThat().belongToAnyOf(DateTime.class);

@ArchTest
static final ArchRule servicesShouldNotDependOnWebLayer = 
    noClasses().that().resideInAPackage("..service..")
        .should().dependOnClassesThat().resideInAPackage("..web..");

---

DevOps культура

Принципы DevOps

1. Collaboration

Принцип: Тесное сотрудничество между разработкой и операциями.

# DevOps Collaboration Framework
collaboration:
  daily_standups:
    participants: ["Developers", "Operations", "QA", "Product"]
    focus: ["Deployment status", "Incident response", "Feature progress"]
  
  shared_responsibilities:
    - "Code quality"
    - "System reliability"
    - "Performance monitoring"
    - "Security"
  
  communication_channels:
    - "Slack channels"
    - "Shared documentation"
    - "Regular meetings"
    - "Incident response procedures"

2. Automation

Принцип: Автоматизация всех повторяющихся процессов.

# CI/CD Pipeline
pipeline:
  stages:
    - name: "Build"
      steps:
        - "Code checkout"
        - "Dependency installation"
        - "Compilation"
        - "Unit tests"
        - "Code quality checks"
    
    - name: "Test"
      steps:
        - "Integration tests"
        - "Performance tests"
        - "Security scans"
        - "Architecture tests"
    
    - name: "Deploy"
      steps:
        - "Build Docker image"
        - "Push to registry"
        - "Deploy to staging"
        - "Smoke tests"
        - "Deploy to production"
        - "Health checks"

3. Monitoring and Feedback

Принцип: Непрерывный мониторинг и обратная связь.

// Monitoring Integration
@Component
public class ApplicationMetrics {
    private final MeterRegistry meterRegistry;
    
    public ApplicationMetrics(MeterRegistry meterRegistry) {
        this.meterRegistry = meterRegistry;
    }
    
    @EventListener
    public void handleOrderCreated(OrderCreatedEvent event) {
        Counter.builder("orders.created")
            .tag("customer_type", event.getCustomerType())
            .register(meterRegistry)
            .increment();
    }
    
    @EventListener
    public void handlePaymentProcessed(PaymentProcessedEvent event) {
        Timer.builder("payment.processing.time")
            .tag("payment_method", event.getPaymentMethod())
            .register(meterRegistry)
            .record(event.getProcessingTime());
    }
}

Практики DevOps

1. Continuous Integration (CI)

Continuous Integration — практика частого слияния кода в общую ветку с автоматической проверкой.

# GitHub Actions CI Pipeline
name: Continuous Integration

on:
  push:
    branches: [ main, develop ]
  pull_request:
    branches: [ main ]

jobs:
  test:
    runs-on: ubuntu-latest
    
    strategy:
      matrix:
        java-version: [11, 17]
        os: [ubuntu-latest, windows-latest, macos-latest]
    
    steps:
    - uses: actions/checkout@v3
    
    - name: Set up JDK ${{ matrix.java-version }}
      uses: actions/setup-java@v3
      with:
        java-version: ${{ matrix.java-version }}
        distribution: 'temurin'
    
    - name: Cache Maven dependencies
      uses: actions/cache@v3
      with:
        path: ~/.m2
        key: ${{ runner.os }}-m2-${{ hashFiles('**/pom.xml') }}
        restore-keys: ${{ runner.os }}-m2
    
    - name: Run tests
      run: mvn clean test
    
    - name: Generate test report
      uses: dorny/test-reporter@v1
      if: success() || failure()
      with:
        name: Maven Tests
        path: target/surefire-reports/*.xml
        reporter: java-junit
    
    - name: Code coverage
      run: mvn jacoco:report
    
    - name: Upload coverage to Codecov
      uses: codecov/codecov-action@v3
      with:
        file: ./target/site/jacoco/jacoco.xml

2. Continuous Deployment (CD)

Continuous Deployment — автоматическое развертывание кода в продакшн после успешного прохождения тестов.

# GitLab CI/CD Pipeline
stages:
  - build
  - test
  - security
  - deploy-staging
  - deploy-production

variables:
  DOCKER_IMAGE: $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
  DOCKER_LATEST: $CI_REGISTRY_IMAGE:latest

build:
  stage: build
  script:
    - docker build -t $DOCKER_IMAGE .
    - docker tag $DOCKER_IMAGE $DOCKER_LATEST
    - docker push $DOCKER_IMAGE
    - docker push $DOCKER_LATEST
  only:
    - main
    - develop

test:
  stage: test
  script:
    - docker run --rm $DOCKER_IMAGE npm test
    - docker run --rm $DOCKER_IMAGE npm run test:e2e
  coverage: '/Lines\s*:\s*(\d+\.\d+)%/'

security:
  stage: security
  script:
    - docker run --rm -v $(pwd):/app $DOCKER_IMAGE npm audit
    - docker run --rm -v $(pwd):/app $DOCKER_IMAGE npm run security:scan
  allow_failure: true

deploy-staging:
  stage: deploy-staging
  script:
    - kubectl set image deployment/app app=$DOCKER_IMAGE
    - kubectl rollout status deployment/app
  environment:
    name: staging
    url: https://staging.example.com
  only:
    - develop

deploy-production:
  stage: deploy-production
  script:
    - kubectl set image deployment/app app=$DOCKER_IMAGE
    - kubectl rollout status deployment/app
  environment:
    name: production
    url: https://example.com
  when: manual
  only:
    - main

3. Blue-Green Deployment

Blue-Green Deployment — стратегия развертывания с двумя идентичными продакшн средами.

# Blue-Green Deployment with Kubernetes
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: app-rollout
spec:
  replicas: 5
  strategy:
    blueGreen:
      activeService: app-active
      previewService: app-preview
      autoPromotionEnabled: false
      scaleDownDelaySeconds: 30
      prePromotionAnalysis:
        templates:
        - templateName: success-rate
        args:
        - name: service-name
          value: app-preview
      postPromotionAnalysis:
        templates:
        - templateName: success-rate
        args:
        - name: service-name
          value: app-active
  selector:
    matchLabels:
      app: app
  template:
    metadata:
      labels:
        app: app
    spec:
      containers:
      - name: app
        image: app:latest
        ports:
        - containerPort: 8080
        livenessProbe:
          httpGet:
            path: /health
            port: 8080
          initialDelaySeconds: 30
          periodSeconds: 10
        readinessProbe:
          httpGet:
            path: /ready
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 5

4. Canary Deployment

Canary Deployment — постепенное развертывание новой версии для части пользователей.

# Canary Deployment with Istio
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: app-vs
spec:
  hosts:
  - app
  http:
  - match:
    - headers:
        canary:
          exact: "true"
    route:
    - destination:
        host: app
        subset: v2
      weight: 100
  - route:
    - destination:
        host: app
        subset: v1
      weight: 90
    - destination:
        host: app
        subset: v2
      weight: 10

---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: app
spec:
  host: app
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2

5. Infrastructure as Code

# Terraform Configuration
resource "aws_instance" "web_server" {
  ami           = var.ami_id
  instance_type = var.instance_type
  
  tags = {
    Name        = "Web Server"
    Environment = var.environment
    Project     = var.project_name
  }
}

resource "aws_security_group" "web_sg" {
  name_prefix = "web-sg-"
  
  ingress {
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }
  
  ingress {
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

2. Configuration Management

# Ansible Playbook
- name: Deploy Application
  hosts: web_servers
  become: yes
  vars:
    app_version: "{{ lookup('env', 'APP_VERSION') }}"
    db_host: "{{ lookup('env', 'DB_HOST') }}"
  
  tasks:
    - name: Update application
      git:
        repo: "https://github.com/company/app.git"
        version: "{{ app_version }}"
        dest: /opt/app
    
    - name: Install dependencies
      pip:
        requirements: /opt/app/requirements.txt
    
    - name: Update configuration
      template:
        src: config.j2
        dest: /opt/app/config.yaml
        backup: yes
    
    - name: Restart application
      systemd:
        name: app
        state: restarted
        enabled: yes

---

Code Review и архитектурные ревью

Процесс ревью кода

1. Code Review Checklist

# Code Review Checklist

## Функциональность
- [ ] Код выполняет требуемую функциональность
- [ ] Обрабатываются граничные случаи
- [ ] Нет неиспользуемого кода
- [ ] Логика понятна и корректна

## Качество кода
- [ ] Соблюдены принципы SOLID
- [ ] Нет дублирования кода
- [ ] Имена переменных и функций понятны
- [ ] Код хорошо структурирован

---

## Стандарты кодирования и инструменты

### Принципы стандартов кодирования

#### 1. Важность единого стиля кода

**Преимущества единого стиля:**
- Повышение читаемости кода
- Ускорение разработки
- Упрощение code review
- Снижение количества ошибок
- Улучшение поддержки кода

**Основные принципы:**
- **Консистентность** — одинаковый стиль во всем проекте
- **Читаемость** — код должен быть понятен любому разработчику
- **Простота** — избегание сложных конструкций
- **Документированность** — четкие комментарии и документация

#### 2. Стандарты кодирования по языкам

**Java - Google Java Style Guide:**

```java
// Правильное именование
public class UserService {
    private static final String DEFAULT_ROLE = "USER";
    private final UserRepository userRepository;
    
    public UserService(UserRepository userRepository) {
        this.userRepository = userRepository;
    }
    
    public User createUser(CreateUserRequest request) {
        validateUserRequest(request);
        User user = buildUser(request);
        return userRepository.save(user);
    }
    
    private void validateUserRequest(CreateUserRequest request) {
        if (request.getEmail() == null || request.getEmail().isEmpty()) {
            throw new IllegalArgumentException("Email is required");
        }
    }
    
    private User buildUser(CreateUserRequest request) {
        return User.builder()
            .email(request.getEmail())
            .name(request.getName())
            .role(DEFAULT_ROLE)
            .createdAt(LocalDateTime.now())
            .build();
    }
}

// Неправильное именование
public class userservice {
    private static final String default_role = "USER";
    private final userrepository userrepository;
    
    public userservice(userrepository userrepository) {
        this.userrepository = userrepository;
    }
    
    public user createuser(createuserrequest request) {
        validateuserrequest(request);
        user user = builduser(request);
        return userrepository.save(user);
    }
}

Rust - Rust Style Guide:

// Правильное именование
use std::collections::HashMap;

pub struct UserService {
    user_repository: Box<dyn UserRepository>,
}

impl UserService {
    pub fn new(user_repository: Box<dyn UserRepository>) -> Self {
        Self { user_repository }
    }
    
    pub fn create_user(&self, request: CreateUserRequest) -> Result<User, ServiceError> {
        self.validate_user_request(&request)?;
        let user = self.build_user(request);
        self.user_repository.save(user)
    }
    
    fn validate_user_request(&self, request: &CreateUserRequest) -> Result<(), ServiceError> {
        if request.email.is_empty() {
            return Err(ServiceError::ValidationError("Email is required".to_string()));
        }
        Ok(())
    }
    
    fn build_user(&self, request: CreateUserRequest) -> User {
        User {
            email: request.email,
            name: request.name,
            role: "USER".to_string(),
            created_at: chrono::Utc::now(),
        }
    }
}

// Неправильное именование
pub struct userservice {
    userrepository: Box<dyn userrepository>,
}

impl userservice {
    pub fn new(userrepository: Box<dyn userrepository>) -> Self {
        Self { userrepository }
    }
    
    pub fn createuser(&self, request: createuserrequest) -> Result<user, serviceerror> {
        // ...
    }
}

Python - PEP 8:

# Правильное именование
import logging
from typing import Optional, List
from dataclasses import dataclass
from datetime import datetime

logger = logging.getLogger(__name__)

@dataclass
class CreateUserRequest:
    email: str
    name: str
    password: str

class UserService:
    DEFAULT_ROLE = "USER"
    
    def __init__(self, user_repository: UserRepository):
        self.user_repository = user_repository
        self.logger = logging.getLogger(self.__class__.__name__)
    
    def create_user(self, request: CreateUserRequest) -> User:
        self._validate_user_request(request)
        user = self._build_user(request)
        return self.user_repository.save(user)
    
    def _validate_user_request(self, request: CreateUserRequest) -> None:
        if not request.email or not request.email.strip():
            raise ValueError("Email is required")
        
        if len(request.password) < 8:
            raise ValueError("Password must be at least 8 characters")
    
    def _build_user(self, request: CreateUserRequest) -> User:
        return User(
            email=request.email,
            name=request.name,
            role=self.DEFAULT_ROLE,
            created_at=datetime.utcnow()
        )

# Неправильное именование
class userservice:
    default_role = "USER"
    
    def __init__(self, userrepository):
        self.userrepository = userrepository
    
    def createuser(self, request):
        self.validateuserrequest(request)
        user = self.builduser(request)
        return self.userrepository.save(user)

Node.js/TypeScript - Airbnb Style Guide:

// Правильное именование
import { UserRepository } from './user-repository';
import { CreateUserRequest, User } from './types';
import { ServiceError } from './errors';

export class UserService {
    private static readonly DEFAULT_ROLE = 'USER';
    
    constructor(
        private readonly userRepository: UserRepository,
        private readonly logger: Logger
    ) {}
    
    public async createUser(request: CreateUserRequest): Promise<User> {
        this.validateUserRequest(request);
        const user = this.buildUser(request);
        return this.userRepository.save(user);
    }
    
    private validateUserRequest(request: CreateUserRequest): void {
        if (!request.email || request.email.trim() === '') {
            throw new ServiceError('Email is required');
        }
        
        if (request.password.length < 8) {
            throw new ServiceError('Password must be at least 8 characters');
        }
    }
    
    private buildUser(request: CreateUserRequest): User {
        return {
            email: request.email,
            name: request.name,
            role: UserService.DEFAULT_ROLE,
            createdAt: new Date(),
        };
    }
}

// Неправильное именование
export class userservice {
    private static readonly default_role = 'USER';
    
    constructor(
        private readonly userrepository: userrepository,
        private readonly logger: logger
    ) {}
    
    public async createuser(request: createuserrequest): Promise<user> {
        this.validateuserrequest(request);
        const user = this.builduser(request);
        return this.userrepository.save(user);
    }
}

3. Инструменты автоматизации стиля кода

Java - Spotless:

// build.gradle
plugins {
    id 'com.diffplug.spotless' version '6.0.0'
}

spotless {
    java {
        googleJavaFormat()
        removeUnusedImports()
        trimTrailingWhitespace()
        endWithNewline()
    }
    
    format 'misc', {
        target '*.gradle', '*.md', '.gitignore'
        trimTrailingWhitespace()
        indentWithSpaces(4)
        endWithNewline()
    }
}

Rust - rustfmt:

# rustfmt.toml
max_width = 100
tab_spaces = 4
newline_style = "Unix"
use_small_heuristics = "Default"
imports_granularity = "Crate"
group_imports = "StdExternalCrate"

Python - Black + isort:

# pyproject.toml
[tool.black]
line-length = 88
target-version = ['py38']
include = '\.pyi?$'
extend-exclude = '''
/(
  # directories
  \.eggs
  | \.git
  | \.hg
  | \.mypy_cache
  | \.tox
  | \.venv
  | build
  | dist
)/
'''

[tool.isort]
profile = "black"
multi_line_output = 3
line_length = 88
known_first_party = ["myproject"]

Node.js/TypeScript - Prettier + ESLint:

// .prettierrc
{
  "semi": true,
  "trailingComma": "es5",
  "singleQuote": true,
  "printWidth": 80,
  "tabWidth": 2,
  "useTabs": false
}

// .eslintrc.json
{
  "extends": [
    "airbnb-base",
    "airbnb-typescript/base",
    "@typescript-eslint/recommended"
  ],
  "parser": "@typescript-eslint/parser",
  "parserOptions": {
    "project": "./tsconfig.json"
  },
  "rules": {
    "import/prefer-default-export": "off",
    "class-methods-use-this": "off",
    "no-console": "warn",
    "@typescript-eslint/no-unused-vars": "error"
  }
}

4. Pre-commit хуки

# .pre-commit-config.yaml
repos:
  - repo: https://github.com/pre-commit/pre-commit-hooks
    rev: v4.4.0
    hooks:
      - id: trailing-whitespace
      - id: end-of-file-fixer
      - id: check-yaml
      - id: check-added-large-files
      - id: check-merge-conflict

  - repo: https://github.com/psf/black
    rev: 22.10.0
    hooks:
      - id: black
        language_version: python3

  - repo: https://github.com/pycqa/isort
    rev: 5.12.0
    hooks:
      - id: isort

  - repo: https://github.com/pycqa/flake8
    rev: 6.0.0
    hooks:
      - id: flake8
        args: [--max-line-length=88, --extend-ignore=E203]

  - repo: https://github.com/pre-commit/mirrors-eslint
    rev: v8.28.0
    hooks:
      - id: eslint
        files: \.(js|ts)$
        types: [file]

5. CI/CD интеграция

# .github/workflows/code-style.yml
name: Code Style Check

on:
  pull_request:
    branches: [ main, develop ]
  push:
    branches: [ main, develop ]

jobs:
  code-style:
    runs-on: ubuntu-latest
    
    steps:
    - uses: actions/checkout@v3
    
    - name: Set up Java
      uses: actions/setup-java@v3
      with:
        java-version: '17'
        distribution: 'temurin'
    
    - name: Run Spotless Check
      run: ./gradlew spotlessCheck
    
    - name: Set up Python
      uses: actions/setup-python@v4
      with:
        python-version: '3.9'
    
    - name: Install Python dependencies
      run: |
        pip install black isort flake8 mypy
    
    - name: Run Black
      run: black --check .
    
    - name: Run isort
      run: isort --check-only .
    
    - name: Run Flake8
      run: flake8 .
    
    - name: Run MyPy
      run: mypy .
    
    - name: Set up Node.js
      uses: actions/setup-node@v3
      with:
        node-version: '18'
    
    - name: Install Node.js dependencies
      run: npm ci
    
    - name: Run ESLint
      run: npm run lint
    
    - name: Run Prettier
      run: npm run format:check

6. Автоматическое форматирование в IDE

VS Code настройки:

// .vscode/settings.json
{
  "editor.formatOnSave": true,
  "editor.codeActionsOnSave": {
    "source.organizeImports": true,
    "source.fixAll.eslint": true
  },
  "python.formatting.provider": "black",
  "python.linting.enabled": true,
  "python.linting.flake8Enabled": true,
  "typescript.preferences.organizeImportsOnSave": true,
  "java.format.settings.url": ".vscode/java-google-style.xml"
}

IntelliJ IDEA настройки:

<!-- .idea/codeStyles/Project.xml -->
<component name="ProjectCodeStyleConfiguration">
  <code_scheme name="Project" version="173">
    <JavaCodeStyleSettings>
      <option name="IMPORT_LAYOUT_TABLE">
        <value>
          <option name="name" value="java" />
          <option name="value" value="java.*" />
          <option name="name" value="javax" />
          <option name="value" value="javax.*" />
          <option name="name" value="BLANK_LINE" />
          <option name="value" value="" />
          <option name="name" value="ALL_OTHER_IMPORTS" />
          <option name="value" value=".*" />
        </value>
      </option>
    </JavaCodeStyleSettings>
  </code_scheme>
</component>

7. Метрики качества кода

// SonarQube правила для Java
public class CodeQualityMetrics {
    
    // Плохо: слишком длинный метод
    public void processUserData(String name, String email, String phone, 
                               String address, String city, String country,
                               String zipCode, String dateOfBirth, String gender) {
        // 50+ строк кода
    }
    
    // Хорошо: разбиение на более мелкие методы
    public void processUserData(UserData userData) {
        validateUserData(userData);
        enrichUserData(userData);
        saveUserData(userData);
    }
    
    private void validateUserData(UserData userData) {
        // валидация
    }
    
    private void enrichUserData(UserData userData) {
        // обогащение данных
    }
    
    private void saveUserData(UserData userData) {
        // сохранение
    }
}

8. Документирование стандартов

# Coding Standards

## Общие принципы

1. **Читаемость превыше всего** — код должен быть понятен любому разработчику
2. **Консистентность** — одинаковый стиль во всем проекте
3. **Простота** — избегание сложных конструкций
4. **Документированность** — четкие комментарии

## Именование

### Java
- Классы: `PascalCase` (UserService)
- Методы: `camelCase` (createUser)
- Константы: `UPPER_SNAKE_CASE` (DEFAULT_ROLE)
- Переменные: `camelCase` (userName)

### Python
- Классы: `PascalCase` (UserService)
- Функции: `snake_case` (create_user)
- Константы: `UPPER_SNAKE_CASE` (DEFAULT_ROLE)
- Переменные: `snake_case` (user_name)

### TypeScript
- Классы: `PascalCase` (UserService)
- Функции: `camelCase` (createUser)
- Константы: `UPPER_SNAKE_CASE` (DEFAULT_ROLE)
- Переменные: `camelCase` (userName)

## Структура файлов

src/ ├── controllers/ # Контроллеры ├── services/ # Бизнес-логика ├── repositories/ # Доступ к данным ├── models/ # Модели данных ├── utils/ # Утилиты └── config/ # Конфигурация

## Комментарии

```java
/**
 * Создает нового пользователя в системе
 * 
 * @param request данные для создания пользователя
 * @return созданный пользователь
 * @throws ValidationException если данные некорректны
 */
public User createUser(CreateUserRequest request) {
    // Валидация входных данных
    validateUserRequest(request);
    
    // Создание пользователя
    User user = buildUser(request);
    
    // Сохранение в базу данных
    return userRepository.save(user);
}

---

## Производительность
- [ ] Нет очевидных проблем с производительностью
- [ ] Используются подходящие алгоритмы
- [ ] Нет утечек памяти
- [ ] Оптимизированы запросы к БД

## Безопасность
- [ ] Нет уязвимостей безопасности
- [ ] Валидация входных данных
- [ ] Безопасная работа с паролями
- [ ] Нет SQL injection

## Тестирование
- [ ] Покрытие тестами
- [ ] Тесты понятны и корректны
- [ ] Интеграционные тесты
- [ ] Тесты производительности

2. Code Review Tools

# SonarQube Configuration
sonar:
  project_key: "my-project"
  project_name: "My Project"
  
  quality_gates:
    - "Code Coverage > 80%"
    - "Duplicated Lines < 3%"
    - "Maintainability Rating A"
    - "Reliability Rating A"
    - "Security Rating A"
  
  rules:
    - "java:S1144"  # Unused private methods
    - "java:S1186"  # Empty methods
    - "java:S1481"  # Unused local variables
    - "java:S1854"  # Dead stores

Процесс архитектурного ревью

1. Architecture Review Checklist

# Architecture Review Checklist

## Архитектурные принципы
- [ ] Соответствие архитектурным принципам
- [ ] Соблюдение паттернов проектирования
- [ ] Правильное разделение ответственности
- [ ] Слабая связанность компонентов

## Качественные атрибуты
- [ ] Производительность соответствует требованиям
- [ ] Масштабируемость обеспечена
- [ ] Безопасность учтена
- [ ] Надежность гарантирована

## Техническая реализуемость
- [ ] Технологии подходят для задачи
- [ ] Команда имеет необходимые навыки
- [ ] Инфраструктура поддерживает решение
- [ ] Временные рамки реалистичны

## Риски и митигации
- [ ] Основные риски идентифицированы
- [ ] План митигации разработан
- [ ] Fallback стратегии определены
- [ ] Мониторинг рисков настроен

2. Architecture Review Tools

// Architecture Tests
@ArchTest
static final ArchRule noClassesShouldUseSystemOut = 
    noClasses().should().callMethod(System.class, "out", "println", String.class);

@ArchTest
static final ArchRule repositoryClassesShouldHaveRepositoryAnnotation = 
    classes().that().haveNameMatching(".*Repository")
        .should().beAnnotatedWith(Repository.class);

@ArchTest
static final ArchRule serviceClassesShouldHaveServiceAnnotation = 
    classes().that().haveNameMatching(".*Service")
        .should().beAnnotatedWith(Service.class);

---

Управление техническим долгом

Что такое технический долг

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

Типы технического долга

1. Code Debt

// Пример технического долга в коде
public class UserService {
    // Долг: отсутствие валидации
    public User createUser(String name, String email) {
        User user = new User();
        user.setName(name);
        user.setEmail(email);
        return userRepository.save(user);
    }
    
    // Долг: дублирование кода
    public User updateUser(Long id, String name, String email) {
        User user = userRepository.findById(id);
        user.setName(name);
        user.setEmail(email);
        return userRepository.save(user);
    }
    
    // Долг: отсутствие обработки ошибок
    public User getUser(Long id) {
        return userRepository.findById(id);
    }
}

2. Architecture Debt

# Архитектурный долг

## Проблемы архитектуры
- Монолитная архитектура в микросервисном мире
- Тесная связанность компонентов
- Отсутствие четких границ доменов
- Неоптимальные паттерны взаимодействия

## Последствия
- Сложность внесения изменений
- Высокие затраты на разработку
- Проблемы с масштабированием
- Сложность тестирования

3. Infrastructure Debt

# Инфраструктурный долг
infrastructure_debt:
  problems:
    - "Manual deployment processes"
    - "Outdated dependencies"
    - "Inconsistent environments"
    - "Lack of monitoring"
    - "Manual configuration management"
  
  consequences:
    - "High deployment risk"
    - "Security vulnerabilities"
    - "Environment inconsistencies"
    - "Difficult troubleshooting"
    - "High operational costs"

Управление техническим долгом

1. Debt Tracking

# Technical Debt Backlog

## High Priority
- [ ] Refactor UserService validation logic
- [ ] Implement proper error handling
- [ ] Remove code duplication
- [ ] Add missing unit tests

## Medium Priority
- [ ] Update outdated dependencies
- [ ] Improve database queries
- [ ] Add integration tests
- [ ] Implement caching

## Low Priority
- [ ] Code style improvements
- [ ] Documentation updates
- [ ] Performance optimizations
- [ ] Logging improvements

2. Debt Prevention

// Предотвращение технического долга
@Service
public class UserService {
    @Autowired
    private UserValidator userValidator;
    
    @Autowired
    private UserRepository userRepository;
    
    // Предотвращение долга: валидация
    public User createUser(CreateUserRequest request) {
        userValidator.validate(request);
        
        User user = new User(request);
        return userRepository.save(user);
    }
    
    // Предотвращение долга: обработка ошибок
    public User getUser(Long id) {
        return userRepository.findById(id)
            .orElseThrow(() -> new UserNotFoundException("User not found: " + id));
    }
}

3. Debt Refactoring

// Рефакторинг технического долга
@Service
public class UserService {
    @Autowired
    private UserRepository userRepository;
    
    @Autowired
    private UserMapper userMapper;
    
    // Рефакторинг: использование маппера
    public User createUser(CreateUserRequest request) {
        User user = userMapper.toEntity(request);
        return userRepository.save(user);
    }
    
    // Рефакторинг: использование маппера
    public UserResponse getUser(Long id) {
        User user = userRepository.findById(id)
            .orElseThrow(() -> new UserNotFoundException("User not found: " + id));
        
        return userMapper.toResponse(user);
    }
}

---

Коммуникация и презентации

Коммуникация с командой

1. Technical Communication

# Техническая коммуникация

## Ежедневные стендапы
- Прогресс по архитектурным задачам
- Блокеры и проблемы
- Планы на день

## Еженедельные технические ревью
- Обзор архитектурных решений
- Обсуждение технических проблем
- Планирование улучшений

## Ежемесячные архитектурные сессии
- Анализ архитектуры
- Планирование рефакторинга
- Обучение команды

2. Stakeholder Communication

# Коммуникация со стейкхолдерами

## Бизнес-стейкхолдеры
- Объяснение технических решений простым языком
- Связь технических решений с бизнес-ценностью
- Оценка влияния на бизнес-процессы

## Технические стейкхолдеры
- Детальное техническое обоснование
- Анализ альтернативных решений
- Оценка рисков и митигаций

Презентации архитектуры

1. Executive Summary

# Презентация для руководства

## Слайд 1: Проблема
- Текущие проблемы системы
- Влияние на бизнес
- Необходимость изменений

## Слайд 2: Решение
- Предлагаемая архитектура
- Ключевые преимущества
- Бизнес-ценность

## Слайд 3: Реализация
- План миграции
- Временные рамки
- Ресурсы и бюджет

## Слайд 4: Риски
- Основные риски
- Планы митигации
- Fallback стратегии

2. Technical Deep Dive

# Техническая презентация

## Архитектурные принципы
- SOLID принципы
- Паттерны проектирования
- Архитектурные стили

## Технологический стек
- Выбранные технологии
- Обоснование выбора
- Альтернативы

## Качественные атрибуты
- Производительность
- Масштабируемость
- Надежность
- Безопасность

## Реализация
- Детальный план
- Зависимости
- Риски

---

Практические задания

Задание 1: Техническое лидерство

1. Проведите архитектурное ревью
2. Создайте план развития команды
3. Проведите техническую презентацию

Задание 2: DevOps процессы

1. Настройте CI/CD пайплайн
2. Реализуйте Infrastructure as Code
3. Настройте мониторинг и алерты

Задание 3: Управление техническим долгом

1. Проведите аудит технического долга
2. Создайте план рефакторинга
3. Реализуйте меры по предотвращению долга

---

Дополнительные ресурсы

Книги

• "The Phoenix Project" by Gene Kim
• "The DevOps Handbook" by Gene Kim
• "Team Topologies" by Matthew Skelton
• "Accelerate" by Nicole Forsgren

Инструменты

• CI/CD: Jenkins, GitLab CI, GitHub Actions
• Monitoring: Prometheus, Grafana, ELK Stack
• Code Quality: SonarQube, Checkmarx, Veracode
• Communication: Slack, Microsoft Teams, Confluence

---

Контрольные вопросы

1. Какие обязанности у технического лидера?
2. Как управлять архитектурными процессами?
3. Как интегрировать архитектуру в Agile процессы?
4. Что такое DevOps культура?
5. Как проводить эффективные code review?
6. Как управлять техническим долгом?
7. Как коммуницировать архитектурные решения?
8. Какие инструменты использовать для автоматизации процессов?