Se un programmatore fluente ignora le buone pratiche, la sua fluidità non funziona contro di lui? [chiuso]

Sto lavorando a un'applicazione abbastanza grande e buggy - e a causa del modo in cui è scritto (ti risparmierò i dettagli, ma viola le regole nella maggior parte delle aree a cui puoi pensare), è quasi impossibile svilupparlo senza importanti refactoring.

Una parte significativa dell'app è stata creata da stagisti, n00bs ecc .; ma c'è stato anche un programmatore nel rango di Master Developer, e con tutta umiltà, anche il codice che ha lasciato alle spalle è dubbio, in un modo diverso, ma forse ancora.

Certo, il suo codice tende a portare a termine il lavoro - la maggior parte delle volte - ma è tipicamente criptico, reinventando la ruota (ad es. Un grande metodo personalizzato che esegue un backup db SQL piuttosto ordinario) ecc. Fondamentalmente, inutile confusione più molta ingegnosità

E mi ha fatto pensare che essere un programmatore altamente qualificato (deliberatamente non uso la parola "sviluppatore", supponendo che indichi un insieme più ampio di abilità), se non accompagnato da altre qualità, può effettivamente essere velenoso.

Supponendo che sia vero, alcuni dei motivi che mi vengono in mente sono:

• se stai programmando con facilità, sembra (o in realtà lo è, a breve termine) solo più veloce di estrarre le tue soluzioni sul posto, senza ricorrere a librerie, funzionalità preesistenti ecc.
• se uno ha esperienza sufficiente per mantenere facilmente un'immagine mentale di un programma complesso, è meno propenso a dividerlo in moduli, livelli ecc.

Quindi il mio punto è che se un programmatore fluente sembra essere un cattivo sviluppatore, la loro fluidità non solo non compensa quest'ultimo, ma in realtà fa ancora più danni.

Cosa ne pensi? È vero (fino a che punto se sì)?

se stai programmando con facilità, sembra (o in realtà lo è, a breve termine) solo più veloce di estrarre le tue soluzioni sul posto, senza ricorrere a librerie, funzionalità preesistenti ecc.

Sì. Sono stato quel ragazzo. E ho imparato che è una cosa terribile.

Va tutto bene per te, non devi imparare qualcosa di nuovo.

E il resto della tua squadra? Diventano molto dipendenti da te. Non possono cercare su Google "Clive's Quicky ORM" per ottenere assistenza sul mappatore relazionale degli oggetti che hai scritto.

E poi arriva il giorno in cui devono assumere qualcuno di nuovo e non possono cercare persone con esperienza in Quicky ORM di Clive.

E finalmente arriva il giorno in cui parti e qualcuno nota un bug nel tuo ORM. E sarà lì, perché non hai un'intera comunità di persone che verifica e ripara il tuo prodotto.

Sì, imparare Hibernate potrebbe aver richiesto più tempo rispetto alla scrittura di qualcosa di leggero. Ma il vantaggio di farlo è troppo grande per essere ignorato, IMHO.

• se stai programmando con facilità, sembra (o in realtà è, a breve termine) solo più veloce di scattare le tue soluzioni sul posto, senza ricorrere a librerie, funzionalità preesistenti ecc.

Esperto nella lingua ma non negli strumenti. Non è nemmeno un forte programmatore. Sta semplicemente lucidando un'abilità (conoscenza della lingua) e permettendo ad un'altra di diventare arrugginita (conoscenza della biblioteca). Il contrario è altrettanto brutto, ma più facile da individuare.

• se si ha abbastanza esperienza per mantenere facilmente un'immagine mentale di un programma complesso, si è meno inclini a dividerlo in moduli, livelli ecc.

Questa è solo pigrizia mascherata da abilità. Non ci vuole molto sforzo per tenere a mente ciò a cui stai attivamente lavorando. Ci vuole abilità per trovare le giuste giunture e dividere il codice lungo di esse. I programmatori che affermano che è stato più veloce o migliore lasciare tutto in un punto spesso non riescono a vedere quali elementi suddividere.

Assicurati solo che non sia perché ha lavorato in un ambiente "Se la tua tastiera non fa clic, non stai lavorando". Guardiamo tutti indietro al codice e ci chiediamo cosa stessimo pensando. Inoltre, questo negozio è nella pratica del refactoring del loro codice? Potrebbe essere stato un lusso che non gli è stato dato.

Tuttavia, abbiamo bisogno di staccarci dalla nostra prima idea (quella che puoi semplicemente sederti e martellare) e fare un po 'più di pianificazione, ricerca, pensiero. La tentazione di eliminare ogni piccolo problema è allettante e l'intero progetto è disseminato di questa pratica. Nessuno vuole pagare le persone per sistemare cose che "non sono rotte", quindi perché refactor.

Modifica: assicuriamoci di non punire chi capita di conoscere le risposte. Ci sono persone che parlano fluentemente e scrivono buon codice con velocità. La chiave non è quella di affrontare ogni problema in questo modo.

100%.

Il modo cinico di vedere questo sarebbe che questi tipi di programmatori mantengono effettivamente la maggior parte degli sviluppatori al lavoro, correggendo bug che sono così fondamentali che puoi sprofondare migliaia di ore di sviluppatori senza arrivare a metà strada da un sistema stabile, flessibile, sicuro , modulare o [la tua proprietà del software preferita]. Questi sistemi hanno così tante idiosincrasie che il solo pensiero di migrare a qualcos'altro, anche con il 95% delle funzionalità già in atto e una vivace comunità alle sue spalle, è considerato da qualche parte tra ridicolo e motivi per essere licenziato.

In breve, i programmatori fluenti possono fare più danni di un'orda di concorrenti, ma il prezzo è di solito pagato per molti anni. E di solito stavano semplicemente facendo il loro lavoro (come definito da qualcun altro).

Come sapere se sei uno sviluppatore o un programmatore? Immagino sia impossibile, ma ogni volta che trovi un modo per semplificare il tuo codice senza ridurre la qualità hai fatto un altro passo verso l'illuminazione.

Il problema che hai descritto era fondamentalmente NIH ("non inventato qui") - ci sono altri sintomi?

A volte NIH, in particolare se isolato da una o due persone, può essere affrontato in una discussione di gruppo ("Joe qui ha una certa esperienza nel fare backup SQL usando librerie standard - cosa ne pensi, Joe?"). Questo potrebbe essere meno conflittuale di quello che stai andando direttamente alla persona e dicendo "Ehi! Usa la libreria standard, manichino!" :)

Essendo stato nella tua situazione e avendo causato situazioni simili, capisco la tua frustrazione, ma penso che la risposta alla tua domanda sia un "no" piatto. La fluidità non garantisce che un programmatore produrrà codice gestibile. Spesso le organizzazioni costringono i programmatori a fornire software mal progettato e implementato a causa di ridicoli limiti di budget e di tempo. È possibile che il programmatore fluente stia tagliando gli angoli, solo i programmatori si preoccupano di fornire qualcosa di cui i clienti si preoccupano. Ovviamente questo non è buono in pratica, ma purtroppo una realtà la maggior parte dei programmatori deve affrontare ad un certo punto della loro carriera. C'è anche la possibilità che un programmatore fluente sia solo pigro o compiacente. Parlo un inglese perfetto, ma è più facile e divertente usare il gergo.

Per quanto riguarda l'utilizzo del codice altrui o la discussione del proprio argomento, penso che dipenda davvero da ciò che ottiene il lavoro migliore. A volte "best" non tiene conto di cose come lo stile e la manutenibilità se "best" significa consegnare un progetto di sei settimane in due settimane. Ecco perché refattiamo e perfezioniamo. Inoltre, lo sviluppatore deve essere consapevole di ciò che è disponibile in termini di codice di terze parti e deve sapere come usarlo e confidare che funzionerà e sarà adeguatamente supportato / mantenuto. Dato che ci sono migliaia di framework, librerie e API opzionali per qualsiasi paradigma di sviluppo popolare che utilizza tali cose può finire per costare più tempo, energia e stress che semplicemente lanciare il proprio. Inoltre, trovo casi in cui il codice di terze parti non fa esattamente ciò di cui ho bisogno, ovvero quando "

Sono su quella barca (codice scritto fluentemente legacy) ed ero del tipo fluente per un po '.

Il più grande ostacolo alle soluzioni "veloci e sporche" è sempre quando è necessario aggiungerne altre in seguito. Quando hai bisogno di più funzionalità. C'è solo così tanto che puoi fare a meno della struttura. Dopodiché, si rompe, ed è costoso riordinarlo (ancora soddisfacente, ma non molto apprezzato).

Fondamentalmente, devi proteggerti da QUALSIASI HACK che potrebbe diventare potenzialmente una "soluzione praticabile", pronta per essere venduta da un venditore desideroso. È il vecchio "Non è pronto! - Ma funziona, no?" enigma.