Sto lavorando a un progetto con un team di 4-5 persone. È necessario discutere le modifiche al database con il team prima dell'implementazione? Sto lavorando alle API del database.
È meglio discuterne o no? Nella mia squadra ci sono persone anziane. Quindi non posso apportare modifiche io stesso e attuare il cambiamento e spiegare i cambiamenti.
La struttura della tabella riflette le relazioni tra il tuo oggetto. Tali cambiamenti sono abbastanza importanti e dovrebbero essere discussi.
Non penso che questo sia solo legato alle modifiche del database.
Se non sei il Senior Architect o Database Programmer del tuo team, qualsiasi modifica tu faccia per progettare & l'implementazione di codice o tabelle SQL o DB o qualsiasi altra risorsa, deve essere esaminata e approvata da altri membri del team, peer o senior.
Sei esitante a farlo? Non esiste già un processo di revisione formale?
Aggiornamento:
Nel tuo caso, dipende dall'impatto dei cambiamenti. Stai facendo una piccola modifica come la lunghezza di una singola colonna VARCHAR2 o aggiungendo nuove colonne alla tabella che hanno bisogno di un buy-in anche dagli sviluppatori front-end? In ogni caso, direi che la discussione è meglio che non farlo e rimpiangere in seguito
Non penso che ci sarà una buona risposta generale. Dipende veramente dal fatto che il lavoro degli altri membri del team sarà influenzato da ciò che fai o meno (anche se tendo a pensare che i cambiamenti della struttura del database influenzeranno altri codici). Se la progettazione del database e l'API sono di esclusiva responsabilità dell'utente, il minimo che si dovrebbe fare è INFORMARE alle persone le modifiche che potrebbero interessarli. Se non sei sicuro degli effetti, CHIEDI i membri del team in modo da poter giudicare i compromessi e prendere la migliore (ri) decisione di progettazione: la squadra nel suo complesso ne beneficerà.
Se ci sono altre persone che possono apportare modifiche al database o condividere le tue responsabilità, sarà necessario COORDINARE tutto. Puoi chiamare questa DISCUSSIONE, ma non vedo nulla di negativo, a meno che il modo in cui la tua squadra discute le cose sia percepito come un giudizio / critica ingiusta del tuo lavoro. Se è così capisco perché ti senti a disagio. Ma il modo per risolvere questo non è pensare a cosa discutere e cosa no, ma a cambiare il "come" per discutere e cambiare lo spirito di squadra.
Dipende da cosa intendi per "discutere".
Se per "discutere" intendi "dibattito" o "progetto per comitato", dico di no. Lo sviluppatore che è il proprietario di una sezione di un'applicazione arriva a dire come appare lo schema.
Se, invece di "discutere" le modifiche al database, cambi il database e non fai sapere a nessuno finché il loro codice non va a buon fine, io dico di sì, "la discussione" è fondamentale.
Come già sottolineato da altri, è decisamente meglio discuterne. Questo è particolarmente vero in caso di modifiche al database. Il database, essendo praticamente il livello più basso, significa che eventuali modifiche ad esso (sia aggiunte, ma soprattutto modifiche) possono potenzialmente avere l'impatto PIÙ GRANDE per gli sviluppatori del team.
Un processo di revisione formale è OBBLIGATORIO (e preferibilmente questo deve essere fatto dall'architetto dati / dba / qualcuno che possiede lo schema) ma anche se questo è in atto, consiglierei comunque una discussione con i membri del team sui dati specialmente le modifiche dello schema prima della mano.
Persone con una comprensione tecnica / dominio / applicativa più ampia di quella che potresti essere in grado di evidenziare insidie / necessità / modifiche al tuo approccio in una fase precedente rispetto a una revisione che ti fa risparmiare tempo e fatica (se hanno ragione)
Questo sembra un cambiamento di design. Questo deve essere fatto in fase di progettazione. Questo dovrebbe essere esaminato nella revisione del progetto.
Quindi la mia risposta breve è Sì. Fatti rivedere il più presto possibile. Perché se non viene revisionato e qualcun altro lo ha ancora creato, quella persona sicuramente si incazzerà.
Non hai riunioni di gruppo? Mischie giornaliere o incontri settimanali di stato o qualcosa del genere? Questo è il tipo di cosa che mi aspetterei di suscitare in questi incontri. Non sembra che i cambiamenti siano così significativi da richiedere un equo avvertimento, ma sono presumibilmente abbastanza importanti da giustificare modifiche all'API, quindi le persone dovrebbero sicuramente essere informate. La tua squadra usa un wiki? Se è così, allora forse creare una pagina che elenca le modifiche del database e la data in cui sono state fatte. In alternativa, se stai utilizzando un sistema di segnalazione di bug, potresti creare un problema di "modifica" o "miglioramento" e descrivere la modifica lì.
iff tu possiedi l'API e le tue modifiche non influenzano gli altri, quindi ti terrei in grado di avere le mani libere nel fare ciò che è necessario per il tuo lavoro.
A è appena le tue modifiche influenzano gli altri diventa un problema di squadra.