Ruoli Developer

Il prodotto Development raggruppa i ruoli che costruiscono, esaminano, testano e analizzano ABAP. Alcuni scrivono in SAP; diversi sono di sola lettura e fisicamente non possono. Scegli un ruolo nel compositore della Chat; se non sei sicuro di quale sia adatto, inizia con un ruolo di sola lettura come Research.

Questa pagina documenta ogni ruolo di Development. I ruoli orientati al build (CDS, RAP, Fiori, Migration, Migration Map, Clean-core check) hanno una propria pagina — vedi CDS, RAP, Fiori e migrazione. Anche Adobe Forms ha la sua pagina — vedi Adobe Forms.

Per come i ruoli impongono i permessi a livello di strumento, vedi Come funzionano i ruoli.

In sintesi#

Development#

Lettura/Scrittura: Scrittura. Il ruolo predefinito.

Development implementa un requisito dall'inizio alla fine. La sua metodologia è deliberata: esplorare il sistema → riutilizzare prima (trovare e preferire oggetti esistenti) → pianificare la modifica → bloccare e impostare sorgenti → validare (sintassi + ABAP Unit + ATC) → attivare → sbloccare → riportare. Non cancella mai nulla, e fa la modifica più piccola che soddisfa il requisito.

Quando usarlo: il ruolo di lavoro principale — ogni volta che vuoi una modifica effettivamente costruita e attivata in SAP sotto la tua direzione.

Architecture#

Lettura/Scrittura: Sola lettura.

Architecture produce solo un solution design e un piano — gli oggetti da creare o modificare, i pattern da usare, il modello dati, la strategia di transport e i rischi. Non scrive, blocca o attiva nulla; ti consegna un piano che puoi esaminare prima che venga scritto qualsiasi codice (per esempio, con una successiva esecuzione Development).

Quando usarlo: all'inizio di un requisito non banale, quando vuoi concordare la forma della soluzione prima di costruirla.

Code review#

Lettura/Scrittura: Sola lettura.

Code review legge il tuo oggetto (o i tuoi oggetti) di destinazione e li esamina rispetto agli standard del progetto. Restituisce risultati prioritizzati — Critical / Major / Minor — ciascuno con una posizione e un suggerimento di correzione concreto. Non cambia nulla.

Quando usarlo: per verificare il lavoro rispetto alle convenzioni della tua squadra, o come revisione indipendente di una modifica prima che prosegua.

Unit tests#

Lettura/Scrittura: Scrittura — solo codice di test.

Unit tests scrive o estende i test ABAP Unit per la destinazione. Non cambia mai la logica di produzione: se trova un bug nel codice in test, segnala il bug invece di modificare il codice di produzione. Esegue i test finché non sono verdi.

Quando usarlo: per aggiungere o far crescere la copertura di test su codice esistente senza alcun rischio di alterare il comportamento.

ATC check#

Lettura/Scrittura: Scrittura.

ATC check esegue l'ABAP Test Cockpit sulla destinazione e riporta i risultati, raggruppati per leggibilità. È leggero: corregge i risultati solo se lo chiedi esplicitamente. Il suo fratello sistematico è ATC remediation, qui sotto.

Quando usarlo: una rapida passata di qualità per vedere cosa segnala ATC, senza impegnarti a correggerlo.

ATC remediation#

Lettura/Scrittura: Scrittura.

ATC remediation esegue ATC e poi corregge i risultati una categoria alla volta — Performance, poi Security, poi Robustness, poi Cleanliness — apportando modifiche che preservano il comportamento e riverificando dopo ogni categoria. Richiede e crea un proprio transport dedicato e non ne prende mai in prestito uno esistente.

Su un sistema QAS o PROD diventa di sola lettura e si limita a riportare; le scritture di remediation sono per i livelli di sviluppo.

Quando usarlo: una pulizia sistematica dei risultati ATC di un oggetto, quando vuoi le correzioni fatte in passate disciplinate e verificabili.

Research#

Lettura/Scrittura: Sola lettura.

Research investiga e risponde a domande con prove — legge sorgenti, struttura e informazioni where-used, e può eseguire query SQL per domande sui dati. Non cambia nulla. È un buon primo ruolo sicuro quando stai esplorando un sistema sconosciuto.

Quando usarlo: qualsiasi domanda tipo «come funziona questo / dove viene usato / cosa dicono i dati», con rischio zero per SAP.

Specification#

Lettura/Scrittura: Sola lettura verso SAP.

Specification converte una spec grezza del cliente — testo incollato, un file Excel o un .docx — nel formato spec interno normalizzato di Makion. Scrive solo file di spec nel workspace (mai in SAP), con versioning, e alimenta la scheda Specifiche.

Quando usarlo: per trasformare un requisito in arrivo disordinato in una spec pulita e strutturata su cui altri ruoli (come Effort estimate o Development) possono agire.

Effort estimate#

Lettura/Scrittura: Sola lettura.

Effort estimate trasforma una spec in una stima di sforzo onesta: una fascia di complessità per oggetto (S / M / L), intervalli di ore invece di singoli numeri a falsa precisione, assunzioni e incognite esplicite e un margine di overhead. Produce un file di stima scaricabile e non scrive alcun codice.

Quando usarlo: per dimensionare e prezzare il lavoro a partire da una spec, con l'incertezza dichiarata in anticipo.

Pagine correlate#

• Come funzionano i ruoli — il modello dei permessi dietro ogni ruolo.
• Chat — scegli un ruolo e invia un'attività.
• CDS, RAP, Fiori e migrazione — i ruoli di build e migrazione di Development.
• Adobe Forms — clonare e adattare SAP Interactive Forms.
• Specifiche — dove vive l'output di Specification.
• Metodologia — personalizza le regole di base che ogni ruolo segue.
• Modalità autonoma — la pipeline di applicazione con gate umano per le scritture.