È ancora buona norma registrare i parametri e i resi?

Non penso che l'articolo implichi che il metodo ogni dovrebbe essere registrato in quel modo, sta solo dicendo quando stai loggando assicurati di catturare il contesto in cui si è verificato il registro.

Ad esempio, se si dispone di un registro che dice solo "Utente non può essere trovato", se si sta effettivamente cercando di capire lo scenario che porta a quel registro, probabilmente è necessario conoscere almeno l'ID utente. In genere gli argomenti delle funzioni hanno l'effetto più significativo sull'output di una funzione, quindi questo è il contesto più importante da catturare, ma le variabili di classe o globali potrebbero essere altrettanto importanti a seconda della situazione.

Nel caso di un'applicazione web Spring, sicuramente non inserirò il log in ogni singola funzione, ma registrerei dove sono probabili i fallimenti. Ad esempio, se si effettua una chiamata a un servizio esterno.

L'articolo stesso afferma:

Of course, you must be reasonable but every method that: accesses external system (including database), blocks, waits, etc. should be considered.

Sebbene alcuni di questi log potrebbero essere già forniti dal tuo ORM o RDBMS, quindi non aggiungerei la registrazione ad ogni singola chiamata di database.

L'articolo afferma inoltre:

You should consider DEBUG or TRACE levels as best suited for these types of logs.

Che tipicamente non sono registrati in produzione, quindi potresti considerarlo un'alternativa alle istruzioni temporanee di stampa / eco durante lo sviluppo. Di nuovo, solo dove appropriato.

Utilizzerai mai le informazioni registrate?

Potrebbe essere utile per il debug ma probabilmente utilizzerai comunque un debugger.

Ho lavorato su progetti in cui la praticità è stata registrata, ma c'era un reale requisito aziendale: avevano bisogno di prove legali se veniva rilevato un comportamento errato / fraudolento da parte di collaboratori "fidati".

Dalla mia opzione - i parametri di registrazione e i valori di ritorno devono essere presenti ma disattivati per impostazione predefinita. Per esempio. per impostazione predefinita non viene registrato nulla o solo le cose necessarie. Ma quando qualcosa va storto puoi abilitare facilmente la registrazione tramite la modifica della configurazione dei file (log4j e logback support config che aggiornano con l'intervallo di tempo).

Cosa ti dà e cosa va male?

1. Prima di tutto questo approccio è molto utile per situazioni in cui non è possibile eseguire il codice locale. Ad esempio aws lambda che potrebbe necessitare di alcune impostazioni di sicurezza e potrebbe comunicare con altre risorse aws. In tal caso, puoi abilitare facilmente la registrazione e rieseguire lambda per vedere cosa succede.
2. Considerare l'ambiente di produzione quando i bug non possono essere riprodotti localmente. Nel caso in cui il problema sia difficile da riprodurre, è sufficiente attivare la registrazione aggiuntiva per un periodo di tempo limitato (ad esempio 1 minuto o meno) e vedere cosa succede nella produzione. Il periodo di tempo limitato limita la degradazione delle prestazioni per la registrazione aggiuntiva.
3. Spesso durante lo sviluppo si codifica e poi si pensa - "Non funziona, devo aggiungere la registrazione di più qui". La possibilità di accedere a metodi e parametri porta a una minore codifica.

Non mescolare la logica di registrazione di bussines e la registrazione per il debug

Ad esempio, se lavori con un sistema esterno, è meglio aggiungere la registrazione direttamente come: logger.info("Order created id={}", id) , quindi abilita la registrazione per tutti i layer per vedere l'ID ordine nei log.