Le cattive pratiche di programmazione sono tipiche dell'industria del software? [chiuso]

Ho appena iniziato il mio primo lavoro come sviluppatore di software più di un mese fa. Tutto ciò che ho imparato su OOP, SOLID , DRY , YAGNI, modelli di progettazione, SRP , ecc. Può essere buttato fuori dalla finestra.

Usano i Webform C # .NET e fanno quasi tutto nel Code Behind con pochissime classi esterne, sicuramente non chiamate oggetti. Usano i controlli personalizzati e li riutilizzano. Gli unici oggetti utilizzati sono Entity Framework . Riutilizzano il Codice dietro ogni cliente. Hanno metodi lunghi 400 righe che fanno tutti i tipi di cose. Per i nuovi clienti prendono aspx e aspx.cs e rimuovono il codice client e iniziano ad aggiungere il nuovo codice specifico del client.

La loro prima scusa sarebbe che aggiunge ulteriore manutenzione e più codice è più manutenzione. È un piccolo negozio di tre sviluppatori incluso me stesso. Uno sviluppatore ha oltre 30 anni di esperienza e l'altro ha oltre 20 anni di esperienza. Uno era uno sviluppatore di giochi e l'altro ha sempre funzionato in C e C ++.

Quanto è comune questo nel settore del software? Come posso assicurarmi di rimanere aggiornato su OOP e sui principi correlati? Mi alleno nel mio tempo libero e sento di dover davvero lavorare con uno sviluppatore più esperto per migliorare in OOP.

1. I principi che hai citato nella tua domanda sono proprio questi ... principi. Non sono mandati, leggi o ordini.
2. Mentre le persone che hanno escogitato questi principi sono molto intelligenti, non sono autorità assolute. Sono solo persone che offrono le loro idee e indicazioni.
3. Non esiste un modo "corretto" per programmare. Ciò è dimostrato dal fatto che il modo "accettato" di farlo è cambiato e continua a cambiare radicalmente nel tempo.
4. La spedizione di un prodotto può spesso avere la precedenza rispetto a farlo nel modo "giusto". Questa è una pratica così diffusa che ha un nome: debito tecnico.

5. Alcune architetture software di uso comune non sono l'ideale. Le migliori pratiche si stanno evolvendo da grandi applicazioni monolitiche a raccolte di moduli liberamente accoppiati.

6. Il contesto è importante. Molti principi architettonici dimostrano il loro valore solo quando lavori con programmi di grandi dimensioni o domini specifici. Ad esempio, l'ereditarietà è utile soprattutto per le gerarchie dell'interfaccia utente e altre strutture che traggono vantaggio da disposizioni profondamente annidate e strettamente accoppiate.

Quindi, come si fa a seguire un percorso "giusto", un percorso di principio, in modo da poter emergere dal deserto?

1. Studia l'adeguatezza, piuttosto che la correttezza. Il modo "giusto" di fare qualsiasi cosa nello sviluppo del software è quello che soddisfa in modo più efficace i tuoi requisiti specifici.
2. Studia i compromessi. Tutto nello sviluppo di software è un compromesso. Vuoi più velocità o meno utilizzo della memoria? Vuoi un linguaggio di programmazione molto espressivo con pochi professionisti o un linguaggio meno espressivo che molti sviluppatori conoscono?

3. Studia l'atemporalità. Alcuni principi hanno superato la prova del tempo e saranno sempre rilevanti. I sistemi di tipo sono universali. Le funzioni di prima classe sono universali. Le strutture di dati sono universali.

4. Impara il pragmatismo. Essere pratici è importante. La purezza matematica, le architetture della cattedrale di cristallo e i principi della torre d'avorio sono inutili se non si può spedire.

5. Sii un artigiano, non un fanatico. I migliori sviluppatori di software sono quelli che conoscono le regole e quindi sanno come infrangerle quando ha senso farlo. Sono quelli che sanno ancora come risolvere i problemi e pensare da soli. Usano i principi per informare e guidare le loro scelte, non dettarle.
6. Scrivi il codice Un sacco. I principi di progettazione del software sono ottimizzazioni premature fino a quando non avrai scritto molto codice e sviluppato un istinto su come applicarli correttamente.

Non è raro. Una cosa da capire è che l'industria del software è incredibilmente diversificata. Alcune aziende sono all'avanguardia. Le principali università e società di software innovative (anche alcuni laboratori in quelle grandi!) Così come persone o gruppi benedetti come la banda di quattro analizzano i problemi che si verificano con i modi comuni di fare le cose e inventare nuove lingue, macchine, strumenti e schemi. Nuove aziende, spesso spin-off o split, provano a usarle commercialmente e talvolta hanno un successo incredibile. Pensa a Facebook o Google.

Ma il software è usato quasi ovunque in questi giorni, forse principalmente in aziende che non sono in realtà società di software. Ho lavorato principalmente nel settore dei trasporti (automobilistico e ferroviario) e c'è un sacco di esperienze. Ma nessuno di loro era vicino al "limite". A volte non possono essere; il software rilevante per la sicurezza dipende da strumenti ben controllati (attualmente stiamo utilizzando un compilatore C ++ validato degli anni '90). A volte non hanno le persone giuste. Spesso il software è sviluppato da ingegneri di altri settori che sono appena entrati nello sviluppo del software nella loro azienda quando il software è diventato sempre più importante. Non ci si può aspettare che conoscano o utilizzino i principi di ingegneria del software.

Un'altra cosa da considerare è ciò che è importante in un ingegnere nel mondo reale. Spesso il compito a portata di mano non è, letteralmente, la scienza missilistica. I problemi del pane e burro nelle società non software possono essere risolti con mezzi software modesti. Ciò che rende un ingegnere del software utile, forse anche buono, è in parte ciò che rende un buon ingegnere generale: essere affidabile; organizzare e documentare il tuo lavoro in modo responsabile; essere cooperativo; fare buone stime di costi e tempi (la validità della stima è più importante del tempo e dei costi effettivi!); capire cosa puoi e cosa non puoi fare. Manca evidentemente qui "conoscere e usare strumenti e procedure all'avanguardia". Quello che descrivi è una società che ha creato un set di strumenti e un processo che funziona per loro. Probabilmente non produrranno mai nulla di sexy o straordinario, ma soddisfano le richieste dei clienti abbastanza bene da generare un flusso costante di entrate sufficienti. Questa potrebbe essere la definizione di ingegneria ;-).

Quindi sì: ciò che impari all'università in realtà non è comune in gran parte del campo.

Voglio aggiungere un pezzo di consolazione, o una nota più ottimista. Quello che hai imparato non dovrebbe essere gettato fuori dalla finestra. Puoi applicare principi migliori nel tuo lavoro quotidiano dove non si rompono le cose. Forse ci sarà una finestra di opportunità per introdurre un nuovo strumento o modello di progettazione. Le possibilità sono migliori quando il vecchio modo di fare le cose è spiacevole per i colleghi o se incontrano problemi con la gestione della complessità o della manutenzione (i due problemi più virulenti affrontati dalle innovazioni). Siate pronti a offrire miglioramenti in caso di opportunità. Essere un'influenza positiva e migliorare progressivamente metodi e strumenti; diffondere conoscenza dove è apprezzato.

Usano C # .Net Webforms e fanno quasi tutto all'interno del codice dietro con classi esterne molto piccole

C'è la tua spiegazione proprio lì. Se non sei a conoscenza, il codice Web Forms pronto all'uso è praticamente l'opposto polare di OOP, SOLID, DRY, YAGNI, Design Patterns, SRP , ecc. Persino gli esempi ufficiali di Microsoft di alcuni anni fa ti farebbe rabbrividire oggi.

Web Forms si spinge verso un flusso procedurale, con alcuni "eventi" falsi innescati da clic di controllo e simili. Gli sviluppatori che hanno trascorso molto tempo a fare Web Form di solito sembrano anche riluttanti a discostarsene, probabilmente perché hanno sprecato così tanto tempo nell'apprendimento del ciclo di vita della pagina e su come fare controlli resi dinamicamente che non amano buttare via quella conoscenza ora di fronte a metodi più recenti / migliori. Una versione inconscia dell'errore sommerso. Questi sviluppatori hanno trascorso anni imparando a combattere i moduli Web e ora non si discosteranno facilmente da quella competenza, quindi i loro discorsi sul tempo di "manutenzione".

E questo è abbastanza comune nello spazio di .NET Web Forms, tra l'altro.

Quanto è comune questo nel settore del software?

Molto comune. Più o meno allo stesso modo in cui un idraulico distrugge i tuoi impianti idraulici, un falegname consegna spazzatura o un sarto a buon mercato che fa un abito inadatto. Cioè, è tutto umano.

C'è una buona ragione per cui questo accade: le persone che non sono veramente allenate (o non entusiaste) devono implementare qualcosa sotto pressione.

Questo non è un problema di queste persone, principalmente, ma di solito delle strutture che circondano lo sviluppo del software in quella società. Ad esempio, un'azienda potrebbe avere un sacco di stagisti a sviluppare il proprio software interno; anche se quegli stagisti sono brillanti e ben informati, saranno lì solo per alcune settimane o mesi e la proprietà cambierà frequentemente.

O qualcuno che è fantastico nel dominio, ma non un programmatore, potrebbe hackerare insieme alcune applicazioni VBA ecc. Perché all'inizio sembra essere abbastanza facile.

Oppure un'applicazione ben fatta finisce nella fase di manutenzione, tutti i buoni sviluppatori passano avanti, e quindi continua a essere sviluppato da poche persone (nel peggiore dei casi: uno) che ne sanno poco, che non hanno documentazione, ecc.

Come posso assicurarmi di rimanere aggiornato su OOP e sui principi correlati? Mi alleno nel mio tempo libero e sento che ho davvero bisogno di lavorare con uno sviluppatore più esperto per migliorare in OOP.

Ci sono due possibili risposte:

• O: discutilo con il tuo capo e assicurati di entrare in progetti puliti. Se non è possibile, trova un nuovo capo.
• Oppure: assumiti la responsabilità di questo da solo. Ciò significa farlo da soli - nel tempo libero, o se puoi, in compagnia, ma guidato da te stesso (improbabile).

Se la seconda risposta sembra troppo cinica per te, allora lascia che ti assicuri che non lo è. Un falegname che ha un negozio di falegnameria a casa sarà più certamente un falegname meglio di uno che non lo fa.

Ad esempio, è assolutamente possibile e molto divertente per alcune persone, ad esempio, scavare in una nuova lingua come Ruby, apprendere non solo la sintassi, ma anche approfondire aspetti OO speciali di quella lingua e immergersi davvero in profondità. Tutto nel tuo tempo libero, senza alcun collegamento con il tuo lavoro. Sarà solo un hobby, ma essendo il professionista qualificato che sei, può essere efficace (o più) come sedersi accanto a qualche sviluppatore principale e cercare di seguire quello che stanno facendo. Questo sarà quindi strettamente per il tuo sviluppo personale e il tuo divertimento. Se non ti diverti a farlo, o se scopri che semplicemente non riesci a raggiungere alcuna comprensione, allora grattalo e torna alla prima risposta.

Quel capo sviluppatore che si sta allenando è abbastanza probabile imparato che roba esattamente in questo modo ...

Penso che in Spagna sia una costante perché quando uno sviluppatore trascorre molti anni in un'azienda viene solitamente promosso in più aree di gestione come l'analisi e la gestione dei progetti. Di conseguenza non viene eseguita alcuna revisione tra pari e il codice viene solitamente scritto da persone meno esperte.

I fallimenti di queste persone esperte non vengono mai corretti: invece, il loro unico obiettivo è quello di svolgere il lavoro. Di conseguenza, nel codice si accumulano sempre più pratiche errate.

Alla fine qualche asino intelligente afferma che la migliore "soluzione" è quella di passare a una tecnologia emergente che genererà codice più pulito e più manutenibile, creando una nuova applicazione. Come se la tecnologia da sola potesse farlo.

Ancora una volta, i programmatori inesperti vengono messi al lavoro in quella nuova tecnologia, nessuno rivede il codice e il cerchio viene chiuso di nuovo .... per sempre e sempre ....

Alcune delle "migliori pratiche" che impari a scuola non sono pratiche o economiche su progetti del mondo reale. Uno dei maggiori cambiamenti che ho notato è stato nella formattazione e nei commenti. La maggior parte dei miei professori ha sottolineato l'importanza di documentare ampiamente il tuo codice, ma nel mondo reale, il buon codice è spesso (non sempre!) Autoesplicativo e, soprattutto, molti capi non vogliono pagare per te per passare del tempo in più a scrivere Commenti.

A volte vedrai programmatori che vengono premuti per un po 'di tempo usando scorciatoie e anti-schemi che richiedono meno boiler-plate rispetto alle soluzioni di qualità.

Tuttavia, uno dei maggiori problemi che ho notato in molti team e progetti è la riluttanza a imparare cose nuove. Molti dei programmatori più anziani con cui ho parlato hanno iniziato la loro carriera in un periodo di ingegneria del software "Wild West" quando le qualifiche sono iniziate e terminate con la volontà di scrivere codice. Spesso si sono laureati in campi completamente diversi e sono entrati in programmazione con poca o nessuna istruzione formale quando si presentava un'opportunità (ad esempio il loro datore di lavoro non aveva un programmatore e aveva bisogno di qualcuno da imparare per costruire software interno). Alcuni di questi programmatori autodidatti della vecchia scuola non fanno mai lo sforzo di apprendere le moderne pratiche di codifica e continuano a programmare in qualunque modo apprendessero decenni fa. Quando finiscono per occuparsi di nuovi progetti a causa dell'anzianità, tendono a trattenere i progetti e danneggiare la qualità complessiva del codice.

Naturalmente quanto sopra non si applica a tutti i programmatori più anziani e i programmatori di nuova generazione possono essere altrettanto colpevoli. Ho lavorato con molti programmatori più giovani che hanno raccolto alcuni strumenti e librerie appena usciti dal college e poi hanno smesso di imparare completamente. Scaricheranno un IDE o una libreria una volta e non lo aggiorneranno mai a meno che la loro azienda non lo richieda (a volte puoi indovinare in quale anno un programmatore si è laureato in base a quanto sono obsolete le sue librerie). Non tengono il passo con le nuove funzionalità nella loro lingua (s) di scelta, e non imparano mai nuove lingue. Non imparano nuove strategie di programmazione e possono abusare di schemi o paradigmi perché non conoscono alternative più appropriate (oh MVC, quanto pesantemente sei abusato). Col passare del tempo, il loro flusso di lavoro diventa sempre più obsoleto e diventano più una responsabilità che un'attività.

In sintesi, due delle principali cause di basi di codice disordinate sono scadenze affrettate e programmatori con conoscenze obsolete o incomplete. Sfortunatamente, la responsabilità di entrambe le questioni può ricadere pesantemente sul capo o CTO, che deve garantire che le scadenze siano realistiche e che il personale sia aggiornato sulle proprie conoscenze e abilità. Se il capo non sa nulla delle buone pratiche di programmazione, il meglio che puoi fare è provare a suggerire cambiamenti e sperare che siano aperti ai suggerimenti. Sfortunatamente, potrebbero essere inclini a fidarsi della parola di un programmatore più anziano che non capisce OOP e ama scrivere 10.000 lezioni di linea.

Alcune delle cattive pratiche di programmazione derivano dalla necessità di lavorare con software legacy che ha iniziato lo sviluppo decenni fa. Se esiste un enorme software complesso, riscrivere tutto potrebbe non essere un'opzione. Potrebbe anche essere estremamente difficile capire tutto ciò che il codice sta effettivamente facendo. L'opzione migliore potrebbe essere semplicemente copiare ciò che funziona, cercando anche di integrare le migliori pratiche di programmazione, se è possibile farlo senza interrompere nulla.

Penso che sia importante non solo dire bene dal male ma conoscere le ragioni dietro ogni giusto e sbagliato. Quando conosci i motivi, puoi prevederne le conseguenze. Perché usare questo o quel principio non perché sia ​​stato descritto in un libro, ma perché sappiamo come aiuta e cosa succede esattamente se dovessimo romperlo. Se sai cosa succede quando puoi valutare i pro e i contro e prendere una decisione. Questo ti aiuterà anche a discutere la tua posizione ogni volta. SOLID e OOP possono anche ridurre la manutenzione se usati bene.

SOLID se usato in modo troppo dogmatico porta a troppe classi e metodi che non sono altrettanto buoni. Non esagerare. Questo è in parte un grosso problema con i nostri libri di testo e tutorial poiché spesso cercano di promuovere idee senza un'adeguata giustificazione. OOP ha anche i suoi contro. Molti principi e paradigmi si contraddicono a vicenda. Non devi essere al top, devi rendere tutto ragionevole, giustificato, elegante e semplice.

Inoltre, poiché questo è il tuo primo lavoro, è probabile che questi programmatori non siano molto competenti. Ma ancora una volta, probabilmente si stanno fidando di compiti non molto difficili che possono essere svolti senza tanta abilità e per un salario più basso da programmatori meno abili meno costosi. Ecco come funziona l'economia. Ogni luogo di lavoro è diverso.

Capisco come ti senti. Non fatevi prendere dal panico . Avrai bisogno di ciò che sai, forse non immediatamente, ma ti aiuterà. Forse in un posto di lavoro diverso, forse in alcune occasioni. Hai tempo davanti a te per andare oltre.