Le cattive pratiche di programmazione sono tipiche del settore del software? [chiuso]

1. I principi che hai citato nella tua domanda sono solo ... principi. Non sono mandati, leggi o ordini.
2. Mentre le persone che hanno ideato 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" di 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 pratica è così diffusa che ha un nome: Debito tecnico

5. Alcune architetture software di uso comune non sono l'ideale. Le best practice si stanno evolvendo lontano dalle applicazioni monolitiche di grandi dimensioni verso raccolte di moduli liberamente accoppiate.

6. Il contesto è importante. molti principi architettonici dimostrano il loro valore solo quando lavori con programmi grandi o domini specifici. Ad esempio, l'ereditarietà è principalmente utile per le gerarchie UI e altre strutture che beneficiano di arrangiamenti profondamente nidificati e strettamente accoppiati.

Quindi, come segui un percorso "giusto", un percorso di principio, in modo che tu possa emergere dalla natura selvaggia?

1. Appropriatezza dello studio, piuttosto che correttezza. Il modo "giusto" di fare qualsiasi cosa nello sviluppo del software è quello che soddisfa in modo efficace le tue esigenze specifiche.
2. Contratti di studio. Tutto nello sviluppo del 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'eternità. Alcuni principi hanno superato la prova del tempo e saranno sempre pertinenti. I sistemi di tipo sono universali. Le funzioni di prima classe sono universali. Le strutture dati sono universali.

4. Impara il pragmatismo. Essere pratico è importante. Purezza matematica, architetture di cattedrale di cristallo e principi di torre d'avorio sono inutili se non puoi spedire.

5. Sii un artigiano, non uno zelante. I migliori sviluppatori di software sono quelli che conoscono le regole e sanno come romperle 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 codice. Molto. I principi di progettazione del software sono premature ottimizzazioni finché non hai scritto molto codice e sviluppato un istinto per come applicarli correttamente.

Non è raro. Una cosa da capire è che l'industria del software è incredibilmente diversificata. Alcune aziende sono all'avanguardia. Università leader e società di software innovative (anche alcuni laboratori in quelle grandi!), Nonché 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 nuovi linguaggi, macchine, strumenti e modelli. Le nuove società, spesso spin-off o split-off, cercano di usarle a livello commerciale e talvolta hanno un successo incredibile. Pensa a Facebook o a Google.

Ma al giorno d'oggi il software è utilizzato quasi ovunque, forse soprattutto in aziende che non sono in realtà società di software. Ho lavorato principalmente nel settore dei trasporti (automobilistico e ferroviario), e c'è un mix di esperienze. Ma nessuno di loro era da nessuna parte vicino al "all'avanguardia". A volte non possono essere; il software rilevante per la sicurezza dipende da strumenti ben controllati (stiamo attualmente 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 semplicemente scivolati 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 dell'ingegneria del software.

Un'altra cosa da considerare è ciò che è importante in un ingegnere nel mondo reale. Spesso il compito a portata di mano è, letteralmente, non una scienza missilistica. I problemi di pane e burro nelle società non software possono essere risolti con mezzi software modesti. Ciò che rende un ingegnere del software utile, forse persino 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 costo e del tempo effettivi!); capire cosa puoi e cosa non puoi fare. Manca evidentemente qui "conoscere e utilizzare strumenti e procedure allo stato dell'arte". Quello che descrivi è un'azienda che ha stabilito 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ì: quello che impari all'università in realtà non è comune in gran parte del campo.

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

They use C# .Net Webforms and do almost everything within the Code Behind with very little External Classes

Ecco la tua spiegazione qui. Se non si è a conoscenza, il codice Web Form predefinito è praticamente l'esatto opposto di OOP, SOLID, DRY, YAGNI, Design Patterns, SRP , ecc. Anche gli esempi ufficiali da Microsoft qualche anno fa ti farebbe rabbrividire oggi.

Web Forms si spinge verso un flusso procedurale, con alcuni "eventi" falsi attivati da clic di controllo e simili. Anche gli sviluppatori che hanno trascorso molto tempo a fare form Web sembrano riluttanti a discostarsene, probabilmente perché affondano così tanto tempo nell'apprendimento del ciclo di vita della pagina e in che modo eseguire controlli dinamicamente resi di cui detestano buttare via questa conoscenza adesso di fronte a metodi più nuovi / migliori. Una versione inconscia dell'errore del costo irrecuperabile. Questi sviluppatori hanno trascorso gli anni a imparare come utilizzare i Web Form e ora non si discosteranno facilmente da quell'esperienza, quindi parlano di "manutenzione".

E questo è abbastanza comune nello spazio .NET Web Form, btw.

How common is this within the software industry?

Molto comune. Circa la stessa comunanza con un idraulico che distrugge il tuo impianto idraulico, un falegname che consegna spazzatura o un sarto a buon mercato che realizza un abito inadatto. Io, è tutto umano.

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

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

O qualcuno che è bravo nel dominio, ma non un programmatore, potrebbe hackerare insieme qualche applicazione VBA ecc. perché all'inizio sembra abbastanza facile.

Oppure un'applicazione ben fatta finisce nella fase di manutenzione, tutti i buoni sviluppatori vanno avanti, e viene quindi continuata ad essere sviluppata da poche persone (nel caso peggiore: uno) che ne sanno poco, che non hanno documentazione , ecc.

How can I ensure that I stay on top of OOP and the related principles? I practice in my spare time and I feel like I really need to work under a more experienced developer to get better at OOP.

Ci sono due possibili risposte:

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

Se la seconda risposta suona troppo cinica per te, allora ti assicuro che non lo è. la maggior parte di un falegname che ha una falegnameria a casa sarà certamente un falegname migliore rispetto a chi non lo fa.

Ad esempio, è assolutamente possibile e un lotto di divertimento per alcune persone, ad esempio, scavare in una nuova lingua come Ruby, imparare non solo la sintassi, ma anche approfondire gli aspetti OO speciali di quella lingua, e davvero immergersi in profondità. Tutto nel tuo tempo libero, senza alcuna connessione con il tuo lavoro. Sarà solo un hobby, ma essendo il professionista addestrato che sei, può essere altrettanto efficace (o anche di più) come stare seduto 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 ti accorgi che non riesci semplicemente a capire, digita questo e torna alla prima risposta.

Lo sviluppatore principale che ti sta allenando ha abbastanza probabilmente imparato queste cose esattamente in questo modo ...

Penso che in Spagna sia una costante perché quando uno sviluppatore passa molti anni in una società, lui (o lei) viene solitamente promosso a 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 vengono accumulate sempre più pratiche sbagliate.

Alla fine alcuni furbi dicono che la migliore "soluzione" è quella di passare a una tecnologia emergente che genererà un codice più pulito e più maneggevole, creando una nuova applicazione. Come se la tecnologia da sola potesse farlo.

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

Alcune delle "migliori pratiche" che impari a scuola non sono pratiche o economicamente vantaggiose nei progetti reali. Uno dei più grandi cambiamenti che ho notato riguardava la formattazione e i commenti. La maggior parte dei miei professori ha sottolineato l'importanza di documentare estesamente il tuo codice, ma nel mondo reale, il buon codice è spesso (non sempre!) Auto-esplicativo, e ancora più importante che molti capi non vogliono pagare per spendere tempo extra a scrivere Commenti.

A volte vedrai programmatori che sono premuti per un po 'di tempo usando scorciatoie e anti-pattern che richiedono meno calorie rispetto alle soluzioni di qualità.

Tuttavia, uno dei maggiori problemi che ho notato in molti team e progetti è una 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. Si sono spesso laureati in campi completamente diversi e sono saltati in programmazione con poca o nessuna istruzione formale quando si è presentata 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 codificare in quasi tutti gli stili che hanno imparato decenni fa. Quando finiscono per occuparsi di nuovi progetti a causa dell'anzianità, tendono a tenere indietro i progetti e danneggiano la qualità complessiva del codice.

Ovviamente quanto sopra non si applica a tutti i programmatori più vecchi, 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 apprendere completamente. Scaricheranno un IDE o una libreria una volta e non la aggiorneranno mai a meno che la loro azienda lo richieda (a volte puoi indovinare in che anno un programmatore si è laureato sulla base delle sue librerie scadute). Non tengono il passo con le nuove funzionalità nelle loro lingue di scelta e non imparano mai nuove lingue. Non apprendono nuove strategie di programmazione e possono utilizzare in modo improprio schemi o paradigmi perché non conoscono alternative più appropriate (o MVC, quanto pesantemente sei abusato). Col passare del tempo, il loro flusso di lavoro diventa sempre più obsoleto e diventano più una responsabilità che una risorsa.

In sintesi, due delle principali cause di codebase disordinati sono scadenze affrettate e programmatori con conoscenza obsoleta o incompleta. 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 competenze. Se il capo non sa nulla di buone pratiche di programmazione, il meglio che puoi fare è provare a suggerire i cambiamenti e sperare che siano aperti ai suggerimenti. Sfortunatamente, potrebbero essere inclini a fidarsi della parola di un programmatore più anziano che non comprende OOP e ama scrivere 10.000 lezioni di linea.

Alcune delle cattive pratiche di programmazione derivano dal dover lavorare con software legacy che ha iniziato a svilupparsi decenni fa. Se c'è un enorme software complesso, riscrivere tutto potrebbe non essere un'opzione. Potrebbe persino essere estremamente difficile capire tutto ciò che il codice sta effettivamente facendo. L'opzione migliore potrebbe essere quella di copiare semplicemente ciò che funziona, cercando anche di integrare le migliori pratiche di programmazione, se è possibile farlo senza rompere nulla.

Penso che sia importante non solo dire il giusto da sbagliato, ma sapere ragioni dietro ogni cosa giusta e sbagliata. Quando conosci le ragioni, puoi prevedere le conseguenze. Perché usare questo o quel principio non perché è 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 ei 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 correttamente.

SOLID se usato troppo dogmaticamente porta a troppe classi e metodi che non sono altrettanto validi. Non esagerare. Questo è in parte un grosso problema con i nostri libri di testo e tutorial in quanto spesso cercano di promuovere idee senza un'adeguata giustificazione. OOP ha anche i suoi contro. Molti principi e paradigmi si contraddicono l'uno con l'altro. Non è necessario essere in cima, è necessario rendere tutto ragionevole, giustificato, elegante e semplice.

Inoltre, poiché questo è il tuo primo lavoro, è probabile che questi programmatori non siano molto abili. Ma, ripeto, probabilmente ci si affida a compiti non molto difficili che possono essere svolti senza tanta abilità e con un salario inferiore da parte di programmatori meno esperti meno esperti. Ecco come funziona l'economia. Ogni luogo di lavoro è diverso.

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