Se un codificatore fluente ignora le buone pratiche, la sua scioltezza non è efficace contro di lui? [chiuso]

if you're coding with ease, it feels (or actually is, in short run) just quicker to snap out your own solutions on the spot, without turning to libraries, preexistent functionality etc.

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

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

Ma per quanto riguarda il resto della tua squadra? Diventano molto dipendenti da te. Non possono google per "Clive's Quicky ORM" per ottenere aiuto sul mapper relazionale oggetto che hai scritto.

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

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

Sì, l'apprendimento di Hibernate potrebbe richiedere più tempo rispetto alla scrittura di qualcosa di leggero. Ma il vantaggio di farlo è troppo grande per ignorarlo, IMHO.

•if you're coding with ease, it feels (or actually is, in short run) just quicker to snap out your own solutions on the spot, without turning to libraries, preexistent functionality etc.

Abile nella lingua ma non negli strumenti. In realtà non è nemmeno un programmatore potente. Si tratta semplicemente di lucidare una competenza (conoscenza della lingua) e di consentire ad un'altra di diventare arrugginita (conoscenza della biblioteca). L'opposto è altrettanto brutto, ma più facile da individuare.

•if one is experienced enough to easily maintain a mental image of a complex program, one is less inclined to split it into modules, layers etc.

Questa è solo pigrizia mascherata da abilità. Non ci vuole molto sforzo per mantenere quello che stai lavorando attivamente nella tua testa. Ci vuole abilità per trovare le giuste cuciture e dividere il codice lungo di esse. I coder che dicono che è stato più veloce o meglio lasciare tutto in un posto spesso non riescono a vedere quali elementi separare.

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

Tuttavia, abbiamo bisogno di rompere con la nostra prima idea (quella che puoi semplicemente sederti e battere fuori) e fare un po 'più di pianificazione, ricerca, riflessione. La tentazione di allontanare ogni piccolo problema è allettante e l'intero progetto è disseminato di questa pratica. Nessuno vuole pagare le persone per sistemare cose che "non è rotto", quindi perché refactoring.

Modifica: assicuriamoci di non punire chi conosce le risposte. Ci sono quelli che parlano correntemente e scrivono un buon codice con velocità. La chiave non è affrontare ogni problema in questo modo.

100%.

Il modo cinico di guardare a questo sarebbe che questi tipi di programmatori stiano effettivamente mantenendo la maggior parte degli sviluppatori al lavoro, correggendo bug che sono così fondamentali che puoi affondare migliaia di ore di sviluppo senza arrivare a metà strada a una stalla, flessibile, sicuro, modulare o [la tua proprietà software preferita]. Questi sistemi hanno così tante idiosincrasie che il solo pensiero di migrare a qualcos'altro, anche con il 95% delle funzionalità già presenti e una vibrante comunità dietro di esso, è considerato in qualche modo tra ridicolo e motivi per essere licenziato.

In breve, i programmatori fluenti possono fare più danni di un'orda di concorrenti, ma il prezzo viene solitamente 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 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 ha qualche esperienza nel fare backup SQL usando le librerie standard - cosa ne pensi, Joe?"). Questo potrebbe essere meno conflittuale di quello che diresti direttamente alla persona e dire "Ehi, usa la libreria standard, manichino!" :)

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

Per quanto riguarda l'utilizzo del codice di altri o il rollover del tuo argomento, penso che in realtà dipenda da cosa ottiene il lavoro migliore. A volte il "migliore" non tiene conto di cose come stile e manutenibilità se "migliore" significa consegnare un progetto di sei settimane in due settimane. Questo è il motivo per cui ci rifattiamo e perfezioniamo. Inoltre, lo sviluppatore deve essere a conoscenza di ciò che è disponibile in termini di codice di terze parti e deve sapere come usarlo e fidarsi che funzioni e sia adeguatamente supportato / mantenuto. Dato che ci sono migliaia di framework, librerie e API opzionali per qualsiasi paradigma di sviluppo popolare che utilizza tali elementi può costare più tempo, energia e stress rispetto al semplice rotolare il proprio. Inoltre, trovo casi in cui il codice di terze parti non fa esattamente quello che mi serve per farlo - che è quando è molto utile essere fluenti.

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

Il più grande ostacolo alle soluzioni "rapide e sporche" è sempre quando è necessario aggiungerne altre in seguito. Quando hai bisogno di più funzionalità. C'è così tanto che puoi fare senza struttura. Dopo di ciò, si rompe, ed è costoso riarrangiarlo (ma soddisfacente, ma non molto apprezzato).

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