Gli sviluppatori dovrebbero eseguire tutte le attività o specializzarsi? [chiuso]

Come al solito, nessuno in pratica fa le cose al 100% in un modo o al 100% nell'altro, anche se potrebbero prendere quella posizione in un argomento per motivi di semplicità.

Hai citato Agile e Agile generalmente tende a una minore specializzazione. Questo perché ci si aspetta che tutti quanti si incarichino di ridefinire il codice mentre eseguono lo sviluppo, e questo è difficile da fare se il refactoring deve fermarsi a un qualche tipo di confine, ad esempio se inizia a toccare il codice di uno specialista molto più avanti dell'altro sviluppatori in quell'area. Quindi, la quantità ottimale di specializzazione è inferiore se questo è il tuo modo di lavorare.

La tua lista di pro e contro non è male. Ne aggiungo qualcuno, personalmente:

Pro - È molto bello avere qualcuno che può far scollare le cose quando si verificano problemi davvero difficili, e per alcuni di questi uno specialista vale una dozzina di generalisti.

Con - Gli sviluppatori comunicano meno perché lavorano nelle loro aree specializzate il più delle volte. Se è così, non imparano tanto l'uno dall'altro e possono ottimizzare localmente, ma perdono l'immagine globale. Ci sono anche meno occhi per trovare bug o cattivi disegni.

Con - La ridondanza ha valore. Avere più persone a capire un determinato bit di codice riduce il rischio di perdere le informazioni chiave sul codice.

Anche in questo caso, ci sono costi e benefici in entrambi gli approcci, quindi ogni squadra deve cercare di trovare il trade-off con il valore massimo per la sua situazione.

Il sistema non crea valore. L'individuo fa.

Ancora più importante, il valore economico di un programmatore è direttamente correlato alla sua esperienza e alla capacità di adattarsi alle mutevoli circostanze.

Non riesco a pensare in qualsiasi momento dove sia bello essere semplicemente uno "sviluppatore Java" o uno "sviluppatore C #" o uno "sviluppatore JavaScript". Immagina come si sentono ora le persone che si definivano "sviluppatori Cobol" ( Oltre a ricchi) o, ancora meglio, come si sentono le persone che si sono definite sviluppatori di Mumps ?

Ero abituato a pensare che gli sviluppatori dovessero specializzarsi (ironicamente, quando lavoravo a un lavoro in cui non non eravamo specializzati). Ora che lavoro da qualche parte dove abbiamo sviluppatori specializzati (c'è una netta divisione tra lo sviluppo di FEWD e Back-end), vorrei che non lo facessimo.

Indipendentemente dal linguaggio e dalla piattaforma, ci sono problemi comuni. Quando ti inseri al "front end" o "back end", corri il rischio che un gruppo faccia gli stessi errori che l'altro gruppo ha appena risolto. Qualunque cosa può essere migliorata con la comunicazione, ma il problema non può essere risolto se gli sviluppatori non hanno un frame di riferimento per correggerlo.

Anche se hai persone che sono "migliori" nelle tecnologie front-end, non può fare altro che aiutare la tua azienda nel suo insieme se gli sviluppatori hanno familiarità con tutti gli aspetti della loro infrastruttura e codice. Non devono diventare la persona "di passaggio", ma devono averne familiarità. Altrimenti, cosa succede quando uno di loro viene colpito da un autobus o, peggio, da tutta la squadra?

Dipende . Se il tuo progetto si presta alla separazione, fallo. Se la tua squadra è sufficientemente arrotondata per lavorare su tutto, allora potrebbe essere più veloce. Se hai solo 2 sviluppatori, indosseranno un sacco di cappelli. Se i tuoi problemi sono molto difficili, potrebbe essere necessaria la specializzazione.

Personalizza il tuo processo nel tuo scenario; sarà così che otterrai il miglior risultato.

Il team ideale avrebbe entrambi i tipi di sviluppatori. Vuoi avere specialisti perché avranno la profondità della conoscenza che il generalista non avrà; possono battere il codice più velocemente, risolvere i problemi più complicati meglio o più velocemente, e così via. Volete che i generalisti attraversino il sistema, siano in grado di identificare i problemi comuni e correggere i colli di bottiglia - ad esempio, un cambiamento minore nel database potrebbe costare una settimana di riprogettazione del front end. Lavori in una squadra, ogni abilità di sviluppatore, debolezza, preferenze e pet-hates viene fuori e fai il piatto di conseguenza.

E penso che lo sviluppatore ideale coprirà entrambe queste basi. Vuoi generalizzare abbastanza per essere in grado di costruire sistemi piuttosto che componenti o solo "bit" per aiutare qualcun altro a costruire un sistema. Ma devi specializzarti abbastanza per avere un vantaggio sul prossimo: vuoi essere il migliore in qualcosa, giusto?

Naturalmente "specializzare" è un termine spurio. Potrei dire "Sono specializzato in .NET"; è una specializzazione? In un certo senso, sì perché definisce dove si trovano le mie competenze, ma non è certo un'area di nicchia e anche all'interno di .NET c'è troppo da fare per essere un esperto. D'altra parte, potrei dire "Sono specializzato in XPath" - ok, anche questo è grandioso, ma è una specializzazione molto più ristretta. Non puoi costruire molto usando solo XPath, e se non sai nulla, ma XPath, allora sei utile è molto limitato.

Ci sono così tante aree da attraversare, e ci sono solo tante ore in un giorno, che non coprirai mai tutte le basi. Idealmente avresti una vasta gamma di esperienze e aree di competenza all'interno di tale intervallo.

Questo dipende dal livello di abilità degli sviluppatori nel progetto.

Di solito in un progetto web, se hai uno sviluppatore con ottime capacità su jquery / html / css, lascia che lui / lei lavori sull'interfaccia utente e lo faccia diventare carino. Logicamente, uno sviluppatore che si diverte a creare codice e servizi di back-end sarebbe la cosa più utile per fare quella parte dell'applicazione.

Tuttavia, ci potrebbero essere sviluppatori meno esperti nella squadra, che potrebbero imparare da sviluppatori esperti nella squadra.

In altre parole, se il progetto ha persone miste e qualificate nel team, lascia che facciano ciò che è meglio.