Quali sono le caratteristiche o le caratteristiche del codice di qualità di produzione?

Naviga le tue risposte
7

Questa è la prima volta che consegnerò il codice per un progetto freelance (web-app) e, poiché non ho un codice di spedizione molto esperto, sto avendo difficoltà a decidere se il mio programma è pronto per l'implementazione oppure no.

La mia comprensione è che un codice a livello di produzione deve avere le seguenti caratteristiche:

  • Tolleranza ai guasti : capacità di sopravvivere alle eccezioni non rilevate
  • Ridondanza dei dati : non perdere mai i dati utente
  • Scalabilità : la gestione del carico aggiuntivo non richiede la riscrittura dell'app
  • Copertura del test : una quantità "decente" di codice testato

Alcune di queste caratteristiche sono specifiche del programma stesso, mentre altre sono più legate all'ambiente (se si utilizzano più cluster). Tuttavia, anche le caratteristiche dipendenti dall'ambiente influiscono sul modo in cui il programma è progettato.

La mia domanda allora è: quali sono le altre caratteristiche che rendono il codice di produzione così diverso dal codice non destinato alla produzione?

Per ridurre l'ambito della domanda, concentrati solo su app web .

Modifica : cercherò di restringere l'ambito chiedendo caratteristiche specifiche della mia situazione. Come libero professionista, ero responsabile di tutto, dall'acquisto di un VPS, alla sua configurazione, alla scrittura del codice, alla sua distribuzione. Sebbene il progetto e la sua configurazione siano ben documentati, il cliente non sarà in grado di mantenerlo. L'app non è complessa, ma dipende da molti componenti esterni, il che rende molto facile rompere se questi componenti cambiano / scompaiono. L'obiettivo è quello di creare un servizio che possa durare il più a lungo possibile senza l'intervento del cliente.

    
posta verybadalloc 09.08.2013 - 04:54
fonte

1 risposta

13

"codice di qualità di produzione" è qualsiasi cosa un altro utente, chi non sei tu, è ...

  1. in grado di utilizzare con supporto minimo o minimo. Se ogni azione viene soddisfatta con un bug, il tuo software andrà nella spazzatura
  2. in grado di capire come utilizzare con supporto o documentazione minimi. Se il tuo utente non riesce a capire come usare il tuo software, andrà nella spazzatura.
  3. disposti ad usare perché aggiunge valore. Se il tuo software aggiunge abbastanza valore, forse ti daranno anche dei soldi. Se non aggiunge abbastanza valore da darti via gratis, il tuo software andrà nella spazzatura.

ECCO.

Alcune persone hanno bisogno di una tolleranza ai guasti assoluta. Ad altri non importa se alcuni dati vengono persi in caso di crash ... presumendo che si verifichino incidenti molto rari. Non ci sono qualità o requisiti fissi. E nessun cliente si preoccupa della copertura dei test, ciò che a loro interessa sono i tre punti sopra elencati. La copertura di prova è uno strumento (uno dei tanti) che puoi usare per arrivarci, ma un sacco di software, alcuni dei quali addirittura validi, è stato costruito con nient'altro che test manuali.

Qualunque sia il software che costruisci, i requisiti sono tra te e il tuo cliente e se stai costruendo software per il consumo generale, scegli uno o pochi gruppi target e non cercare di essere tutto per tutti. Cercare di inventare una specie di muffa generica mi sembra piuttosto sciocco.

Invece, di cercare di prevedere o indovinare quando il tuo software sarà pronto per la produzione, perché non lavori con il tuo cliente? Date loro un'anteprima ma spiegate che non è pronta per la produzione. Pubblicalo sul tuo server e chiedi loro di usarlo, curiosare e darti un feedback. Continua a lavorare con loro fino a quando non sono contenti di ciò che hai dato loro. In altre parole, ti diranno quando è pronto per la produzione.

    
risposta data 09.08.2013 - 07:03
fonte

Leggi altre domande sui tag

Esiste una tassonomia software consolidata basata sul tipo di software? Quando si progetta una coda di lavoro, che cosa dovrebbe determinare l'ambito di un lavoro?