10 - Evoluzione e Manutenzione del Progetto

Evoluzione del Progetto: Scalabilità e Manutenzione

Un progetto non finisce con il deploy. La vera sfida è mantenerlo, evolverlo e scalarlo nel tempo. Claude può essere un partner prezioso per refactoring, aggiunta di feature e decisioni di scalabilità.

In questo articolo vedremo come usare Claude per la manutenzione continua, il refactoring guidato e la pianificazione dell'evoluzione del progetto.

Refactoring Guidato con Claude

Claude eccelle nel refactoring perchè può analizzare il contesto completo e suggerire miglioramenti mantenendo la compatibilità.

<role>Sei un Senior Developer specializzato in refactoring</role>

<context>
Ho questo OrderService che è cresciuto troppo.
Ha 500+ righe e gestisce: CRUD, validazione, notifiche, pagamenti.
</context>

<code>
[Incolla il codice del service]
</code>

<task>
Analizza il service e proponi un piano di refactoring:
1. Identifica le violazioni di Single Responsibility
2. Proponi la separazione in servizi più piccoli
3. Suggerisci l'ordine di refactoring (minimo rischio)
4. Fornisci esempi di codice per le parti critiche
</task>

<constraints>
- Mantieni compatibilità API esterna
- Refactoring incrementale (no big bang)
- Ogni step deve essere deployabile
</constraints>

Pattern di Refactoring Comuni

Aggiunta Nuove Feature

<context>
Progetto: Order Management (gia in produzione)
Stack: Spring Boot, PostgreSQL, Angular
Feature esistenti: CRUD ordini, pagamenti, notifiche email
</context>

<task>
Devo aggiungere la feature "Ordini Ricorrenti":
- Un cliente può impostare un ordine come ricorrente
- Frequenza: giornaliera, settimanale, mensile
- Il sistema crea automaticamente nuovi ordini

Analizza:
1. Impatto sulle entità esistenti
2. Nuove entità/tabelle necessarie
3. Modifiche API
4. Considerazioni di backward compatibility
5. Piano di implementazione step-by-step
</task>

Feature Toggle Pattern

// FeatureToggleService.java
@Service
public class FeatureToggleService {{ '{' }}

    @Value("${{ '{' }}features.recurring-orders.enabled:false{{ '}' }}")
    private boolean recurringOrdersEnabled;

    @Value("${{ '{' }}features.recurring-orders.rollout-percentage:0{{ '}' }}")
    private int rolloutPercentage;

    public boolean isRecurringOrdersEnabled(String customerId) {{ '{' }}
        if (!recurringOrdersEnabled) return false;

        // Rollout graduale basato su hash del customer ID
        int hash = Math.abs(customerId.hashCode() % 100);
        return hash < rolloutPercentage;
    {{ '}' }}
{{ '}' }}

// Uso nel controller
@PostMapping("/{{ '{' }}orderId{{ '}' }}/recurring")
public ResponseEntity<?> setRecurring(
        @PathVariable String orderId,
        @RequestBody RecurringConfig config,
        @AuthenticationPrincipal User user) {{ '{' }}

    if (!featureToggle.isRecurringOrdersEnabled(user.getCustomerId())) {{ '{' }}
        return ResponseEntity.status(404).body("Feature not available");
    {{ '}' }}

    return orderService.setRecurring(orderId, config);
{{ '}' }}

Gestione Debito Tecnico

<task>
Analizza questa codebase e identifica il debito tecnico:

1. Code smells (duplicazione, metodi lunghi, classi god)
2. Dipendenze outdated con vulnerabilità note
3. Test mancanti o fragili
4. Documentazione obsoleta
5. Configurazioni hardcoded

Per ogni issue:
- Severity (critical, high, medium, low)
- Effort stimato (ore)
- Impatto se non risolto
- Suggerimento di fix
</task>

# Tech Debt Backlog

## Critical
| Issue | Effort | Impact | Sprint |
|-------|--------|--------|--------|
| Spring Boot 3.0 → 3.2 (CVE) | 4h | Security | Next |
| N+1 query in OrderList | 2h | Performance | Next |

## High
| Issue | Effort | Impact | Sprint |
|-------|--------|--------|--------|
| OrderService split | 8h | Maintainability | Q2 |
| Add integration tests | 16h | Reliability | Q2 |

## Medium
| Issue | Effort | Impact | Sprint |
|-------|--------|--------|--------|
| Refactor DTOs to records | 4h | Code quality | Backlog |
| Update Javadoc | 2h | Documentation | Backlog |

Scalabilità

Quando Scalare

Strategie di Scalabilità

<context>
Il mio progetto è cresciuto:
- 10.000 utenti attivi/giorno
- 50.000 ordini/giorno
- Response time P95: 800ms (target: 300ms)
- Single instance, PostgreSQL, Redis cache

Stack: Spring Boot, PostgreSQL, Redis, Kafka
</context>

<task>
Analizza e proponi una strategia di scalabilità:
1. Quick wins (ottimizzazioni senza cambi architettura)
2. Medium term (1-2 mesi)
3. Long term (se continua a crescere)

Per ogni proposta:
- Effort di implementazione
- Costo infrastruttura stimato
- Impatto atteso
</task>

Manutenzione Preventiva

# Checklist Manutenzione Mensile

## Dipendenze
- [ ] Check vulnerabilità (./mvnw dependency:check)
- [ ] Update minor versions
- [ ] Review breaking changes major versions

## Database
- [ ] Analizza query lente (pg_stat_statements)
- [ ] Verifica dimensione tabelle
- [ ] Check indici non utilizzati
- [ ] Test restore backup

## Monitoring
- [ ] Review alert triggered
- [ ] Analizza trend metriche
- [ ] Verifica log errors
- [ ] Check disk usage

## Sicurezza
- [ ] Rotate secrets/keys
- [ ] Review access logs
- [ ] Check certificate expiry
- [ ] Update security patches

## Documentazione
- [ ] Sync README con stato attuale
- [ ] Update API docs se cambiata
- [ ] Review ADR pendenti

Riepilogo e Prossimo Passo

Abbiamo percorso un lungo cammino nella serie "Claude: AI-Driven Personal Project". In questi articoli abbiamo esplorato come usare Claude come partner tecnico per ogni fase dello sviluppo:

Nel prossimo articolo vedremo come applicare tutto questo in un progetto reale: l'integrazione di Claude Code in Play The Event, un progetto multi-stack con architettura DDD e Hexagonal.