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

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 la teoria sana e limita anche le cattive pratiche, mentre nell'ingegneria del software non esiste una forza altrettanto strong per mantenere la torre di avorio impraticabile concetti così come lavori scadenti sotto controllo.

Molti programmatori hanno avuto brutte esperienze con la teoria della fuga che sta diventando un impedimento attivo per ottenere risultati (ad esempio "UML eseguibile", processi di sviluppo super-burocratici). Viceversa, hack e patches sporchi possono farti dannatamente lontano, anche se lentamente alla fine. E come osservate nel vostro ultimo paragrafo: i fallimenti di solito non sono così definitivi e quindi non altrettanto problematici.

Ingegneria del software e 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 dedicano molto tempo all'apprendimento delle proprietà del suolo e delle caratteristiche del materiale. 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 a tre righe di quicksort in Haskell può essere ovviamente corretta per alcuni, ma incomprensibile per gli altri. Una squadra di due persone può completare un'applicazione in un mese, mentre un'altra squadra di dieci si sforza di consegnare in un anno.

Lo sviluppo del software è tutto design, gli artefatti in fase di progettazione sono ordini di grandezza più complessi di qualsiasi manufatto e ognuno di essi è unico.

Come più o meno onesto ingegnere meccanico (con un po 'civile) programmatore girato, poi dottore CS (AI), poi insegnante, poi programmatore di nuovo (scusatemi, Ingegnere software ), Ho una sfuriata su questo argomento generale.

In ingegneria tradizionale

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

Esiste una "fisica" che si applica al software: la teoria dell'informazione, ma gli ingegneri del software hanno poca visibilità su di esso, e certamente nulla viene applicato. La maggior parte della teoria che ottengono è computability 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 dei loro programmi.

Inoltre, l'inventiva non è incoraggiata. È scoraggiato, a favore dei metodi di pensiero di gruppo a minimo comun denominatore, mascherati da "leggibilità". (Immagina se gli ingegneri aeronautici o nucleari fossero incoraggiati a non fare qualcosa che potrebbe essere difficile da capire per i loro coetanei junior.)

Le cose che imparano, come programmare applicazioni web, sono di grande valore. Così è l'abilità di un idraulico o di un elettricista, ma non è ingegneria.

Se metto un angolo su più software, e faccio qualcosa che non è il miglior design, ma farò 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 si rovina e perde alcuni dati, o qualsiasi altra cosa, non è davvero un grosso problema. È anche più semplice fissare le fondamenta di una grande app dopo il fatto, piuttosto che sostituire le fondamenta di un edificio di 10 piani. Tutto si riduce al contesto e al calcolo del rischio.

Posso anche, tranquillamente 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 una nuova funzionalità a un'app di grandi dimensioni ogni giorno, se lo desidero.

Ora, un buon design rende tutto più semplice nella programmazione. Ma non è impossibile con un design scadente, e i rischi sono ... un software buggato. Di solito non la morte.

Resta con me su questo. Ho un punto.

Un professore mi ha detto una volta che procrastinare porta a procrastinare ulteriormente, anche se la maggior parte delle persone dopo una notte di scrittura / cramming / programmazione cartacea ha detto a se stessi: "Non lo farò mai più. Comincerò presto e finirò presto. " Nella mia esperienza di procrastinatore consumato, ho trovato che questo è vero, ed ecco la spiegazione del professore perché: non importa quanto spiacevole sia l'esperienza di procrastinare, nella maggior parte dei casi, si ottiene un successo relativo. 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 è tanto più allettante, perché sei riuscito nell'ultima volta.

Penso che un'analogia possa essere fatta qui per la tecnica di programmazione "fai le cose" che vediamo troppo spesso. Un programmatore o un gruppo di programmatori, forse per ignoranza, pigrizia, o forse un vero e proprio vincolo di tempo, adotta l'approccio "fai le cose" alla programmazione, gettando fuori dalla finestra tutta la tua teoria, matematica e buone pratiche. E tu sai cosa? Fanno le cose. Non è elegante, carino o manutenibile, ma fa il lavoro. Forse un superiore non tecnico che non conosce un punto e virgola da un semaforo dà loro un grande elogio per "fare le cose". Quindi, la prossima volta che il programmatore è tentato di adottare questo approccio lento alla programmazione, è tutto più facile, perché hey, ha funzionato l'ultima volta no? È la via "facile", a meno che non sia la povera, sfortunata anima che eredita tale applicazione anni dopo e deve mantenerla.

Sono stato quell'anima povera, sfortunata, e quindi molti di voi probabilmente. Ti imploro tutti. Non prendere la via più facile! :)

La tua premessa è difettosa. La ragione principale per cui gli ingegneri civili utilizzano l'ingegneria durante la progettazione di grandi edifici, ponti, gallerie, ecc. È quella di garantire che utilizzino una quantità minima di materiale (calcestruzzo, 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 oggettivi, ma una volta costruiti, di solito non è necessario modificare per farli usare il materiale in modo più efficiente.

C'è una dinamica un po 'diversa nella progettazione di sistemi software di grandi dimensioni. Se non altro, di solito sono sottostimati, ma questo perché il design può essere cambiato dinamicamente con il procedere del lavoro, che semplicemente non può essere fatto facilmente con i 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 materiali, sia potenziali in termini di responsabilità), mentre arriva un punto nello sviluppo del software in cui il costo del design aumenta oltre il valore restituito.

Vorrei anche sottolineare, oltre a molte altre eccellenti risposte che l'umanità ha fatto l'equivalente di "ingegneria civile" poiché facilmente il tempo degli egiziani, quindi abbiamo avuto molto tempo per perfezionare la teoria generale di come dovrebbero essere fatte le cose Abbiamo sviluppato software per circa 70 anni circa (a seconda di quello che consideri il primo "software"); Intendo 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 sempre saranno, "incognite sconosciute". Ci sono cose che sai e quindi puoi pianificare, cose che sai essere sconosciute e quindi puoi ricercare e stimare, e poi ci sono cose che non sai di non sapere; "sorprese". Hai l'obiettivo di eliminarli nella maggior parte dei sistemi imparando tutto quello che puoi, ma tutto ciò che serve è una piccola violazione del codice edilizio (che può essere basata su una regola che non esisteva 2 anni fa quando il tuo edificio veniva concettualizzato) e tutto -il piano generale di inversione deve cambiare, a volte in modo abbastanza drastico.

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 ai cambiamenti in base ai problemi creati dagli sconosciuti sconosciuti. Se stai costruendo un edificio di 10 piani e hai sovrastimato la capacità portante della fondazione che hai inserito nel tuo progetto, non puoi costruire l'edificio a 10 piani o devi strappare una quantità significativa di lavoro a tornare alle fondamenta e rinforzarle o ricostruirle. Tuttavia, nel software, se hai sottovalutato le richieste su un particolare livello della struttura globale della soluzione, ci sono molte opzioni per aggiustare quel livello che non implica l'invalidazione di tutti gli altri lavori. È possibile 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 per il webserver. Se si codifica un algoritmo inefficiente ma semplice in base a supposizioni errate delle dimensioni dell'input, è quasi sempre possibile rimuovere e riscrivere l'implementazione in modo relativamente chirurgico, senza influire su altro codice che ha conoscenza dell'algoritmo (chiamate e passa input a esso, o si aspetta un output da esso).

Questa relativa facilità di cambiamento consente al software engineer di codificare in base a ciò che sa senza preoccuparsi eccessivamente di ciò che non sa. Ciò consente l'applicazione più lenta della teoria e della progettazione concettuale iniziale; ti immergi e lo fai, e lungo la strada trovi le cose che hai codificato che devono essere cambiate e cambiarle. Devi ancora conoscere i concetti e la teoria, perché quando viene scoperto un problema sono quelle cose che ti aiuteranno a identificare la causa e creare una soluzione. Ma ti è permesso prendere una decisione improvvisa senza soccombere alla "paralisi dell'analisi", perché se si scopre che hai preso la decisione sbagliata in base a qualcosa che non sapevi o che non ti interessava ai tuoi "calcoli", la 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 cosa ti serve prima di iniziare.
• In pratica, spesso non sono tutti lì o scopri qualcosa a metà dell'implementazione che ti costringe a riprogettare qualcosa. Quindi è molto meglio saltare con progetti almeno rudimentali, in modo che tu possa scoprire subito 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, che provano se qualcosa è o non è possibile (per esempio, P e NP) e così via. Mentre è bello averli nella parte posteriore della mente, non vengono spesso nello sviluppo del software.

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

In realtà ci sono alcuni livelli di ingegneria del software che dipendono da ciò che sta facendo il software che stai costruendo.

La NASA ha bisogno di software per controllare gli shuttle con equipaggio nello spazio, quindi il livello del processo di ingegneria è molto più rigido di quello di costruire un sito web per mostrare le immagini dei razzi.

Uno dei miei colleghi che ha lavorato per la NASA in precedenza ha descritto il proprio processo di ingegneria del software scrivendo centinaia di pagine di giustificazione e centinaia di ore di riunioni per giustificare la scrittura di una singola riga di codice!

Non fraintendermi, perché non sto cercando di sembrare irrispettoso quando dico questo, ma anche dopo tutto quel costo di tempo, risorse e miliardi di dollari che lo space shuttle ha ancora fatto saltare in aria.

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

Quando si costruisce un software, il costo di questo arresto raramente causa perdite di vite umane, quindi è molto più facile lanciare cose là fuori e provare a guidarlo. Siamo d'accordo sul fatto che fare le cose rapidamente produca un 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ù strong rispetto a dove è debole e ancora molte volte più strong di quanto debba essere per stare al passo con il carico.

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

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

In senso stretto, ciò che gli sviluppatori di software professionali fanno è più come l'ingegneria del software che l'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 la creazione di materiale praticamente.

Immagino che gli ingegneri civili raramente debbano prendere in considerazione la relatività generale quando fanno il loro lavoro. Gran parte dell'ingegneria civile può essere costruita in sicurezza in Newtonian Mechanics. Allo stesso modo, l'ingegneria del software può essere realizzata con molto successo con una comprensione approssimativamente approssimativa dell'informatica teorica.

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

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

So my question is why do some programmers think that there is a contrast between theory (formal methods) and practice (getting things done)?

Costruire software è diverso dalla costruzione di un ponte. Nel software, ci sono molti oggetti da costruire che possono o non possono essere definiti all'inizio. Esistono degli standard per aumentare la facilità di manutenzione e la collaborazione degli sviluppatori, non per aderire a formule matematiche arbitrarie o altri ideali simili. Ad esempio, quando si seleziona il comportamento basato su una variabile, a volte ha senso utilizzare un interruttore, altre volte un modello di fabbrica. Dipende dalla facilità di manutenzione e dai punti critici identificati come i 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ì semplice in Java perché non ha il supporto di framework per lo stile di programmazione funzionale di .NET. In altre parole, nel caso generale non è possibile eseguire X nella situazione Y. Ciò è dovuto al fatto che X e Y dipendono dal numero N di fattori variabili.

Is software engineering (building software) perceived by many as easy compared to, say, civil engineering (building houses)?

Non sono sicuro che "easy" sia il termine corretto. Una mancanza di prove tangibili può portare alla percezione che non si stia lavorando. Oppure, analogamente, il lavoro esistente può essere facilmente modificato.

Or are these two disciplines really different (apart from mission-critical software, software failure is much more acceptable than building failure)?

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 la maggior parte delle persone che conosco (che hanno progettato e scritto software sufficientemente complesso) direbbe.

Detto questo, quando si tratta della maggior parte dei programmatori , quando il compito di scrivere qualcosa arriva a loro il progetto ("la matematica" come lo si definisce) è già stato fatto dall'architetto / responsabile /eccetera. prima che il compito di scrivere arrivi a loro. Quindi può apparire in questo modo dal livello della prima linea.

Penso che la ragione di questo contrasto sia che il ciclo di vita di un progetto software e di un progetto hardware o di architettura è diverso. La maggior parte del 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 feedback. Se il feedback è positivo, continua, non fare un passo indietro e riconsiderare la tua strategia. Ecco perché gli sviluppatori di software hanno cose come lo sviluppo agile, il prodotto minimo vitale e così via.

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

Ma non tutte le branche dello sviluppo del software possono permettersi tale approccio. Fare software, ad esempio, per i servizi aerei o medici richiede una pianificazione molto attenta e molti calcoli preliminari.

Mi sembra uguale. Costruisci un grande edificio con blocchi standard, cemento a resistenza standard, acciaio standard. Costruisci una grande app con le librerie standard.

Non provi e prova formalmente matematicamente una grande app corretta 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 erano nel software. Sono solidale con molti degli elementi che hai esposto.

Sospetto che la vera natura del problema riguardi come otteniamo le cose. Ora abbiamo una decina di anni di sviluppo agile sotto i nostri nastri collettivi e il messaggio è chiaro. Non progredire per strati; progredire per caratteristiche. Certo - ci saranno progetti quando è necessario progredire in base al livello (ad esempio, costruire lo stack di rete prima del server Web) ma per la stragrande maggioranza dei progetti del mondo reale, abbiamo imparato la lezione che offre funzionalità di lavoro, uno o pochi a un tempo, è molto più efficace costruire enormi teorie non testate, e quindi cercare di implementarle.

Quindi prendiamo il tuo esempio di capanna (di solito parlo di fare un ponte lanciando un log attraverso un torrente contro un chilometro di ponte sospeso ... qualunque cosa!), e portalo nel mondo dell'ingegneria del software. La differenza principale che vedo è che nel software, la maggior parte del lavoro è di una scala che non ha bisogno di grandi modelle up-front per avere successo. L'errore del principiante è spesso dare per scontato che le cose abbiano bisogno di più di quello che effettivamente fanno, e per la maggior parte di noi, avendo commesso questo errore un paio di volte, siamo ansiosi di farlo di nuovo troppo spesso.

Nessun argomento: ci sono progetti che devono iniziare con un comitato di 17 architetti del software. In realtà sono circa rari come diamanti da 20 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 da macchine di Turing teoriche come la matematica. L'ingegneria civile riguarda la creazione di strutture che resistono alla natura di madre e forse anche belle. Ancora una volta, non so molto dell'ingegneria civile, ma non penso che ci siano equivalenti ingegneri civili di P vs NP, il venditore ambulante, e altre cose divertenti a cui attaccare il cervello. E c'è sicuramente un posto per la nostra teoria dell'informatica: se qualcuno risolve il commesso viaggiatore o il problema dell'arresto, ci sono un sacco di nuovi incredibili progressi. Ma per un ingegnere del software, il cui compito è quello di progettare software, tali problemi sono in realtà solo divertimento e giochi.

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

O la teoria si riferisce agli algoritmi? Non passi un sacco di tempo a scrivere algoritmi che hai imparato nella tua classe di algoritmi. Perché? Perché di solito ne hai bisogno solo in casi particolari (e poi lo cerchi e lo cerchi), oppure 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 tendono a non imparare come funziona un algoritmo finché non ne hanno bisogno.

Un altro motivo è che attualmente esistono diversi metodi di sviluppo del software "fatti bene" che sono efficaci. Ad esempio, in uno sviluppo agile, non si può progettare preventivamente un intero sistema. Il motivo è perché non sai esattamente cosa stai costruendo ancora -si vuole ciò che stai facendo per essere flessibile e adattarsi alle nuove informazioni e requisiti. Progettare tutto fuori dal go-go e quindi costruire solo che non sempre produce il miglior software. Tuttavia, non è la soluzione per tutto. Ad esempio, supponiamo che tu stia progettando una cosa nuova del cluster distribuito. Non puoi fare schizzi di tovaglioli e avviare il tuo SCRUM.

TL; DR. Penso che ci sia un equivoco intorno alla parola "teoria". Tradizionalmente, la teoria si riferisce agli aspetti matematici teorici dell'informatica. A meno che non stiate ricercando nuovi modi di calcolo, 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 particolari specifici di implementazione di determinati algoritmi non sono importanti. Spesso, con idee meno complicate, è opportuno non progettare molto e iniziare la codifica. E penso che sia da lì che viene l'idea che i programmatori non amano la teoria.

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

L'ingegneria del software reale spingerebbe la maggior parte di coloro che lavorano nel campo formale e il vero sviluppo del software matematico fa impazzire quelli dell'ingegneria. Entrambi i campi richiedono persone con attitudini diverse, e non penso 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 esista indefinitamente nello stesso ambiente e che la soluzione di un problema astratto generale sia sempre l'obiettivo. Presuppone un ciclo di vita del software 4-as-a-product: progettazione, sviluppo, implementazione, completamento. La teoria formale riguarda la risoluzione del problema della progettazione del software mediante analisi, astrazione, generalizzazione e previsione dei cambiamenti futuri. Ciò è utile se si ha un problema ben definito in un dominio semplice facilmente analizzabile, prevedibile e abbastanza statico.

La programmazione pratica consiste nel risolvere il problema giusto (non quello della progettazione del software) nel modo giusto ora, in modo che i tuoi colleghi possano svolgere il loro lavoro meglio / più velocemente / a tutti, o in modo che i ricavi possano affluire all'azienda . Molto software non è come un prodotto, mai "fatto", ma più come una cosa vivente, che inizia altamente specializzata per una nicchia ecologica, e può avere una durata di vita molto variabile durante la quale deve risolvere problemi nuovi e imprevisti in un ampia varietà di ambienti in continua evoluzione. Nel mondo degli affari, con la politica e la legalità e la concorrenza e le organizzazioni, le strutture e le tendenze in continua evoluzione, i requisiti sono spesso ambigui, contorti con tutti i tipi di casi speciali, mal definiti e soggetti a rapidi cambiamenti inaspettati. Non sono analizzabili, prevedibili o statici e spesso non sono logici o ragionevoli. È probabile che il software sia irrilevante in 2 settimane per essere ancora in uso in 20 anni. Entra nel mondo non sapendo molto o in grado di fare molto, e ha bisogno di essere nutrito, curato e addestrato per tutta la sua vita per crescere strong, flessibile e capace 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 causerà dolore e sofferenza, risolvendo i problemi con una forza contundente.

La teoria formale non risponde alle esigenze di molti software aziendali reali. Ci fa credere che il software possa essere progettato e realizzato. Che si tratti di un prodotto che può essere riparato, lucidato o incollato su base occasionale, ma non è una cosa vivente che deve essere allevata correttamente con attenzione e attenzione costante per tutta la sua durata. Quindi ci ritroviamo con un codice legalmente molto brutto, ma probabilmente la teoria formale non ci avrebbe aiutato.

Tutto sembra piuttosto negativo, ma in realtà mi piace usare la teoria formale. Un bel design mi fa sempre sorridere. Tuttavia, è soprattutto nella mia programmazione hobbista che non è soggetta alle vicissitudini degli affari. Al lavoro, mi occupo principalmente di codice biologico e spero solo di poter dedicare abbastanza attenzione al fatto che crescerà bene, mi renderà orgoglioso e non sarò antipatico e maleducato con gli altri che devono affrontarlo.

La posta in gioco è più bassa, il lavoro è più semplice e la gestione raramente vede il valore in una buona progettazione. Instabilità, manutenibilità e 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 colleghi programmatori. Molti di loro non possono o non vogliono impegnarsi a pensare a un problema prima che inizi la codifica. A causa di quanto sopra, una buona parte di queste persone sono sviluppatori senior, rendendo ancora più difficile ottenere un buon design in produzione.

Ho visto il progetto condurre anni sprecati aggiungendo funzionalità ad-hoc e correzioni a progetti che erano rocciosi per cominciare, e poi abbattere ogni tentativo di mettere ordine nel caos con frasi come "troppo complicato" o "perdere tempo. " Non è piacevole vedere una spirale importante del progetto per il suo inevitabile destino, perché la direzione non ammetterà che stanno costruendo la propria prigione su base giornaliera; tuttavia, temo che sia una sfortunata realtà a cui molti sviluppatori hanno assistito e, nel bene o nel male, hanno imparato.

Cerco di trovare un supporto nel mio lavoro. Non scrivo più codice in progetti "contaminati" di quanto sia assolutamente necessario, e prendo ogni opportunità per spostare le funzionalità fuori di loro. "Tra un progetto e l'altro" passo del tempo a progettare e ripulire i progetti in cui ho effettivamente il controllo.

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

Prima di tutto, adoro questa domanda. Ho scritto come tre risposte di 1000 parole e tutte erano terribilmente 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 cemento come vuoi tu.

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

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

Il front-end di un'app Web d'altra parte, consiste principalmente di due linguaggi dichiarativi (non di programmazione) e JavaScript. L'unica cosa fisica che non puoi del tutto astrarre è il fatto che c'è sempre questo wall http per bloccare le cose tra server e browser. Indipendentemente da come lo si seppellisce nel codice, ciò richiede tempo e design asincrono.

Ovviamente non è possibile utilizzare un modello popolare e apprezzato come MVC per gestire i problemi front-end sul Web esclusivamente senza alterare il modo in cui è possibile gestirlo in un contesto di app desktop. In realtà, direi, dovresti essere consapevole di ciò che rende MVC utile, ma nemmeno tentare di implementarlo in modo particolarmente esigente o all'ingrosso. Il paradigma delle app Web è unico nel senso che tutte le cose look-at-me sono gestite dal browser dell'utente e tutti i dati / materiale del modello sono in genere sul server da qualche parte. Ma dove lascia il controller? Tutto sul server o tutto sul front-end? Qualcuno deve possedere quello. O forse MVC non è il 100% la soluzione migliore per lo scenario. Non male per Google back end. Non è terribile nel contesto di specifici widget dell'interfaccia utente. Ma il tentativo di applicarlo a tutto per motivi di coerenza potrebbe essere una brutta mossa, IMO.

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

Glenn Vanderburg presenta una visione grandiosa delle differenze tra ingegneria del software e discipline ingegneristiche più tradizionali: link

Se un ingegnere civile potesse testare i suoi progetti senza alcun costo prima di costruire l'ultima cosa, avrebbe fatto molto meno uso della teoria. Se in pochi secondi riuscisse a costruire un ponte migliaia di volte gratuitamente per testare quando si romperà, lo farebbe invece di spendere mesi calcolando quando potrebbe frenare in teoria ...

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

In effetti la maggior parte dei software oggi non è più limitata da vincoli fisici come potenza di calcolo o memoria. La limitazione del software è la complessità che ammonta a sistemi sempre più grandi. Gestisce questa complessità mantenendo il sistema comprensibile dagli esseri umani, cosa rende l'enorme sfida nella programmazione di oggi.