Approccio alla consegna di "API di registrazione"

2

Ho affrontato una domanda in un'intervista su .NET.

Come cliente ho bisogno di un LoggingAPI. Come procede l'approccio di progettazione e sviluppo e consegna dell'API di registrazione al cliente? Non mi interessa WPF o un linguaggio specifico. Voglio un LoggingAPI che deve registrare alcuni dati? qual è il tuo approccio nel fornire lo stesso.

Non ho risposto a questa domanda. Per favore guida come procedere per rispondere a questo tipo di domande.

    
posta venkat 27.04.2013 - 08:08
fonte

2 risposte

7

La domanda dell'intervista non è abbastanza chiara. Un client ha bisogno di un'API di registrazione per fare cosa? Cosa c'è che non va nelle funzionalità esistenti di .NET Framework?

Caso 1: stavano testando le tue capacità di analisi

Forse si aspettavano che tu facessi quelle precise domande, con l'intento di assicurarti di avere abbastanza esperienza nel chiarire i requisiti e capire il problema, invece di iniziare a scrivere codice senza pensare al problema stesso, come i principianti di solito lo fanno.

Come sviluppatore, ci si aspetta che tu risolva i problemi e il modo più veloce, meno costoso ed elegante, non semplicemente di digitare il codice. Quando ti viene chiesto di "creare un motore per blog che possa essere distribuito in ambiente LAMP", se il tuo primo riflesso è creare un nuovo file PHP e iniziare a digitare, lo stai facendo male. Invece, ci si aspetta che tu sappia o vada, cerchi e trovi che esiste già un prodotto chiamato WordPress che puoi usare, riducendo i costi e i tempi di consegna, mentre aumenti la qualità finale.

Nella vita reale, succede così:

— We need a logging API. What would be your approach of design, development and delivery?
— Wait, why can't you use log4net?
— Because we don't want additional libraries [one of the most stupid arguments, but sadly you rarely can reply this to the customer].
— What about .NET Framework logging?
— No. We need something powerful with lots of features.
— Ok. What features do you need which are not already available in .NET Framework?
— We need to be able to save some entries to the Windows Event Log, not simply to text files.
— This is what EventLogTraceListener does.
— Really? I didn't know that. Well, it's still not an option, because we need to include, with every trace event, the date and time of the event, as well as some debug values which are in a static class. Those values give us precious information about the state of the system.
— The date and time are added with TraceListener.TraceOutputOptions. As for the additional variables, the most straightforward way would be to extend either the TraceSource or one of the TraceListeners to include the values of those variables.

Caso 2: stavano verificando se sapete come vengono eseguite le API di registrazione

Forse si aspettavano che tu descrivessi l'architettura di una libreria di logging. Nel qual caso dovresti dire che dovrebbe avere:

  • Tipi (ad esempio verbose, informazioni, avvertenze ed errori),

  • Gli ascoltatori; ciò consente all'utente di collegare uno o più listener come quello che registra le informazioni in un file o uno che lo invia alla console o uno che salva i registri nel database o come eventi di Windows,

  • Filtraggio, vale a dire che ogni ascoltatore potrebbe voler ascoltare i registri da un componente di un'applicazione, ma non da un altro, o un ascoltatore potrebbe essere interessato solo a errori e avvertimenti, mentre un altro registrerà tutto,

Dovrebbe anche essere a conoscenza di problemi di concorrenza. Scrivere registri sullo stesso file da due thread causerebbe inevitabilmente dei problemi.

Anche la possibilità di configurare diverse opzioni, in particolare il livello di log, in fase di esecuzione (ad esempio tramite App.config) è piacevole.

    
risposta data 27.04.2013 - 10:18
fonte
3

How you go the approach of design and development and delivering Logging API to the client?

Il primo (e solitamente solo) pensiero sarebbe quello di utilizzare una delle tante librerie di registrazione esistenti mature, testate e ben conosciute. . Per quale dei due, se al cliente non interessa, usa ciò che sai meglio o ciò che sembra più popolare.

Questo è se si suppone che sia uno scenario reale, che suona come quando si parla di un cliente. Può darsi che gli intervistatori volessero veramente testare la tua comprensione di come sono progettate le API di registrazione, quindi potrebbe essere meglio chiarirlo prima.

Per ottenere l'undestanding, sarebbe meglio dare un'occhiata a varie librerie di logging per vedere cosa hanno in comune. Gli elementi tipici sono:

  • livelli di log che consentono di specificare l'importanza di un messaggio di registro e di consentire al sistema di registrare solo quelli sopra un determinato livello
  • un modo per associare i messaggi di log con i moduli (o classi, pacchetti, spazi dei nomi ...) in modo che tu possa avere output e configurazione per modulo
  • Varie destinazioni di registrazione (accedi a un file, un DB, invia email, ecc.)
  • un modo per configurare tutto quanto sopra.
risposta data 27.04.2013 - 09:57
fonte