Domanda

Microsoft ha recentemente messo un rilascio dei loro contratti quadro sulla DevLabs con una licenza commerciale. Siamo interessati a utilizzarli nel nostro progetto (per lo più C #, un po 'di C ++ / CLI) per sostituire gradualmente tutto il codice di convalida personalizzato, ma sono desiderosi di conoscere l'esperienza di altre persone hanno avuto con esso prima ci impegniamo ad esso, in particolare:

  • Pensi che il quadro è sufficientemente maturo per grandi e complessi progetti commerciali?

  • Quali problemi avete incontrato durante l'utilizzo?

  • Quali benefici avete avete ottenuto da esso?

  • E 'attualmente più dolore che ne vale la pena?

Mi rendo conto che questa è una domanda un po 'soggettiva in quanto richiede opinione, ma dato che questo quadro è una parte molto significativa di .NET 4.0 e sarà (potenzialmente) cambiare il nostro modo di tutto il codice di convalida di scrittura, mi auguro che questa domanda verrà lasciata aperta per raccogliere esperienze sul tema per aiutarmi a prendere una decisione di una specifica, domanda rispondere:

  

Dovremmo iniziare ad utilizzare il mese prossimo?

Si noti che non spediamo un'API di codice, solo un servizio web uno, quindi per la maggior parte di codice di rompere la compatibilità in termini di tipo di eccezione generata non è una preoccupazione. Tuttavia, come spero più persone di appena uno mi beneficiare di questo post e le sue risposte, ogni particolare intorno a questa zona è più che benvenuto.

È stato utile?

Soluzione 2

Ho giocato in giro con il codice dei contratti ancora un po 'me stesso su un piccolo ma moderatamente complesso progetto autonomo, che ha bisogno di ereditare da alcune classi BCL e utilizzare altri.

La cosa contratti sembra grande quando si lavora in un ambiente completamente isolato con solo i tipi di codice e primitivi proprie, ma non appena si inizia a utilizzare le classi BCL (che fino a .NET 4.0 non hanno i loro contratti) il verificatore non può verificare se saranno violare una delle necessita / accerta / invarianti e così si ottiene un sacco di avvertimenti circa i vincoli potenzialmente insoddisfatti.

D'altra parte, lo fa trovare alcuni vincoli non validi o potenzialmente insoddisfatti che potrebbero essere bug reali. Ma è molto difficile trovare questi perché c'è così tanto rumore che è difficile scoprire quali è possibile correggere. E 'possibile sopprimere gli avvertimenti delle classi BCL utilizzando il meccanismo di assumere, ma questo è un po' autolesionista come queste classi avranno contratti in futuro e ipotesi sarà diminuire il loro valore.

Quindi la mia sensazione è che, per ora, perché in 3.5 che stiamo cercando di costruire su un quadro che il verificatore non sufficientemente capire, che è probabilmente la pena di aspettare 4.0.

Altri suggerimenti

L'ultima risposta matura a questo è stato nel 2009, e .NET 4 è fuori. Immagino che siamo a causa di un aggiornamento:

Contratti codice potrebbe anche essere abbastanza maturi per le versioni di debug.

Mi rendo conto che è un po 'di un aggiornamento da “Innocuo” a “Mostly Harmless”.

Il Contratti home page collegamenti alla documentazione abbastanza completa in formato PDF. La documentazione delinea linee guida di utilizzo nella sezione 5. Per riassumere, si può scegliere come ti senti coraggioso sugli strumenti di contratto ri-scrivere il IL nella build di rilascio.

Stiamo usando la modalità “non riscrivere la mia uscita IL”.

Finora, sto più a godere di questo beneficio inaspettato: c'è meno codice, quindi meno codice per testare . Tutti i tuoi clausole di guardia si sciolgono.

if(arg != null) { 
    throw new ArgumentNullException("arg"); 
}
// Blank line here insisted upon by StyleCop

diventa:

Contract.Requires(arg != null);

Le funzioni sono più brevi. Il vostro intento è più chiara. E, non è più necessario scrivere un test chiamato ArgumentShouldNotBeNull solo per raggiungere una copertura del 100%.

Finora, ho incontrato due problemi:

  • ho avuto una prova di unità che si basava su un errore di contratto per avere successo. Si potrebbe sostenere l'esistenza del test è stato un errore, ma ho voluto documentare questo particolare divieto nella forma di un test. Il test non è riuscito sul mio server di compilazione perché non avevo gli strumenti installati. Soluzione:. Installare gli strumenti

  • Stiamo utilizzando due strumenti che riscrivono IL: Code Contracts e PostSharp . Essi non andavano d'accordo troppo bene. PostSharp di 2.0.8.1283 risolto il problema. Mi piacerebbe cautamente valutare come qualsiasi due strumenti IL-riscrittura andare d'accordo, però.

Finora, i benefici sono superiori ai rischi.

Affrontare preoccupazioni out-of-date sollevate in altre risposte:

  • la documentazione del Code Contracts è abbastanza completa, anche se purtroppo in PDF.
  • C'è almeno un Codice Contratto forum ospitato da Microsoft.
  • Code Contracts Standard Edition è gratuito se si dispone di alcuna licenza VS2010.
  • .NET 4 è fuori. Ho eseguito in contratti di Microsoft in sede di attuazione delle interfacce di raccolta generici.

A giudicare dalla questa discussione direi che non è abbastanza maturo da utilizzare per un progetto di livello enterprise. Non ho usato io stesso, ma le persone sono ancora in esecuzione in bug che avrebbe portato il progetto del contratto-critical ad una battuta d'arresto. Sembra davvero un grande quadro e le video di esempio che ho fornito sono stato emozionante, ma mi piacerebbe attendere:

  • Esistenza di un forum della comunità. Stai andando a voler essere in grado di discutere i problemi inevitabili che si esegue in con altri sviluppatori, e si desidera sapere che c'è un decentemente forte base di sviluppatori fuori lì per discutere di soluzioni con.
  • Un rilascio del progetto pilota di successo. In genere, quando Microsoft Research rilascia qualcosa che pensano è abbastanza maturo per essere utilizzato in un progetto commerciale, che lavoreranno con un'organizzazione di pilota, e quindi rilasciare che progetto open source come una prova di concetto e il processo-by-il-fuoco di tutte le principali funzioni. Questo darebbe un sacco di fiducia che la maggior parte degli scenari di contratto comuni sono coperti e di lavoro.
  • documentazione più completa. Chiaro e semplice, ad un certo punto si sta andando a voler fare qualcosa con contratti che non si può fare ancora l'utilizzo di contratti codice Microsoft. Si vuole essere in grado di rapidamente e chiaramente ragione che lo scenario è non è ancora supportato. La documentazione corrente sta per tenervi indovinare e provare cose diverse, anche se, a mio parere, che si tradurrà in un sacco di tempo sprecato.

Non è abbastanza maturo.

Sarà non appena Microsoft rilascia con le edizioni a prezzi accessibili di VS, ma senza l'analisi statica del codice non è utilizzabile a tutti.

Le edizioni di VS, che hanno, sono così follemente costosa che solo una manciata di persone sarà mai in grado di permetterselo.

E 'un peccato Microsoft ha ucciso questa idea incredibile con la loro politica dei prezzi. Vorrei Contratti codice sarebbe diventato mainstream, ma non lo faranno.

Epic fail.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top