Il nostro sviluppatore T-SQL ha appena dato le sue due settimane di preavviso. Ci è stato chiesto se il nostro team di quattro sviluppatori desiderava uno sviluppatore aggiuntivo.
Ci viene offerto di realizzare il nostro sviluppo T-SQL / Entitiy Framework o potremmo ottenere un altro sviluppatore T-SQL dedicato.
Quali sono i pro e i contro di avere uno sviluppatore T-SQL dedicato nel team?
Quale preferisci e perché?
Se hai già almeno una persona nella tua squadra che può:
Potresti già avere un altro sviluppatore t-sql in grado di mantenere il team almeno in linea. La mia lista non è completa, ma se quelle cose ci sono, lui probabilmente può tenerti lontano dai guai.
Se non hai qualcuno nel tuo team che può fare quelle cose e il tuo team ha le mani nel database, hai bisogno di qualcuno che possa fare quelle cose. A meno che tu non sia del tutto estraneo alla qualità del database (una posizione valida se il sistema è abbastanza piccolo, leggi: meno di 15 tabelle).
Su che tipo di applicazione stai lavorando? Dato che hai già avuto uno sviluppatore database / T-SQL nel tuo team in precedenza, presumo che sia ragionevolmente incentrato sul database, ma la risposta a come il database è effettivamente utilizzato dalla tua applicazione ha un impatto sul fatto che uno sviluppatore di database separato sia necessario o utile.
La mia reazione iniziale è stata "vuoi uno sviluppatore T-SQL con esperienza di sviluppo del database sul tuo team", ma se il database è poco più di un archivio dati (poca o nessuna logica nel livello del database), forse potresti farne a meno Stessa cosa se la progettazione del database è semplice (significa che per estrarre qualcosa di utile non è necessario un milionesimo milione di join tra decine di tavoli), o se le prestazioni e la scalabilità non sono delle ottime preoccupazioni nel tuo caso.
Un ovvio inconveniente di uno sviluppatore di database separato è il costo a breve termine di un altro sviluppatore che non contribuirà direttamente alle parti visibili del software dell'utente.
Supponendo che l'applicazione su cui stai lavorando sia ragionevolmente incentrata sul database , una volta che il periodo iniziale di accelerazione è stato curato, con uno sviluppatore che può concentrarsi sugli aspetti del database dell'applicazione può aiutare un bel po '. Si ottiene qualcuno che conosce i dettagli della programmazione basata su set, può concentrarsi su quale quantità di normalizzazione dei dati in memoria è utile nel caso specifico, e si spera che possa aiutare a creare o migliorare la progettazione del database per fornire buone prestazioni ora e in futuro.
Avere uno sviluppatore di applicazioni anche lo sviluppo di database non significa che avere sia una cosa negativa, ma c'è un evidente rischio che lo sviluppatore in questione si concentri maggiormente sulle esigenze dal lato delle applicazioni piuttosto che su ciò che rende una buona e scalabile struttura del database e quindi capire come esporlo al livello dell'applicazione in un modo che fornisca all'applicazione i dati di cui ha bisogno. Questo può portare a risultati a breve termine e dolore a lungo termine quando il progetto sottostante risulta non essere scalabile. Ovviamente non deve accadere in questo modo, ma è un rischio che vale la pena essere consapevoli di.
Per quanto riguarda i costi di comunicazione (e in particolare quello che causa ritardi), non deve accadere in questo modo. Se gli altri sviluppatori del team conoscono un po 'di T-SQL (non è che difficile cogliere le nozioni di base come fare selezioni, aggiornamenti, join, ecc.), Allora possono certamente fare < em> prototyping nel livello del database solo per ottenere i dati di cui hanno bisogno. Prima che il codice vada in produzione (qualunque cosa questo significhi nel tuo ambiente), lo sviluppatore del database può firmarlo dicendo che è un progetto abbastanza buono, o prendere i parametri di input, il risultato desiderato e il design del set di risultati di output, e capire un modo migliore per eseguire le query effettive.
Pro:
Contro:
Penso che tu possa capire dove sto andando con questo.
Hai bisogno di un DBA. Si tratta di persone che si occupano del corretto funzionamento dei database, del buon funzionamento e dei requisiti. Persone che istruiranno e insegneranno agli sviluppatori le migliori pratiche e cosa evitare.
Se non ricevi un DBA dedicato, uno (o tutti) di te dovrà recuperare il gioco, lavorando su cose che non sono direttamente correlate allo sviluppo.
Sebbene i miei punti riguardino i DBA (poiché in origine era il titolo della domanda), ad eccezione dei backup e dei punti di manutenzione, il resto è valido per uno sviluppatore T-SQL.
L'assunto è che uno sviluppatore T-SQL è un professionista che capisce come funziona quel database e le migliori pratiche, ecc ...
Se usi EF e non hai qualcuno che capisca come funziona un database, puoi avere dei problemi. Se il tuo team è abile (capisce l'indicizzazione ad esempio e quando applicarlo in modo appropriato, capisce come ottimizzare una query, ecc ...), probabilmente non hai bisogno di uno sviluppatore T-SQL dedicato.
Which would you prefer and why?
Dipende dallo skillset del mio team e dall'applicazione. Se il team ha qualche background SQL, possono farlo. Se l'applicazione non ha abbastanza lavoro SQL per mantenere occupato un ragazzo, allora forse non voglio un ragazzo dedicato. Se il lavoro SQL è roba di base CRUD, quindi non ho bisogno di uno specialista per quello.
E gli opposti sono veri. Se la squadra è ignorante SQL, o l'app è pesante SQL, o SQL è complesso, allora forse uno specialista è la strada giusta da percorrere.
È proprio come qualsiasi altro skillset del team.
Penso che avere una persona t-sql dedicata in una squadra che fa EF sia un lusso, a meno che anche lui o lui non stiano aiutando con il lato .NET del progetto. La maggior parte degli sviluppatori in team di piccole dimensioni, come la tua, dovrebbero avere familiarità con i principi di progettazione e ottimizzazione di SQL necessari per portare il tuo progetto a livelli accettabili di prestazioni. I problemi che i tuoi quattro sviluppatori non riescono a risolvere dovrebbero essere risolvibili tramite Stack Overflow e consulenti a breve termine.
Risposta breve: Dipenderà dallo ambito del progetto e dagli sviluppatori set di abilità .
Ad esempio: un approccio Primo database con EF potrebbe richiedere un buon sviluppatore T-SQL. Perché un solido design DB con, indici, stored procedure e funzioni potrebbe essere molto utile per aree di incremento delle prestazioni mirate all'interno dell'applicazione.
Per un primo approccio al codice senza l'utilizzo di stored procedure complesse probabilmente non hai bisogno di uno sviluppatore T-SQL.
Inoltre, se hai nel tuo team uno sviluppatore che ha solide conoscenze in progettazione di DB, index, query profiling, analisi del piano di esecuzione ... allora hai un ragazzo giusto in una squadra prendersi cura di tutti gli sviluppi di DB che potreste aspettarvi di avere.
Risposta breve:
Questo dipende dalla portata del set di abilità del progetto e degli sviluppatori.
Risposta lunga:
Durante l'acquisizione di specialisti T-SQL o DBA, tu ei tuoi colleghi dovete essere addestrati nel senso che devono avere mentalità e metodologia per gestire lo SQL
Perché lo sviluppo cresce a lungo, i casi SQL e di gestione delle eccezioni devono aumentare ed essere più complicati.