La fonte è la documentazione - parte 1 [chiusa]

1

Cercando le specifiche per il file system btrfs mi sono imbattuto ancora una volta nel trucchetto: "Il codice è la documentazione". Ciò implica che la modifica del codice modifica la specifica.

Questo approccio ha senso mentre si lavora su un file system che verrà utilizzato da vari driver o applicazioni?

Posso capire che un piccolo gruppo può dividere il lavoro e tutti lavorano sulla sua attività. Ma come dovrebbe funzionare con un gruppo più ampio, distribuito su più punti?

(btrfs spec sarebbe ancora benvenuto)

    
posta Kitana 08.11.2014 - 21:59
fonte

2 risposte

3

I can understand that a small group can split the job and everyone works on her own task. But how should this work with a larger group, spread over several places?

Bene, se ci pensate, funziona allo stesso modo in cui funzionano tutti i progetti di sviluppo distribuiti tutti . Gli sviluppatori usano strumenti (ad esempio controllo della versione distribuita) e procedure che sono provate e testate per questo tipo di situazione.

E la prova è che questo approccio funziona davvero ... se fatto correttamente.

Una cosa che funziona a favore dell'approccio "the code is the spec" per un file system, è che un file system Linux richiede solo un'implementazione master singola. Dal punto di vista degli sviluppatori, non c'è bisogno di implementazioni multiple di (diciamo) BTRFS, e certamente non c'è bisogno di re-implementazioni indipendenti (ad esempio clean room). Se lo guardi dal loro punto di vista , non c'è alcun valore per loro nello scrivere una specifica, creare un comitato per gestire le modifiche alle specifiche e limitarsi a conformarsi alle specifiche.

Commenti di jmoreno:

For something like a file system, I would expect a reference implementation and/or a test suite, which would be the documentation.

Si potrebbe dire che l'implementazione principale è l'implementazione di riferimento e la suite di test principale è la suite di test di riferimento. L'unico problema è che la suite di test sarà stata progettata come una suite di test delle funzionalità per l'implementazione master (di riferimento) anziché come una suite di test di conformità per tutte le possibili implementazioni di una (ipotetica) specifica.

    
risposta data 09.11.2014 - 01:40
fonte
1

Non sono d'accordo: i test sono la documentazione / specifica. Il codice è la documentazione di come è stato implementato .

I test sono stabili, longevi, pubblicabili e leggibili dalla maggior parte (non pubblichi il test code , solo ciò che viene testato). L'implementazione è impermanente, o almeno non vi è alcun requisito o aspettativa che sia permanente e il codice non è realisticamente pubblicabile (solo gli sviluppatori possono decifrarlo).

Il mio team utilizza il framework di test di Spock, che può pubblicare report. Pubblichiamo questi rapporti come nostre specifiche: il nome del test descrive il comportamento. Ogni volta che viene richiesto un cambio di specifica, creiamo un test che cattura il comportamento desiderato, quindi il codice per rendere il test verde (BDD).

Btw Posso consigliare Spock.

    
risposta data 10.11.2014 - 23:38
fonte

Leggi altre domande sui tag