Alcune buone pratiche dipendono dall'abilità?

Risposta breve: Sì, è per questo che è buono per gli sviluppatori alle prime armi imparare e seguire le pratiche di programmazione comuni.

In realtà, capire il funzionamento interno (flusso dei processi aziendali) di un progetto e correggere i bug è un buon punto di partenza per gli sviluppatori alle prime armi. Imparare dal codice è anche un bene con buone capacità di debug come pre-condizione. Detto questo, è un approccio comune a quello sperimentato che potrebbe anche seguire.

È anche vero che understanding of programming problem challenge varia in base all'esperienza. Il programmatore alle prime armi riceve i requisiti e inizia a programmare, mentre lo sviluppatore esperto prende tempo per leggere i requisiti e chiarirli con BA o PM prima di iniziare a scrivere codice.

Pertanto, ottenere consigli da sviluppatori esperti è un processo di apprendimento molto essenziale.

Che cos'è un consiglio nel linguaggio nerd? - Nell'aspetto e nella programmazione funzionale, il consiglio descrive una classe di funzioni che modificano altre funzioni quando vengono eseguite queste ultime; è una determinata funzione, metodo o procedura che deve essere applicata in un dato punto di unione di un programma.

Un approccio dipende dalle proprie capacità e soprattutto dall'esperienza. Un programmatore alle prime armi sta usando i metodi che conosce per risolvere un problema, e di solito non c'è una grande varietà di metodi che un principiante può suggerire. D'altra parte, i programmatori più esperti hanno risolto più problemi, conoscono molte soluzioni e sanno quando ognuno di loro funzionerà meglio.

Inoltre, ai programmatori alle prime armi di solito non vengono assegnati compiti in cui devono applicare varie tecniche e modelli. Più lo sviluppatore è esperto, più sono difficili (e più interessanti, di conseguenza) le attività che ricevono.

Il problema è che molti programmatori semplicemente non sanno come applicare correttamente le loro conoscenze. Potrebbero conoscere molti schemi di progettazione, tecniche, ma hanno poca (o nessuna) esperienza nell'applicarli. Quindi rendono solo il loro codice più complicato e meno gestibile cercando di dare una soluzione "intelligente".

Ma ovviamente se qualche brillante nuovo arrivato suggerisce un buon approccio che richiede un sacco di abilità, nessuno gli dirà che è troppo bello per lui. Viceversa, lui / lei sarà incoraggiato a continuare a lavorare allo stesso modo.

Da voce del blog di PG :

There is a danger in designing a language based on one's own experience of programming. But it seems more dangerous to put stuff in that you've never needed because it's thought to be a good idea.

Per quanto riguarda la tua domanda, offrirei quanto segue:

There is a danger in solving programming problems with seemingly boring boilerplate code. But it seems more dangerous to program in ways that you never have before simply because it's thought to be a good idea.

Ad esempio, ecco cosa ho osservato con .NET:

• Quando .NET 2.0 è stato distribuito, gli sviluppatori junior hanno utilizzato i farmaci generici in modi che non avevano senso, semplicemente perché pensavano che fossero una buona idea.
• Quando .NET 3.5 è stato distribuito, gli sviluppatori junior hanno scritto dichiarazioni LINQ confuse in punti in cui i semplici cicli foreach sarebbero sufficienti perché pensavano che fossero una buona idea.
• Quando i Web Form di ASP.NET non sono graditi alla comunità di sviluppo, sviluppatori junior un altro sviluppatore junior ha aggiunto nuove funzionalità in base a Pattern MVP semplicemente perché ha letto che è stata una buona idea .

Per renderlo perfettamente chiaro, Generics, LINQ e il Pattern MVP hanno tutti il loro posto. Se utilizzati correttamente, questi possono semplificare il codice; ma devono essere utilizzati nel contesto appropriato.

Mi considero un programmatore esperto, sia nel tempo che nelle attività. Il mio stile è decisamente cambiato molto nel corso degli anni.

Come vedo, sono uno strano tipo di programmatore / architetto. Non sono mai orgoglioso di ciò che ho scritto, ma dell'abilità che sono stato in grado di portare a termine. Rispetto il codice di esecuzione, ma dal significato originale della parola: re-spect: controlla di nuovo. E refactoring, ogni volta che non è esattamente quello che voglio vedere.

Cambio il nome di una variabile o di una funzione più volte, se non significa esattamente quello che fa - fino a quando non devo rollare fino alla definizione, perché il nome è evidente. Sposto una funzione o dati più volte tra i vari livelli di un sistema fino a quando non arrivano a dove realmente appartengono. Riscrivo sempre i miei codici, non ne lascio mai nessuno () anche se conosco la precedenza degli operatori, o il {} dopo un if per una singola istruzione.

Ho la netta sensazione che ci sia un buon modo per svolgere un compito - e troppe soluzioni funzionanti, ma strutturalmente sbagliate. La struttura (livelli di servizio, comunicazione, responsabilità, dati) è molto più importante (perché influenza l'intera struttura di un sistema), mentre il codice dovrebbe essere "abbastanza buono" da eseguire.

Programmare per me è una costante ricerca di quella buona risposta, e ho ancora molto da imparare - ma quello che sembrava essere un intero campo di molti modi possibili quando ero un principiante, guarda una mappa con pochissimi percorsi provare. È fondamentalmente diverso.