Schemi di qualità del codice

Ulteriori informazioni su Ottimizzazione delle risorse e dei costi ben progettata → Organizzazione del codice

Questa pagina dello schema consolidato descrive la qualità del codice e le procedure di manutenzione per l’ottimizzazione delle risorse. Include indicazioni sulle decisioni relative ai codici standard e personalizzati, sulla gestione del debito tecnico, sugli standard di progettazione, sulle pratiche di documentazione e sulla governance. Questi schemi aiutano a mantenere la velocità di sviluppo, a ridurre le percentuali di difetti e a consentire la sostenibilità delle soluzioni a lungo termine.

Schemi

Dove cercare	Che bell’aspetto
Prestazioni su larga scala	✅ I test verificano che le soluzioni dichiarative soddisfino i requisiti di prestazione ai volumi di dati previsti. I test di caricamento in Full Copy Sandbox con dati realistici confermano la scalabilità prima della distribuzione in produzione.
Analisi della manutenibilità	✅ L’analisi del TCO confronta l’onere di manutenzione a lungo termine degli approcci dichiarativi e personalizzati, incluse le attività di aggiornamento, i requisiti di test e i requisiti di competenza per i team futuri.
Architettura ad approccio misto	✅ Le soluzioni combinano approcci dichiarativi e programmatici laddove appropriato. Il flusso orchestra la logica generale mentre Apex gestisce i calcoli complessi. I campi formula calcolano derivazioni semplici mentre Apex elabora le operazioni in blocco.
Valutazione AppExchange	✅ Prima di creare codice personalizzato, valutare i pacchetti AppExchange esistenti che offrono funzionalità simili. Documentare i risultati della valutazione, inclusi i pacchetti rivisti, le lacune di capacità e il confronto del TCO.

Schemi

Dove cercare	Che bell’aspetto
Visibilità backlog	✅ Voci debito tecnico tracciate in arretrato con etichette chiare, contesto che spiega perché il codice deve essere migliorato, impatto aziendale del non essere risolto e sforzo stimato di riparazione. Il debito invisibile non può essere definito come priorità o gestito.
Miglioramento incrementale	✅ Regola boy scout applicata durante lo sviluppo delle funzioni: lasciare il codice meglio di quanto trovato. I team risolvono il debito in modo incrementale durante le funzioni correlate anziché richiedere grandi progetti di refactoring dedicati. Le revisioni del codice verificano miglioramenti incrementali.
Prevenzione rispetto alla riparazione	✅ I cancelli di qualità in CI/CD impongono gli standard prima che il codice raggiunga la produzione. Scanner di codice, ApexGuru e metriche di complessità integrate nella convalida delle richieste di estrazione. I problemi di blocco impediscono l’unione finché non vengono risolti.

Anti-schemi

Dove cercare	Che brutto aspetto
Gestione dei backlog	⚠️ Debito tecnico riconosciuto verbalmente ma mai registrato in arretrato. Nessuna visibilità sull’accumulo del debito. La correzione del debito è sempre rinviata a favore del lavoro delle funzioni. La velocità diminuisce gradualmente, i team non sanno spiegarne il motivo.
Bypass cancello di qualità	⚠️ Cancelli di qualità CI / CD spesso ignorati sotto pressione del programma con l’intenzione di risolvere in seguito. “Dopo” non succede mai. Errori dello scanner di codice contrassegnati come problemi noti e ignorati. Soglie di complessità innalzate per soddisfare implementazioni inadeguate.
Nessuna capacità di riparazione	⚠️ 100% della capacità sprint allocata per il lavoro di feature con capacità zero per la correzione del debito tecnico. Il debito si accumula all’infinito. Grandi progetti di refactoring richiesti ogni 18-24 mesi consumando interi trimestri.
Debito di configurazione	⚠️ I tipi di metadati personalizzati e le impostazioni personalizzate si accumulano senza pulizia. La configurazione non utilizzata persiste all’infinito. La produzione ha 50 record di metadati, solo 12 vengono effettivamente utilizzati. Nessuna documentazione che spieghi lo scopo dei valori di configurazione.

Schemi

Dove cercare	Che bell’aspetto
Architettura trigger	✅ Schema trigger handler applicato in modo coerente: i trigger sottili delegano alle classi handler, le classi handler organizzano la logica in base al contesto trigger (prima dell’inserimento, dopo l’aggiornamento), i nomi chiari dei metodi rivelano lo scopo. Nessuna logica aziendale nei file trigger.
Implementazione del livello di servizio	✅ Logica aziendale incapsulata in classi di servizio separate da controller, trigger e punti di ingresso batch. Classi di servizio riutilizzabili in più punti di ingresso senza duplicazioni. Cancella convenzione di denominazione (AccountService, OrderProcessor).
Schema di selezione	✅ Query SOQL centralizzate in classi selettori per oggetto (AccountSelector, OpportunitySelector). I metodi selettori restituiscono insiemi di campi coerenti. Le modifiche dell’ottimizzazione LDV sono state applicate una sola volta, con effetto su tutte le query.
Schema di repository	✅ Accesso ai dati astratto dietro interfacce che consentono il test con fonti di dati fittizie. Le implementazioni repository incapsulano le strategie di costruzione delle query, caching e ottimizzazione. La logica aziendale dipende dalle interfacce dei repository, non dalle implementazioni concrete.
Standard di progettazione dei componenti	✅ I componenti Web Lightning seguono il principio di responsabilità singola, espongono le proprietà per la configurazione, emettono eventi per la comunicazione controllante, progettati per la composizione e il riutilizzo. Libreria di componenti documentata con esempi di utilizzo.
Organizzazione codice	✅ La struttura logica dei pacchetti raggruppa le classi correlate. Netta separazione tra logica di dominio, accesso ai dati, endpoint API e adattatori di integrazione. Le dipendenze dei pacchetti si dirigono in una direzione.

Anti-schemi

Dove cercare	Che brutto aspetto
Trigger	⚠️ Tutta la logica aziendale incorporata direttamente nei file dei trigger con condizionali profondamente nidificati, senza separazione delle preoccupazioni, senza classi di handler. Oltre 300 file trigger di linea che combinano convalida, logica aziendale e chiamate di integrazione. Impossibile testare in modo efficace.
Query in loop	⚠️ Query SOQL eseguite all’interno di cicli di iterazione. Funziona con piccoli volumi di dati ma viola il limite di 100 query SOQL durante l’elaborazione delle operazioni in blocco. Scoperto solo quando i trigger vengono attivati su carichi di dati in blocco in produzione.
DML in loop	⚠️ istruzioni DML (inserimento, aggiornamento, eliminazione) eseguite all’interno di cicli di iterazione. Viola il limite di 150 istruzioni DML con le operazioni in blocco. Ogni record viene elaborato in una transazione di database separata anziché in un’elaborazione in blocco efficiente.

Schemi

Dove cercare	Che bell’aspetto
Record decisioni architettura	✅ Decisioni architettoniche significative documentate nelle ADR memorizzate nel controllo di versione. Gli ADR tengono conto del contesto (fattori trainanti dell’attività, vincoli tecnici), della decisione (scelta), delle alternative prese in considerazione (motivo del rifiuto) e delle conseguenze (compromessi, condizioni di riesame).