Esistono standard minimi di qualità formalizzati per lo sviluppo del software?

0

Ho aderito a una nuova grande azienda che ha idee molto diverse su ciò che costituisce la qualità nello sviluppo. Nel tentativo di convincere i manager su cosa dovrebbe cambiare, ci sono documenti ben accettati sulle pratiche di sviluppo in un ambiente agile?

Lavoriamo nello sviluppo mobile e gli sviluppatori esistenti sono più preoccupati della velocità e delle scadenze, piuttosto che dei seguenti ...

  • test delle unità,
  • copertura del test%
  • revisione del codice,
  • avere eventuali richieste di unione / pull
  • utilizzando rami separati per caratteristiche contro tutti che si impegnano a dirigere verso il ramo dev.
  • cosa dovrebbe bloccare il codice che unisce / accetta richieste di pull,
posta angel of code 29.08.2016 - 00:15
fonte

2 risposte

2

I punti elenco che descrivi nella tua domanda sono tutti i modi per misurare la qualità del codice o i processi di supporto. Mentre tentano di verificare che il tuo codice soddisfi una particolare qualità standard e forniscono alcuni strumenti organizzativi, in realtà non producono codice di buona qualità. Le pratiche di sviluppo del software sensibili lo fanno.

Prendiamo i tuoi proiettili a turno:

Test dell'unità

Lo scopo del test unitario è di validare la funzionalità del metodo, fornire un po 'di automazione del test, consentire al refactoring di procedere senza rompere il codice esistente e incoraggiare un buon design. Entrambi crediamo che sia una buona pratica, ma ci sono programmatori che possono produrre un buon codice senza test unitari. Come fai a dire a quelle persone che ora devono farlo a modo tuo?

Copertura dei test

Per lo più un'aringa rossa, con un alto grado di copertura dei test, si ritiene che mostri e dimostri che il tuo codice funziona, quando la realtà è che semplificare il codice in modo da avere meno copertura è probabilmente una pratica migliore.

Revisione codice

Quanti negozi in realtà impiegano il tempo per farlo? Devo ancora lavorare in uno.

Avere richieste di unione / pull

Il flusso di lavoro Git è una scena tutta per sé. Git è un coltellino svizzero con 30 gadget, quando la maggior parte dei negozi ha probabilmente solo bisogno di 5. Hai bisogno di un buon flusso di lavoro Git? Assolutamente. Implica richieste di pull? Non necessariamente. Se sei un proprietario di un progetto su Github, ti occuperai di Pull Requests. Ma se fai parte di un team interno, non vedo come le richieste di pull siano rilevanti.

Utilizzo di rami separati per le funzioni

Questo ha qualche merito, ma la fusione può essere un processo molto difficile, ea meno che tu non sia molto disciplinato, stando fuori dal ramo principale fino a quando non hai finito con la tua funzione (e poi risolvendo gli inevitabili conflitti quando unisci il ramo indietro nel tronco principale) può diventare un incubo.

Cosa dovrebbe bloccare il codice che unisce / accetta richieste di pull

Probabilmente dovrebbe costruire. Oltre a questo, devi decidere quanta autorità di livello superiore hai bisogno. Il capo squadra rivede tutte le richieste prima di impegnarsi? Ancora una volta, non ho mai lavorato in un negozio che ha richiesto questo.

Quindi qual è il punto?

Il punto è che questi processi sono tutti cerimonia. Nessuno di essi ha nulla a che fare con la qualità del codice, tranne nella misura in cui forniscono controlli e contrappesi a qualsiasi pratica di codifica efficace sia già in atto per produrre codice di alta qualità.

    
risposta data 29.08.2016 - 23:29
fonte
1

C'è sempre il test Joel che ho vagamente ricordato e che ho immediatamente trovato come il risultato di Google più alto per "team di programmazione qualità "quindi direi che è ampiamente noto se non" accettato "e comprende i seguenti elementi:

  1. Usi il controllo del codice sorgente?
  2. Puoi creare una build in un solo passaggio?
  3. Realizzi build giornaliere?
  4. Hai un database di bug?
  5. Correggi bug prima di scrivere un nuovo codice?
  6. Avete un programma aggiornato?
  7. hai una specifica?
  8. I programmatori hanno condizioni di lavoro silenziose?
  9. Usi gli strumenti migliori che il denaro può comprare?
  10. Hai dei tester?
  11. I nuovi candidati scrivono il codice durante il colloquio?
  12. esegui test di usabilità nel corridoio?

E se non riesci a rispondere "sì" ad almeno 10 di questi hai un problema.

    
risposta data 29.08.2016 - 23:43
fonte

Leggi altre domande sui tag