Come faccio a gestire il codice di scarsa qualità fornito da una terza parte?

Se non avevi impostato le linee guida sulla codifica all'inizio che dovevano rispettare, dubito che ci sia molto che puoi fare.

A meno che la scarsa qualità non stia introducendo problemi di sicurezza o semplicemente non funzioni, il controllo di problemi di sicurezza comuni potrebbe essere la soluzione migliore.

Devi:

• Imposta i requisiti di qualità . La qualità è molto soggettiva e dovrebbe essere definita da te.
• Esegui revisioni frequenti del codice leggendo il codice dal repository. Questa è la tua responsabilità. Le società terze non possono eseguire la revisione finale della qualità.

Oltre a questa risposta, ti suggerisco di leggere questo Suggerimenti per evitare di lavorare su un progetto in outsourcing .

Come notato da @ G3D, cercare di salvare il progetto dopo che il danno è stato fatto è difficile nella migliore delle ipotesi. Se qualcuno della parte della tua azienda ha già accettato (la maggior parte) i deliverable dal subappaltatore, potrebbero non esserci metodi legali per recuperare le perdite.

Se il subappaltatore ha soddisfatto i criteri di accettazione predefiniti (per quanto bassi fossero), allora perdi. Se riesci a trovare alcuni problemi lì (vale a dire che l'accettazione non è stata fatta rigorosamente secondo i criteri predefiniti), potresti essere in grado di metterli sotto pressione e, insieme a una migliore garanzia della qualità, ottenere una migliore qualità. Tuttavia, migliorare il codice scritto male in seguito è sempre un compito enorme, richiedendo molto tempo e impegno, indipendentemente da chi lo fa.

Penso che sia più un problema aziendale / gestionale / legale, e non legato alla programmazione. Immagina di vendere un prodotto e il tuo partner consegna la confezione per questo prodotto. Cosa puoi fare se la confezione è pessima?

• Negozia con il tuo partner per offrire qualcosa di qualità superiore,
• Cambia il tuo prodotto per cercare di adattarlo alla scarsa qualità di ciò che viene fatto dal tuo partner,
• Sue il tuo partner.

Nell'ultimo caso, puoi farlo solo se il contratto è stato sufficientemente preciso. Ad esempio, unendo qualità e amp; requisiti di stile per il contratto è una buona idea per evitare questo tipo di problemi. Ad esempio, lavoro in un'azienda in cui lo stile e la qualità della codifica sono molto importanti, quindi quando trattiamo con i subappaltatori, il contratto precisa sempre che la conformità a FxCop e StyleCop è obbligatoria (per C #, abbiamo anche i nostri standard di codifica per CSS o HTML codice, ecc.) e qualsiasi codice non conforme non sarà accettato.

Se nel tuo contratto attuale non ci sono cose del genere, beh, non puoi inventare qualità e amp; linee guida di stile ora e costringi il tuo appaltatore a usarle.

Quindi stai con altre due soluzioni. Se hai una posizione strong rispetto al tuo partner, puoi negoziare un codice di qualità superiore. Oppure, in tutti i casi, puoi chiedere di fornire un lavoro migliore per più soldi o altri vantaggi, o trascorrere del tempo migliorando il codice esistente da solo.

Non dici come devi usare il codice. Se puoi per lo più trattarlo come una scatola nera, il modo in cui è scritto non è al momento importante. Se devi modificarlo, hai più problemi.

Il tuo partner è ancora responsabile della funzionalità del codice, oppure è completamente fuori dai guai in caso di bug o funzionalità mancanti? Fa quello che dovrebbe ora, indipendentemente da quanto sia brutto? Quanto è probabile che la funzionalità cambi in futuro?

In queste circostanze, dovrai preparare le cose per la spedizione, che ti piaccia o no, e sai meglio di noi che cosa comporti. Per il futuro, puoi essere coinvolto nelle trattative contrattuali?

Chiedi a terze parti perché hanno implementato questo modo, prova a capire quali motivazioni hanno avuto nel fare ciò che hanno fatto, se il loro ragionamento è ok, spiega loro il tuo approccio e le pratiche seguite dalla tua azienda.