Perché alcuni programmatori pensano che ci sia un contrasto tra teoria e pratica? [chiuso]

Confrontando l'ingegneria del software con l'ingegneria civile, sono stato sorpreso di osservare un diverso modo di pensare: qualsiasi ingegnere civile sa che se vuoi costruire una piccola capanna nel giardino puoi semplicemente ottenere i materiali e andare a costruirla mentre se vuoi costruire una casa di 10 piani (o, per esempio, qualcosa di simile a questo ) è necessario fare abbastanza alcuni matematica per essere sicuri che non cadrà a pezzi.

Al contrario, parlando con alcuni programmatori o leggendo blog o forum trovo spesso un'opinione diffusa che può essere formulata più o meno come segue: la teoria e i metodi formali sono per matematici / scienziati mentre la programmazione è più su come fare le cose .

Ciò che normalmente è implicito qui è che la programmazione è qualcosa di molto pratico e che anche se metodi formali, matematica, teoria degli algoritmi, linguaggi di programmazione chiari / coerenti, ecc., Possono essere argomenti interessanti, spesso non sono necessari se tutto ciò che si vuole è ottenere cose fatto .

Secondo la mia esperienza, direi che mentre non hai bisogno di molta teoria per mettere insieme uno script di 100 righe (la capanna), per sviluppare un'applicazione complessa (l'edificio di 10 piani) hai bisogno di un design strutturato, beh metodi definiti, un buon linguaggio di programmazione, buoni libri di testo in cui è possibile cercare algoritmi, ecc.

Quindi la teoria dell'IMO (la giusta quantità di) è uno degli strumenti per ottenere risultati .

La mia domanda è: perché alcuni programmatori pensano che ci sia un contrasto tra teoria (metodi formali) e pratica (fare le cose)?

È l'ingegneria del software (software edificio) percepito da molti come facile rispetto a, per esempio, ingegneria civile (costruzione di case)?

Oppure queste due discipline sono davvero diverse (a parte il software mission-critical, il fallimento del software è molto più accettabile del fallimento della costruzione)?

Cerco di riassumere, quello che ho capito dalle risposte finora.

1. A differenza dell'ingegneria del software, nell'ingegneria civile è molto più chiaro quale quantità di teoria (modellistica, progettazione) sia necessaria per un determinato compito.
2. Ciò è in parte dovuto al fatto che l'ingegneria civile è vecchia quanto il genere umano, mentre l'ingegneria del software esiste solo da alcuni decenni.
3. Un altro motivo è il fatto che il software è un tipo di artefatto più volatile, con requisiti più flessibili (può essere consentito l'arresto anomalo), diverse strategie di marketing (un buon design può essere sacrificato per poterlo immettere rapidamente sul mercato), ecc.

Di conseguenza, è molto più difficile determinare quale sia la giusta quantità di progettazione / teoria appropriata nell'ingegneria del software (troppo poco -> codice disordinato, troppo -> non riesco mai a finire) perché non esiste una regola generale e solo (molta) esperienza può aiutare.

Quindi, se interpreto correttamente le tue risposte, questa incertezza su quanta teoria è davvero necessaria contribuisce ai sentimenti misti di amore / odio che alcuni programmatori hanno nei confronti della teoria.

Penso che la differenza principale sia che con l'ingegneria civile, la fisica del mondo reale agisce come un costante e potente controllo della realtà che mantiene sana la teoria e limita anche le cattive pratiche, mentre nell'ingegneria del software non esiste una forza altrettanto forte per mantenere anche concetti impraticabili della torre d'avorio come lavorazione scadente sotto controllo.

Molti programmatori hanno avuto brutte esperienze con la teoria della fuga che diventa un impedimento attivo per ottenere risultati (ad es. "UML eseguibile", processi di sviluppo super-burocratici). Al contrario, hack e patch sporchi possono portarti dannatamente lontano, anche se alla fine lentamente. E come osservi nel tuo ultimo paragrafo: i fallimenti di solito non sono così definitivi e quindi non così problematici.

L'ingegneria del software e l'ingegneria civile hanno poco in comune. Gli sforzi di ingegneria civile sono limitati dalle proprietà fisiche dei loro materiali e dell'ambiente. Gli ingegneri civili impiegano molto tempo a conoscere le proprietà del suolo e le caratteristiche dei materiali. Lo sviluppo del software è fisicamente limitato solo dalla velocità dei processori e dalla memoria disponibile. Entrambi sono facili da capire e non passiamo molto tempo a studiarli. La principale limitazione allo sviluppo del software è l'intelletto umano. E non ci sono due sviluppatori uguali. Questo codice è mantenibile? Da chi? Un'implementazione su tre righe di quicksort in Haskell può ovviamente essere corretta per alcuni, ma incomprensibile per altri. Una squadra di due può completare una domanda in un mese, mentre un'altra squadra di dieci fatica a consegnare in un anno.

Lo sviluppo del software è tutto design, i manufatti in fase di progettazione sono ordini di grandezza più complessi di qualsiasi articolo fabbricato e ognuno è unico.

Come ingegnere meccanico più o meno onesto (con qualche civile) diventato programmatore, poi dottore di ricerca in CS (AI), poi insegnante, poi di nuovo programmatore (mi scusi, ingegnere del software ), ho una passione per questa materia generale.

Nell'ingegneria tradizionale

• devi conoscere la tua matematica e scienza perché tutto ciò che fai è basato su di esso
• gli "eroi" sul campo sono persone che inventano cose nuove, scoprono nuove idee, risolvono problemi considerati irrisolvibili

Esiste una "fisica" che si applica al software - teoria dell'informazione, ma gli ingegneri del software ne hanno poca esposizione, e certamente nulla viene applicato. La maggior parte della teoria che ottengono è calcolabilità e big-O.

Inoltre sono continuamente stupito dalle persone che pensano che conoscere la programmazione sia sufficiente e non hanno bisogno di capire l' argomento di cosa trattano i loro programmi.

Inoltre, l'inventiva non è incoraggiata. È scoraggiato, a favore di metodi di pensiero di gruppo dal minimo comune denominatore, mascherato da "leggibilità". (Immagina se gli ingegneri aeronautici o nucleari fossero incoraggiati a non fare nulla che potesse essere difficile da capire per i loro coetanei.)

Le cose che imparano, come come programmare app Web, sono di grande valore. Lo stesso vale per un idraulico o un elettricista, ma non è ingegneria.

Se taglio un angolo sulla maggior parte dei software e faccio qualcosa che non è il miglior design, ma riuscirò a fare il lavoro, nessuno morirà. È la stessa ragione per cui una capanna in giardino non ha bisogno degli stessi standard di un edificio di 10 piani. Tuttavia, posso creare un'app molto grande come Facebook, e se rovina e perde alcuni dati, o qualsiasi altra cosa, non è proprio un grosso problema. È anche più semplice correggere le fondamenta di un'app di grandi dimensioni dopo il fatto, piuttosto che sostituire le fondamenta di un edificio a 10 piani. Tutto dipende dal contesto e dal calcolo del rischio.

Posso anche, in sicurezza e semplicemente continuare ad aggiungere a un'app. Non puoi facilmente lanciarti in un nuovo terzo piano di un edificio di 10 piani (rendendolo 11). Posso aggiungere ogni giorno una nuova funzionalità a un'app di grandi dimensioni, se lo desidero.

Ora, un buon design semplifica tutto questo nella programmazione. Ma non è impossibile con un design scadente e i rischi, sono ... software difettoso. Di solito non la morte.

Abbi pazienza con me su questo. Ho ragione.

Una volta un professore mi ha detto che la procrastinazione porta a una procrastinazione ancora maggiore, anche se la maggior parte delle persone dopo una notte di duro lavoro di scrittura / stipazione / programmazione di documenti si dice: "Non lo farò mai più. La prossima volta, inizierò presto e fatti presto ". Nella mia esperienza di procrastinatore consumato, ho scoperto che questo è vero, ed ecco la spiegazione del professore perché: non importa quanto sia spiacevole l'esperienza di procrastinare, nella maggior parte dei casi, si ottiene dopo aver ottenuto un relativo successo. Questo è un comportamento ad alto rischio / alta ricompensa. Dopo un po ', ti dimentichi di tutta la spiacevolezza e ricordi solo la ricompensa. Quindi, la prossima tentazione di procrastinare è ancora più allettante, perché ci sei riuscito l'ultima volta.

Penso che qui si possa fare un'analogia con la tecnica di programmazione "fare le cose" che troppo spesso vediamo. Un programmatore o un team di programmatori, forse per ignoranza, pigrizia o forse un vero vincolo di tempo, adotta l'approccio "fai cose" alla programmazione, gettando tutta la tua teoria, matematica e buone pratiche fuori dalla finestra. E tu sai cosa? Hanno fatto le cose. Non è elegante, carino o mantenibile, ma fa il lavoro. Forse un superiore non tecnico che non conosce un punto e virgola da un semaforo dà loro elogi per "aver fatto le cose". Quindi, la prossima volta che il programmatore è tentato di adottare questo approccio lento alla programmazione, è ancora più semplice, perché ehi, ha funzionato l'ultima volta, vero? È la "facile" via d'uscita, a meno che tu non sia il povero,

Sono stata quell'anima povera e sfortunata, e così probabilmente molti di voi. Vi imploro tutti. Non uscire facilmente! :)

La tua premessa è difettosa. Il motivo principale per cui gli ingegneri civili utilizzano l'ingegneria durante la progettazione di grandi edifici, ponti, gallerie, ecc. È quello di garantire che stiano utilizzando una quantità minima di materiale (cemento, acciaio strutturale, ecc.) Che soddisfi gli standard di sicurezza richiesti. È del tutto possibile costruire un edificio alto senza molto in termini di matematica (ad esempio le piramidi delle antiche civiltà egizia e maya) se i costi del materiale e del lavoro non sono un oggetto, ma una volta costruiti, di solito non ha senso modificare per farli utilizzare il materiale in modo più efficiente.

Esiste una dinamica leggermente diversa nella progettazione di grandi sistemi software. Semmai, di solito sono sotto-progettati, ma questo perché il progetto può essere modificato in modo dinamico man mano che il lavoro procede, il che semplicemente non può essere fatto così facilmente con progetti di ingegneria civile.

Il fattore comune è il costo. La progettazione su un progetto di ingegneria civile tradizionale riduce i costi (sia effettivi, in termini di materiale, sia potenziali in termini di responsabilità), mentre arriva un punto nello sviluppo del software in cui il costo della progettazione aumenta oltre il valore restituito.

Vorrei anche sottolineare, oltre a diverse altre eccellenti risposte, che l'umanità ha fatto l'equivalente di "ingegneria civile" fin dai tempi degli egiziani, quindi abbiamo avuto molto tempo per perfezionare la teoria generale di come le cose dovrebbero essere fatto. Costruiamo software da qualche parte circa 70 anni circa (a seconda di ciò che consideri il primo "software"); Voglio dire che non abbiamo avuto la stessa quantità di tempo per sviluppare lo stesso tipo di esperienza.

I progetti di un architetto / ingegnere civile non sono praticamente mai identici ai piani "come costruiti". Qualcosa cambia SEMPRE. Perché? Perché ci sono e saranno sempre "sconosciuti sconosciuti". Ci sono cose che sai e quindi puoi pianificare, cose che conosci sono sconosciute e quindi puoi fare ricerche e stimare, e poi ci sono cose che non sai di non sapere; "sorprese". Il tuo obiettivo è quello di eliminarli nella maggior parte dei sistemi imparando tutto ciò che puoi, ma tutto ciò che serve è una piccola violazione del codice di costruzione (che potrebbe essere basata su una regola che non esisteva 2 anni fa quando il tuo edificio veniva concettualizzato) e tutto - il piano generale di accompagnamento deve cambiare, a volte abbastanza drasticamente.

Il software è molto simile a questo; c'è sempre uno sconosciuto sconosciuto. Tuttavia, a differenza dell'ingegneria civile o strutturale, lo sviluppo del software è intrinsecamente molto più tollerante nei confronti del cambiamento in base ai problemi che le incognite sconosciute creano. Se stai costruendo un edificio di 10 piani e hai sopravvalutato la capacità portante della fondazione che hai inserito nel tuo progetto, non puoi costruire l'edificio su 10 piani o devi strappare una notevole quantità di lavoro per tornare alla fondazione e rinforzarla o ricostruirla. Tuttavia, nel software, se hai sottovalutato le richieste su un determinato livello della struttura generale della soluzione, ci sono molte opzioni per correggere quel livello che non comportano l'invalidazione di tutto il resto del lavoro. Puoi sostituire un singolo server DB con uno più potente o un cluster di replica / failover, o un cluster di bilanciamento del carico / distribuito. Lo stesso vale per il server web. Se hai codificato un algoritmo inefficiente ma semplice in base a ipotesi errate delle dimensioni dell'input, puoi quasi sempre semplicemente rimuovere e riscrivere l'implementazione in modo relativamente chirurgico, senza influire su altri codici che conoscono l'algoritmo (chiama e passa l'input a o si aspetta un output da esso).

Questa relativa facilità di modifica consente a un ingegnere informatico di programmare in base a ciò che sa senza preoccuparsi indebitamente di ciò che non conosce. Ciò consente un'applicazione lassista della teoria e della progettazione concettuale iniziale; ti tuffi e lo fai, e lungo la strada trovi le cose che hai codificato che devono cambiare e cambiarle. Devi ancora conoscere i concetti e la teoria, perché quando un problema viene scoperto sono quelle cose che ti aiuteranno a identificare la causa e creare una soluzione. Ma ti è permesso prendere una decisione immediata senza soccombere alla "paralisi dell'analisi", perché se si scopre che hai preso la decisione sbagliata sulla base di qualcosa che non sapevi o non hai tenuto conto dei tuoi "calcoli", il l'errore è più facile da correggere.

La differenza è principalmente dovuta ai requisiti noti:

• Dal punto di vista della teoria, tutto è definito in anticipo, quindi puoi sapere esattamente di cosa hai bisogno prima di iniziare.
• In pratica, spesso non sono tutti presenti oppure scopri qualcosa a metà dell'implementazione che ti costringe a riprogettare qualcosa. Quindi è molto meglio saltare con disegni almeno rudimentali, in modo da poter scoprire presto questi problemi.

Inoltre, quando si parla di "teoria", di solito significa il lato teorico dell'informatica, piuttosto che l'ingegneria del software. Questa è la parte dell'informatica che riguarda in gran parte la ricerca di algoritmi migliori e più efficienti, dimostrando se qualcosa è o non è possibile (P e NP, per esempio), e così via. Anche se è bene avere questi nella tua mente, non si presentano molto spesso nello sviluppo di software.

Usiamo le librerie per quel tipo di cose il più possibile.

In realtà ci sono alcuni livelli di ingegneria del software a seconda di cosa sta facendo il software che stai costruendo.

La NASA ha bisogno di software per controllare le navette con equipaggio nello spazio, quindi naturalmente il livello del processo di ingegneria è molto più rigoroso di quello della costruzione di un sito Web per mostrare le immagini dei missili.

Uno dei miei collaboratori che ha lavorato per la NASA in precedenza ha descritto il loro processo di ingegneria del software come la scrittura di centinaia di pagine di giustificazione e centinaia di ore di incontri per giustificare la scrittura di una singola riga di codice!

Non fraintendetemi perché non sto cercando di sembrare irrispettoso quando dico questo, ma anche dopo tutto quel costo di tempo, risorse e miliardi di dollari, la navetta spaziale è ancora esplosa.

Anche gli ingegneri civili sanno che, indipendentemente da quanta teoria abbiano messo in un progetto, qualcosa alla fine lo romperà, quindi devono anche sviluppare piani di emergenza.

Quando si crea un software, il costo di un arresto anomalo raramente causa la perdita di vite umane, quindi è molto più semplice gettare rapidamente materiale e testarlo. Concordiamo sul fatto che fare le cose rapidamente si traduce in codice debole. Anche se questo è sempre il caso, vedere il software in azione è il modo migliore per uno sviluppatore di vedere dove è debole e deve essere reso più forte rispetto a dove è debole e ancora molte volte più forte di quanto deve essere per stare al passo con il carico.

Per riassumere, Premature optimization is the root of all evil o come direbbe sempre il mio capoShipping is a feature!

Molte buone risposte qui, ma penso che il confronto tra Informatica e Ingegneria civile sia imperfetto.

A rigor di termini, ciò che fanno gli sviluppatori di software professionali è più simile all'ingegneria del software che all'informatica. Un'analogia migliore è che l'Informatica è la fisica per l'ingegneria del software. Allo stesso modo, Civil Engieering è una raccolta di semplificazioni e approssimazioni della fisica per costruire praticamente cose.

Immagino che gli ingegneri civili debbano raramente tenere conto della relatività generale quando svolgono il loro lavoro. Gran parte dell'ingegneria civile può essere costruita in modo sicuro nella Meccanica newtoniana. Allo stesso modo, l'ingegneria del software può essere realizzata con grande successo con una comprensione approssimativamente approssimativa dell'informatica teorica.

La grande differenza è che i ponti, i grattacieli e altri prodotti dell'ingegneria civile sono cose ragionevolmente ben comprese. Gli ingegneri del software stanno spesso costruendo nuovi costrutti o usando nuovi metodi per costruire cose ben comprese. L'ingegneria del software è molto meno matura dell'ingegneria civile, e probabilmente continuerà ad essere vera per il prossimo futuro.

TL; DR : la teoria e la pratica sono diverse nell'ingegneria del software proprio come lo sono dappertutto. L'analogia corretta è Ingegneria del software: Ingegneria civile :: Informatica: fisica. Ma in pratica, è un po 'più complesso di così :)

Quindi la mia domanda è: perché alcuni programmatori pensano che ci sia un contrasto tra teoria (metodi formali) e pratica (fare le cose)?

La costruzione di software è diversa dalla costruzione di un ponte. Nel software, ci sono molti oggetti da costruire che possono o non possono essere definiti all'inizio. Esistono standard per aumentare la facilità di manutenzione e collaborazione degli sviluppatori, non aderire a formule matematiche arbitrarie o altri ideali simili. Ad esempio, quando si seleziona il comportamento in base a una variabile, a volte ha senso utilizzare un interruttore, altre volte un modello di fabbrica. Dipende dalla facilità di manutenzione e dai punti di dolore identificati come problemi di prestazioni.

Un altro esempio può essere fatto con la manipolazione dei dati. Spesso ha senso utilizzare i delegati nel contesto di .NET. Non è così facile in Java perché non ha il supporto del framework per lo stile di programmazione funzionale di .NET. In altre parole, nel caso generale non è semplicemente possibile eseguire X nella situazione Y. Ciò è dovuto al fatto che X e Y dipendono dal numero N di fattori variabili.

L'ingegneria del software (software per l'edilizia) è percepita da molti come paragonabile, per esempio, all'ingegneria civile (costruire case)?

Non sono sicuro che "facile" sia il termine corretto. Una mancanza di prove tangibili può portare alla percezione che nessun lavoro viene svolto. O, allo stesso modo, il lavoro esistente può essere facilmente modificato.

Oppure queste due discipline sono davvero diverse (a parte il software mission-critical, il fallimento del software è molto più accettabile del fallimento della costruzione)?

L'ingegneria tradizionale e l'ingegneria del software sono molto diverse per i motivi che ho già affermato.

La tua percezione potrebbe essere sbagliata qui, o include molte risorse da persone che non hanno scritto software sufficientemente complesso.

La tua esperienza è in linea con ciò che direbbe la maggior parte delle persone che conosco (che hanno progettato e scritto software sufficientemente complesso).

Detto questo, quando si tratta della maggior parte dei programmatori , quando il compito di scrivere qualcosa arriva a loro il design ("la matematica" come lo si dice) è già stato fatto dall'architetto / lead / etc. prima che il compito di scrivere arrivi a loro. Quindi potrebbe apparire così dal livello della prima linea.

Penso che la ragione di questo contrasto sia che il ciclo di vita di un progetto software e un progetto hardware o architettura è diverso. La maggior parte dei software si evolve gradualmente, non è pianificata dall'inizio alla fine. Gli sviluppatori di software possono applicare un approccio iterativo allo sviluppo: pianificare, implementare e ascoltare il feedback. Se il feedback è positivo, continua, non farlo - fai un passo indietro e riconsidera la tua strategia. Ecco perché gli sviluppatori di software hanno cose come lo sviluppo agile, il prodotto minimo praticabile e così via.

Gli ingegneri civili non hanno questo lusso. Per loro, una volta pianificato qualcosa, non è possibile cambiarlo facilmente, come con il software, perché il costo di tali cambiamenti può essere terribile. Per lo sviluppo del software, d'altra parte, non costa molto, e questo può essere usato a loro vantaggio.

Ma non tutti i settori dello sviluppo software possono permettersi un simile approccio. Realizzare software, ad esempio, per servizi di aviazione o medici richiede una pianificazione molto attenta e molti calcoli precedenti.

Mi sembra lo stesso. Costruisci un grande edificio con blocchi standard, calcestruzzo standard, acciaio standard. Costruisci una grande app con librerie standard.

Non provi e provi matematicamente formalmente una grande app nello stesso modo in cui non provi a scrivere la funzione d'onda per un edificio di 100 piani

Ero un ingegnere meccanico e di produzione prima di scoprire circa 20 anni fa che le mie attitudini risiedevano nel software. Sono d'accordo con molti degli elementi che hai esposto.

Sospetto che la vera natura del problema riguardi il modo in cui facciamo le cose. Ora abbiamo circa dieci anni di sviluppo agile sotto le nostre cinture collettive e il messaggio è chiaro. Non progredire per livelli; progressi per funzionalità. Certo: ci saranno progetti in cui è necessario progredire per livelli (ad esempio, costruire il proprio stack di rete prima del proprio server Web) ma per la stragrande maggioranza dei progetti del mondo reale, abbiamo imparato la lezione che offre funzionalità funzionanti, una o poche una volta, è molto più efficace costruire enormi teorie non testate e poi provare a metterle in atto.

Quindi prendiamo il tuo esempio di capanna (di solito parlo di costruire un ponte lanciando un tronco attraverso un flusso contro un ponte sospeso lungo un chilometro ... qualunque cosa!), E portalo nel mondo dell'ingegneria del software. La differenza principale che vedo è che nel software, la maggior parte del lavoro è su una scala che non ha bisogno di una grande modellazione iniziale per avere successo. L'errore del principiante è spesso quello di presumere che le cose abbiano bisogno di più di quello che realmente fanno, e per la maggior parte di noi, avendo commesso quell'errore alcune volte, siamo cari di rifarlo troppo spesso.

Nessun argomento: ci sono progetti che devono iniziare con un comitato di 17 architetti del software. In verità sono rari circa 20 diamanti a carati.

Penso che l'analogia sia difettosa. Per quanto ne so, l'ingegneria civile non ha lo stesso tipo di basi teoriche dell'informatica; l'informatica è nata dalla matematica teorica, come le macchine di Turing. L'ingegneria civile riguarda la creazione di strutture che resistono alla madre natura e che magari abbiano un bell'aspetto. Ancora una volta, non so davvero molto dell'ingegneria civile, ma non credo che ci siano equivalenti di ingegnere civile di P vs NP, il commesso viaggiatore e altre cose divertenti su cui battere il cervello. E c'è sicuramente un posto per la nostra teoria dell'informatica: se qualcuno risolve il commesso viaggiatore o l'arresto del problema, ci sono molti nuovi fantastici progressi. Ma per un ingegnere del software, il cui compito è quello di progettare software, tali problemi sono davvero solo giochi e divertimento.

Ora, penso anche che dipenda da cosa intendi per "teoria". Stiamo parlando di modelli di design o di pompaggio del lemma? Perché avere una buona conoscenza dei modelli di progettazione è assolutamente fondamentale per essere un buon ingegnere del software. Tuttavia, quando si progetta un grande sistema software, teorizzare i problemi P / NP non è utile. In tal senso, credo che ci sia un netto contrasto tra ingegneria del software e informatica teorica.

O la teoria si riferisce agli algoritmi? Non passi molto tempo a scrivere algoritmi appresi nella tua classe di algoritmi. Perché? Perché in genere ne hai bisogno solo in casi particolari (e poi lo cerchi e lo cerchi) o usi una libreria già scritta per te. Non c'è bisogno di scrivere un altro classificatore bayesiano. L'astrazione è un principio importante nell'informatica. Penso che gli ingegneri del software tendano a non imparare come funziona un algoritmo fino a quando non ne hanno bisogno.

Un altro motivo è che attualmente ci sono molti metodi di sviluppo software "get it done" che sono efficaci. Ad esempio, nello sviluppo agile, non si progetta in anticipo un intero sistema. Il motivo è perché non sai ancora esattamente cosa stai costruendo: vuoi che ciò che stai facendo sia flessibile e si adatti a nuove informazioni e requisiti. Progettare tutto fin dall'inizio e poi costruire solo quello non sempre produce il miglior software. Tuttavia, non è la soluzione per tutto. Ad esempio, supponiamo che tu stia progettando qualcosa di distribuito-calcolo-cluster-pazzo-nuovo. Non è possibile eseguire alcuni schizzi di tovaglioli e avviare SCRUM.

TL; DR. Penso che ci sia qualche equivoco intorno alla parola "teoria". Tradizionalmente, la teoria si riferisce agli aspetti matematici teorici dell'informatica. A meno che tu non stia cercando nuovi metodi di elaborazione, per la maggior parte l'informatica teorica non ha alcun ruolo nella vita quotidiana di un ingegnere del software. Gli ingegneri del software si preoccupano dei modelli di progettazione e dell'architettura di sistema. I dettagli di implementazione specifici di alcuni algoritmi non sono importanti. Spesso con idee meno complicate è opportuno non progettare molto e iniziare a scrivere codice. E penso che sia qui che nasce l'idea che ai programmatori non piaccia la teoria.

Il divario tra teoria e pratica è troppo grande al momento. Quando fai la teoria, ti vengono dati tre assiomi e viene successivamente mostrato che un teorema di una riga ha una dimostrazione di mille pagine o nessuna prova. Nell'ingegneria del software, ti vengono fornite API incoerenti di migliaia di funzioni che ti danno una miriade di (cattive) maniere nell'implementazione di una funzionalità non specificata.

La vera ingegneria del software farebbe impazzire la maggior parte di quelli nel campo formale, e lo sviluppo del vero software matematico farà impazzire quelli che si occupano di ingegneria. Entrambi i campi richiedono persone di attitudini diverse e non credo che le attitudini spesso si sovrappongano.

La teoria formale presuppone che sia possibile pianificare accuratamente tutto in anticipo come un prodotto fabbricato, che il software esisterà indefinitamente all'interno dello stesso ambiente e che la soluzione di un problema astratto generale sia sempre l'obiettivo. Presuppone un ciclo di vita del software 4D come prodotto: progettare, sviluppare, distribuire, fare. La teoria formale riguarda la soluzione del problema della progettazione del software mediante analisi, astrazione, generalizzazione e previsione di cambiamenti futuri. Questo è utile se hai un problema ben definito in un dominio semplice che è facilmente analizzabile, prevedibile e abbastanza statico.

La programmazione pratica consiste nel risolvere il problema giusto (non quello della progettazione software) nel modo giusto in questo momento, in modo che i tuoi colleghi possano fare il loro lavoro meglio / più velocemente / per niente, o in modo che i ricavi possano fluire nell'azienda. Gran parte del software non è come un prodotto, mai "fatto", ma più come un essere vivente, che inizia altamente specializzato per una nicchia ecologica e può avere una durata di vita ampiamente variabile durante la quale deve risolvere problemi nuovi e non previsti in un ampia varietà di ambienti in continua evoluzione. Nel mondo degli affari, con politica e legalità e concorrenza e organizzazioni, strutture e tendenze in continua evoluzione, i requisiti sono spesso ambigui, contorti di tutti i tipi di casi speciali, mal definiti e soggetti a rapidi cambiamenti inaspettati. Non sono analizzabili, prevedibili o statici, e spesso non logico o ragionevole. È probabile che il software sia irrilevante in 2 settimane che sia ancora in uso tra 20 anni. Viene al mondo non sapendo molto o non è in grado di fare molto e deve essere nutrito, curato e allenato per tutta la vita per crescere forte, flessibile e in grado di adattarsi ai suoi ambienti in continua evoluzione e ai nuovi problemi. Se lo trascuri dopo la nascita, diventerà selvaggio se sopravvive abbastanza a lungo, e causa dolore e sofferenza, risolvendo problemi con forza schietta.

La teoria formale non risponde alle esigenze di molti software aziendali reali. Ci induce a credere che il software possa essere progettato e realizzato. Che è un prodotto che può essere riparato occasionalmente, lucidato o su cui è possibile applicare le cose, ma non un essere vivente che deve essere allevato correttamente con costante cura e attenzione per tutta la sua vita. Quindi finiamo con un codice ereditario davvero brutto, ma probabilmente la teoria formale non avrebbe aiutato.

Sembra tutto piuttosto negativo, ma in realtà adoro usare la teoria formale. Un bel design mi fa sempre sorridere. Tuttavia, questo è principalmente nella mia programmazione hobbistica che non è soggetta alle vicissitudini degli affari. Al lavoro, mi occupo principalmente di codice organico e spero solo di dargli abbastanza attenzione da crescere, rendermi orgoglioso e non essere odioso e maleducato con gli altri che devono affrontarlo.

La posta in gioco è più bassa, il lavoro è più semplice e il management vede raramente il valore in una buona progettazione. L'instabilità, la manutenibilità e l'integrità del sistema sono un problema "IT", non un problema "aziendale". Tutti i dirigenti hanno una cosa in comune. Sono concentrati al 95% sul denaro o riferiscono a qualcuno che lo è.

Il resto della battaglia è con i tuoi compagni programmatori. Molti di loro non possono o non si impegneranno a pensare a un problema prima che inizi la codifica. A causa di quanto sopra, molte di queste persone sono sviluppatori senior, rendendo ancora più difficile ottenere un buon design in produzione.

Ho visto il progetto condurre anni sprechi aggiungendo funzionalità e correzioni ad hoc ai progetti che erano rocciosi per cominciare, quindi ho abbattuto ogni tentativo di mettere ordine nel caos con frasi come "troppo complicato" o "perdere tempo". Non è piacevole assistere alla spirale di un grande progetto che porta alla sua inevitabile condanna perché la direzione non ammetterà di costruire la propria prigione su base giornaliera; tuttavia, temo che sia una sfortunata realtà a cui molti sviluppatori hanno assistito e, nel bene e nel male, da cui hanno imparato.

Cerco di trovare un mezzo nel mio lavoro. Scrivo non più di codice in progetti "contaminato" di quanto sia assolutamente necessario, e mi prendo ogni occasione per spostare la funzionalità fuori di essi. "Tra progetti", dedico tempo alla progettazione e alla pulizia dei progetti su cui ho effettivamente il controllo.

Alla fine, è un gran casino di politica e integrità personale per cui il 75% dei programmatori del mondo non ha lo stomaco. Riesco a malapena a sopportarlo, me stesso.

Innanzitutto, adoro questa domanda. Ho scritto come tre risposte di 1000 parole ed erano tutte orribilmente sbagliate quando sono arrivato alla fine.

Il problema con il tentativo di confrontare i due come analoghi, penso, è che la programmazione è un processo di modellazione che può essere astratto o strettamente legato al concreto come desideri.

La teoria dell'ingegneria strutturale, d'altra parte, è strettamente legata a insiemi molto specifici di leggi basate sulla realtà a cui devi conformarti. Non puoi semplicemente modificare il contesto o le leggi. Il problema stesso è radicato in quelle leggi. Nella programmazione, tuttavia, a volte la soluzione sta effettivamente alterando la natura della domanda o semplicemente inserendola in un contesto diverso.

Se il modello MVC, ad esempio, è perfetto, ha molto a che fare con quel contesto. Un'applicazione desktop in genere si occupa di una sola lingua e una sola lingua, senza contare i file di configurazione.

Il front-end di un'app Web è invece costituito principalmente da due lingue dichiarative (non di programmazione) e JavaScript. L'unica cosa fisica che non puoi sottrarre del tutto è il fatto che c'è sempre questo muro http per gettare le cose tra server e browser. Indipendentemente da come lo seppellisci nel codice, ciò richiede tempo e design asincrono.

Ovviamente non è possibile utilizzare un modello popolare e ben considerato come MVC per gestire le preoccupazioni del front-end sul Web esclusivamente senza alterare il modo in cui è possibile gestirlo in un contesto di app desktop. In effetti, direi che dovresti essere consapevole di ciò che rende utile MVC ma non provare nemmeno a implementarlo in modo particolarmente esigente o all'ingrosso. Il paradigma dell'app Web è unico in quanto tutta la roba look-at-me è gestita dal browser dell'utente e tutta la roba dati / modello è in genere sul server da qualche parte. Ma da dove viene questo controller? Tutti sul server o tutti sul front-end? Qualcuno deve possederlo. O forse MVC non è al 100% la soluzione migliore per lo scenario. Non male per roba back-end .NET. Non è terribile nel contesto di specifici widget dell'interfaccia utente.

Costruire una casa risolve un problema. I problemi di programmazione tipici, tuttavia, spesso implicano la risoluzione di problemi all'interno dei problemi e talvolta la soluzione è ridefinire il problema esterno. Sfortunatamente la realtà non è particolarmente entusiasta di quell'idea.

Glenn Vanderburg presenta un'ottima visione delle differenze tra ingegneria del software e discipline ingegneristiche più tradizionali: http://www.youtube.com/watch?v=NP9AIUT9nos

Se un ingegnere civile potesse testare i suoi progetti senza alcun costo prima di costruire l'ultima cosa, farebbe molto meno ricorso alla teoria. Se in pochi secondi potesse costruire un ponte mille volte gratuitamente per testare quando si romperà, lo farebbe invece di passare mesi a calcolare quando potrebbe frenare in teoria ...

Nello sviluppo del software è esattamente quello che fai. Invece di calcolare quanto velocemente il tuo algoritmo è in teoria puoi semplicemente testarlo e conoscere la risposta in pochi secondi.

In effetti, la maggior parte dei software oggi non è più limitata da vincoli fisici come la potenza di calcolo o la memoria. La limitazione del software è la complessità che si presenta nei sistemi sempre più grandi. Gestire questa complessità mantenendo il sistema comprensibile dagli umani ciò che rende oggi la grande sfida nella programmazione.