Questo tipo di design per contratto è inutile?

Quando ho provato il mio corso Java, il mio professore era più o meno allo stesso modo; Il 90% del progetto stava sviluppando un diagramma di flusso e scrivendo pseudo-codice, e il programma effettivo non ha impiegato più di qualche ora per scrivere.

Da allora, tuttavia, ho continuato a scrivere i miei processi sempre di più ... non con alcun metodo particolare o altro, ma solo cercando di capire tutti gli angoli del mio programma finale. Mi sento come se avesse risparmiato tempo a lungo termine.

Quando ho iniziato a programmare, non ho bisogno di fare tutto il sovraccarico, perché i programmi che ho fatto erano banali. Quindi, ero nella tua stessa barca: "Perché stiamo perdendo tempo a fare tutto questo?"

Una volta che inizi a lavorare su produzioni più grandi, magari con un po 'di aiuto sul lato, avere un piano in inglese sarà più utile che scrivere diverse decine di righe di codice solo per cambiare idea un'ora dopo.

Quindi, non tollererei ciò che il tuo professore ti sta insegnando, anche se per una classe introduttiva è in effetti piuttosto inutile. Con progetti grandi e più oscuri, è utile scrivere il piano d'azione. Chissà, un giorno potresti lavorare per un boss dai capelli a punta che ha bisogno di sapere cosa stai cercando di fare e non parla C ++.

Infine, non pensare che il modo in cui ti viene insegnato a pianificare il tuo codice sia l'unico modo per farlo. I metodi di pianificazione sono solo strumenti come i linguaggi di programmazione che assistono.

if your program intuition is wrong you'll write your program wrong

Yup. Questo è il modo in cui è il mondo.

Quando ero ragazzo ci è stato insegnato a pensare a come il nostro programma avrebbe funzionato, a dividerlo in parti gestibili e a pensare a come quelle parti si sarebbero unite. Quindi scrivi questi pensieri per non dimenticarli. E poi, potresti scrivere il tuo programma e sarebbe privo di bug e funzionerà correttamente. Al momento molte persone si sono programmate sedendosi e iniziando a digitare, il che ha dato risultati terribili, ma hanno ottenuto la gratificazione immediata che desideriamo.

Quindi, qui ti viene insegnato a pensare per primo, codice secondo. Che il codice è quasi irrilevante rispetto al design generale. Queste cose sono vere, queste cose ti renderanno un programmatore molto migliore. Lo noterai quando uscirai dall'università e dovrai iniziare a lavorare su applicazioni del mondo reale, quelle che rendono il tuo corso di lavoro simile alle app di mickey-mouse. Quelli in cui non si lavora più con migliaia di righe di codice, ma diverse milioni di righe. Quindi capirai esattamente perché devi pensare seriamente prima di impostare il dito sulla tastiera.

Most of the time, both me and other students have written programs that seemed ok and that had correct pre and post condition too. But at the moment of testing it was just completely wrong.

Sì, questo è il motivo per cui ti sta facendo fare - se non riesci a pensare a come scrivere un programma corretto, come pensi di essere in grado, beh, di scrivere programmi corretti? Puoi scriverlo in modo iterativo usando un approccio code-test-fixbugs-code-test-fixbugs, che va bene per piccole cose, ma ancora una volta, ottieni un grande progetto e passerai una quantità impressionante di tempo per farlo funzionare correttamente.

Dimostrare formalmente la correttezza del programma che stai usando è risaputo essere estremamente arduo e adatto solo per i programmi più piccoli. La quantità di tempo necessaria per dimostrare formalmente qualsiasi cosa tranne i programmi più banali corretta è folle e non è affatto pratica.

Tuttavia, avere un design e specifiche sono strumenti essenziali, anche se non provi che i tuoi programmi siano corretti contro di loro.

Questo non è strettamente noto come Design by Contract, DBC è un termine di marketing usato dalla società di Bertrand Meyers e il concetto di usare pre-condizioni, post-condizioni e invarianti per sviluppare un programma veniva usato da Dijkstra mentre lui stava usando la programmazione strutturata.

Per programmi più grandi o per algoritmi più impegnativi è molto utile essere a conoscenza delle pre-condizioni, delle condizioni di post e degli invarianti. Possono guidare nella scrittura del programma e aiutano a rendere il tuo pensiero molto più chiaro.

Lo scenario dato / quando / allora del test unitario contiene le pre-condizioni, post-condizioni e invarianti del tuo programma. Se stai scrivendo correttamente i tuoi test, lo stai già documentando. e semplicemente bisogno di mettere il codice di prova in parole nei tuoi commenti per placare il professore.