Vieta le chiamate a funzioni / classi arbitrarie nel codice esterno

Are there any reliable and reasonably straightforward ways to achieve these constraints on external code, except from certain specific places in our own code?

Poiché la domanda riguarda specificamente C #, esiste una soluzione basata sul compilatore che può essere utilizzata qui per applicare tali regole: Roslyn Analyzer . È possibile scrivere il proprio analizzatore che segnala l'accesso a determinate API come errore o avviso di compilazione.

Un set di analizzatori di esempio, che fornisce un sacco di codice di esempio per scrivere da solo, sono gli StyleCop Analyzer , che sono un sostituzione della vecchia funzionalità StyleCop per C #.

Detto questo, questi assegni automatici possono sempre essere risolti da gente determinata a "infrangere le regole". Pertanto questo approccio non è un sostituto per le revisioni del codice, come discusso nella risposta di Karl Bielefeldt. Può aiutare con tali recensioni, ma non dovrebbe sostituirle.

Puoi fare cose che richiedono tempo come scrivere un wrapper attorno all'API esterna che lascia fuori le tue operazioni indesiderate, ma niente batte le revisioni del training e del codice, perché qualunque standard o misura tecnica tu metta in atto, le persone troveranno modi creativi per aggirarli.

Ad esempio, abbiamo diversi servizi scritti in Scala, e una delle cose che chiediamo al momento della revisione del codice è per l'immutabilità, ma spesso lo comunichiamo come eliminare lo stackoverflow vars . Qualcuno l'altro giorno ha usato un val x: ListBuffer [Booleano] a tenere una singola variabile mutabile come unica voce nella lista. Non puoi assegnare un altro ListBuffer a x, ma puoi sostituire gli elementi dell'elenco in posizione quanto vuoi. Pessimo quanto usare un var , ma più sneaker.

In altre parole, devi controllare se le persone girano attorno alle tue soluzioni tecniche. Se quelle soluzioni tecniche sono costose e aggiungono complessità, puoi anche controllare che le stiano codificando correttamente.

La risposta di Karl è corretta al 100%. Non c'è modo di garantire la conformità. Tuttavia, oltre alla formazione e alla revisione del codice, prendere in considerazione l'uso di strumenti di analisi statica per garantire la conformità. (Nota: ho detto "in aggiunta a", in quanto è possibile ignorare anche quelli esattamente nello stesso modo in cui Karl ha dichiarato).

Il vantaggio dell'utilizzo di strumenti di analisi statica è quello di rimuovere la noiosa analisi del codice umano alla ricerca di istanze di "uso multiplo di IEnumerable" o di qualsiasi problema di prestazioni della settimana che stai guardando (o, almeno, che mi sento sempre Sto guardando). Ciò consentirà alle revisioni del codice e alla formazione di concentrarsi su questioni più "interessanti".

Per C #, in particolare, ho incluso alcuni suggerimenti di seguito. Inseriscili nell'ambiente di costruzione e sei pronto per partire. Ma, in generale, non importa quale lingua stai usando, c'è uno strumento di analisi statica là fuori da qualche parte.

Copia / incolla direttamente dalla pagina di Wikipedia, usa la pagina wiki per le informazioni e link più recenti: link

• .NET Compiler Platform (Codename Roslyn) - Framework di compilazione open source per C # e Visual Basic .NET sviluppato da Microsoft .NET. Fornisce un'API per analizzare e manipolare la sintassi.
• CodeIt.Right - Combina l'analisi del codice statico e il refactoring automatico alle best practice che consente la correzione automatica di errori e violazioni del codice; supporta C # e VB.NET.
• CodeRush - Un plugin per Visual Studio che avvisa gli utenti delle violazioni delle best practice.
• FxCop - Analisi statica gratuita per i programmi Microsoft .NET che compila in CIL. Standalone e integrato in alcune edizioni di Microsoft Visual Studio; da Microsoft.
• NDepend: semplifica la gestione di una base di codice .NET complessa analizzando e visualizzando le dipendenze del codice, definendo regole di progettazione, eseguendo analisi dell'impatto e confrontando diverse versioni del codice. Si integra in Visual Studio.
• Parasoft dotTEST: analisi statica, test delle unità e plug-in di revisione del codice per Visual Studio; lavora con le lingue per Microsoft .NET Framework e .NET Compact Framework, inclusi C #, VB.NET, ASP.NET e Managed C ++.
• Sonargraph - Supporta C #, Java e C / C ++ con particolare attenzione all'analisi delle dipendenze, al controllo automatico dell'architettura, alle metriche e alla possibilità di aggiungere metriche personalizzate e controllori del codice.
• StyleCop - Analizza il codice sorgente C # per applicare un insieme di regole di stile e coerenza. Può essere eseguito da Microsoft Visual Studio o integrato in un progetto MSBuild.

Per approfondire il suggerimento "addestramento e revisione del codice" sollevato in un'altra risposta: poiché il codice che si desidera proibire è un codice legale, non si può contare sul fatto che il compilatore lo impedisca e si dovrà fare affidamento su un processo successivo, la recensione.

Questo può (e dovrebbe) includere passaggi di revisione sia manuali che automatici:

• Prepara una lista di controllo dei problemi noti e passaci sopra nelle revisioni manuali del codice, una alla volta. Avere una riunione ricorrente per rivedere e aggiornare la lista di controllo. Ogni volta che viene catturato e analizzato un brutto bug, aggiungilo alla checklist.

• Aggiungi le regole di verifica per cercare modelli noti. Questo può essere complicato da scrivere, ma per un grande progetto, nel tempo, potrebbe essere utile. TFS consente di scrivere regole in C # e altri sistemi di generazione hanno i propri ganci. Prendi in considerazione l'uso di build gated per rifiutare i check-in che corrispondono al pattern. Sì, rallenta lo sviluppo, ma dopo una certa dimensione e complessità del progetto, rallentare gli sviluppatori può essere una buona cosa.

Forse il compilatore può aiutarti a recuperare le chiamate indesiderate.

Rinomina classi / metodi di codice nella tua lib che non dovrebbero essere usati dai client lib esterni. In alternativa, rendi le classi / i metodi interni e aggiungi internals visibili a quelle classi che possono usarli.

Gli utenti di lib esterni otterranno un metodo di errore di compilazione / classe non trovato.

Classi / metodi proibiti da librerie pubbliche: crea lo stesso spazio dei nomi / classe / metodo nella tua lib

Gli utenti di lib esterni riceveranno un errore di compilazione a causa della classe duplicata trovata

[update]

It's not necessary to absolutely under every circumstance prevent access to these methods/classes, for example by reflection or just some kind of disabling, ....

forcing the programmer (... client of the lib...) to actively take measures to override these constraints if possible/needed.