Il collaboratore ha rinominato tutte le mie domande [chiuso]

1. Non proprio - è una cosa incredibilmente irrispettosa da fare.

2. Le hai parlato e non l'abbiamo fatto, ma sembra che tu possa rientrare nei tuoi diritti per ripristinare le precedenti convenzioni di denominazione da un backup o ripristinarle se si trovano in un controllo sorgente. FARE notifica al tuo capo e collega se lo fai e fornisci la tua ragione (non puoi mantenere il tuo lavoro).

L'ultima cosa che vuoi è andare avanti e indietro su questo, ma così gestirlo come sembra la situazione, ma dovrebbe almeno essere documentato nel caso in cui diventi parte di un modello di mancanza di rispetto.

Perché non lo gestisci semplicemente come un adulto: siediti, senza confronto, e fai un elenco di pro e contro per uno schema di denominazione, concorda su uno e rendilo ufficiale scrivendo un breve documento che lo descrive . Eticamente sincero interesse per il suo contributo così lei si sente (ed è) coinvolta.

Se è principalmente una questione di gusti e se è il tipo di persona che deve assolutamente avere le cose a modo suo, allora sii felice che tu sia la persona più grande e lascia perdere. La vita è troppo breve per avere un concorso pissing di schemi di denominazione.

Il problema è lo schema di denominazione o che ritieni di non avere rispetto? Se è così forse puoi lavorare sul tuo rapporto di lavoro. Se senti che non ne vale la pena, allora perché ti importa di quello che pensa comunque? :) Un'altra opzione potrebbe essere che lei non ritenga davvero che sia un grosso problema e se spieghi gentilmente che stai riscontrando problemi nel trovare qualcosa, forse puoi cambiarlo.

1. La progettazione del database include le autorizzazioni (CONCEDERE e REVOCARE).
2. Il test include test permessi.
3. Relativamente poche persone dovrebbero avere permesso di rinominare il database oggetti.
4. Il tuo collega non è uno dei pochi.

"La nuova convenzione sui nomi non ha alcun senso" sembra che uno di questi potrebbe essere il caso:

1. Ha applicato a loro qualche norma aziendale. Questi sono spesso usati per assicurarsi che il codice sia almeno coerente e, nel migliore dei casi, può aiutare cose periferiche come piccoli script personalizzati per trovare facilmente il codice. In questo caso, devi capire la norma e perché "non ha senso" nella tua situazione. Se pensi ancora che sia meglio per tutti gli sviluppatori lasciarlo così com'era, spiega loro perché esattamente il tuo metodo è superiore e chiedi se puoi cambiare la norma (probabilmente OK se sono d'accordo è superiore ) o rinunciarvi nel vostro caso (improbabile e disordinato a lungo termine).
2. Ha inventato il suo standard sul posto e l'ha applicato. Questo è più probabile se è nuova, e lei dovrebbe spiegare la sua logica. Potresti imparare qualcosa e / o lei potrebbe imparare qualcosa se poi spieghi la tua motivazione.

Un punto importante è che non è il tuo (singolare) codice, se è qualcosa che appartiene a, e sarà modificato da, l'intero gruppo. Nessuna critica al codice dovrebbe mai essere incentrata su chi l'ha scritta.

I spoke with the person responsible, and she just downplayed the whole thing.

Allora te lo dirò, senza problemi:

Roll back the changes.

Saluta questa guerra. Il tuo manager dovrebbe supportarti e consolidare la tua autorità.

1) No, non hai più reazioni. Qualcuno ha cambiato il tuo lavoro senza dirlo e lo ha spazzato via quando gli hai chiesto perché. Questo è estremamente irrispettoso e maleducato.

2) Sei il DBA ufficiale, o almeno la persona che è stata nominata custode del DB? Se è così, cambia i nomi e scrivi un documento delle convenzioni su come fai le cose. Inoltre, scrivi un documento in stile "Guida per gli utenti" in modo che se qualcuno debba entrare nel DB e trovare qualcosa che può.

Vorrei inviarlo al gruppo, senza puntare le dita, con una nota utile che saresti felice di sederti e far camminare le persone attraverso alcune delle sfumature della struttura.

Altrimenti, prepara le convenzioni come una squadra e seguile come una squadra.

Da una nota a margine, per qualcuno che ha dovuto testare qualcosa per cambiare i nomi di 300+ query sembra piuttosto infantile. Quanto tempo ha sprecato a fare questo, e solo perché potesse trovare qualcosa? Invece di andare e chiedere aiuto a qualcuno, ha perso tempo, tempo e tempo della compagnia. Per non parlare del fatto che il codice probabilmente si è rotto quando lo ha fatto, perdendo così anche il tempo di un altro membro della squadra.

Se fossi in te, aspetterei che ti calmassi un po ', prova a parlarle di nuovo. Se non funziona, fallo con il capo. Quella sorta di mentalità da cowboy alla fine metterà a dura prova l'intera squadra.

La ridenominazione casuale nel database potrebbe facilmente causare la riduzione di un ambiente di produzione. Se tali procedure venissero referenziate da qualche parte nel codice, potrebbero avere conseguenze gravi. Puoi fare dei rollback, ma se un tester come questo non sa davvero cosa sta facendo, non è tanto lontano da un passo per vedere il tester apportare alcune modifiche alla produzione. Ciò potrebbe significare perdita di attività, motivo per cui dovresti provare a implementare ruoli utente separati per sviluppatori e tester. Lo facciamo con i nostri tester e funziona alla grande. I tester lo apprezzano spesso, perché non devono vivere nella paura di rovinare i dati in tempo reale.

Non sembra essere stato toccato altrove, ma qualsiasi fonte (ad es. una query) inserita in un luogo pubblico dovrebbe trovarsi sotto un sistema di controllo della versione.

Quindi, se un collega di lavoro cambia lo schema di denominazione, puoi tornare facilmente al tuo schema di lavoro facilmente (e vedere le loro modifiche e potenzialmente tornare indietro se necessario). Lega anche le modifiche a utenti specifici, in modo che tu possa vedere chi ha incasinato le cose.

Non guardare un cavallo da regalo in bocca.

In primo luogo, la proprietà collettiva del codice: non dovrebbero essere "tuoi".

In secondo luogo, se li hanno rinominati, allora chiedi il ragionamento sul nuovo schema di denominazione. O stanno usando le domande - nel qual caso è una sorta di loro chiamata; oppure è un primo passo in loro a cominciare a darti un aiuto nel mantenerli.

Se tutti pensano di essere 'tuoi', non te ne sbarazzerai mai e passerai a qualcosa di nuovo.a

Non so se questo è stato chiesto ma quale convenzione di denominazione è la versione ufficiale? Se la tua versione è ufficiale, allora dirò di indirizzare il problema dal punto di vista. Quindi, invece di dire "La persona X ha annullato tutte le mie modifiche", dì semplicemente "La persona X ha apportato modifiche contrarie alle convenzioni di denominazione ufficiali". Se non ci sono convenzioni ufficiali, allora ti suggerisco di farle sapere che non apprezzi le modifiche apportate senza prima consultarti.

In entrambi i casi, penso che intraprendere una "guerra" non sia la risposta. Anche se vinci, perdi.

È un comportamento spaventoso. Sembra che non abbia rimpianti, quindi portalo dal tuo capo e fai una richiesta per far revocare il suo accesso finché non si convincerà a non scherzare.

Se il tuo capo non è tecnico, spiegalo in termini che capirà. Immagina di iniziare a lavorare in una stanza di posta, dove i post vengono ordinati in buche di piccione pronte per la consegna. Decidi unilateralmente di ordinare i fori dei piccioni per piano, poi il cognome anziché l'attuale sistema di dipartimento, quindi il pavimento. Potrebbe renderti la vita più facile a breve termine, ma verrai ucciso dall'altra parte del personale della sala.

È oltre il maleducato. Sarei furioso.

Oltre a impostare permessi per impedire che persone casuali li cambino, dovresti anche spiegare come è il suo lavoro verificare la funzionalità, non puoi dare alcuna garanzia di affidabilità se le persone casuali stanno apportando modifiche al codice.

Come tutti hanno detto, non avrebbe dovuto farlo, se non altro per rispetto per te dato che sei il creatore di queste query.

Detto questo, non vedo nessuno menzionare il fatto che, se avesse rinominato le tue query in primo luogo, era perché non riusciva a dare un senso alla convenzione di denominazione.
Quindi il problema potrebbe essere facilmente risolto documentando la convenzione di denominazione e assicurando che i colleghi abbiano accesso al documento e possano trovare ciò di cui hanno bisogno.

Devi anche stare attento e tener conto di come le altre persone troveranno e useranno le tue query: se la tua convenzione di denominazione non consente loro di svolgere il loro lavoro in modo efficiente, probabilmente dovrai mantenere un elenco più completo delle tue query , utilizzando forse tag e parole chiave concordate in modo che altri possano trovare ciò che stanno cercando.

La chiave qui penso che nessuno lavori in isolamento e il modo migliore per evitare di pestare i piedi l'un l'altro è comunicare e concordare regole di base comuni.

Risponderei allo stesso modo - minimizzando la tua decisione di ripristinare tutto. Basta ripristinare le sue modifiche e scrivere una breve e-mail ai tuoi colleghi:

"Per ora ho cambiato la modifica rXXXX, perché non ho capito che è la convenzione di denominazione. Grazie per aver provato però :)"

Sì, stai esagerando.

C'è qualcosa chiamato controllo della versione che, tra le altre cose, è usato per non dover battere $ #! 7 dai colleghi quando hanno problemi con le tue cose. Basta eseguire il rollback alla versione precedente e bloccare il file quindi lasciandola gestire la rabbia. Questo ti aprirà l'opportunità di spiegare che eseguire cambiamenti radicali sul codice che dipende dalle cose di qualcun altro senza una solida ragione e senza prima chiederlo non è solo sbagliato, estremamente poco pratico e praticamente un peccato.

Ovviamente questo presuppone che la tua convenzione di denominazione sia migliore di quella di lei e che tu possa effettivamente fare il backup di questa decisione con solidi argomenti oggettivi, se così non è la cosa più saggia da fare inizia a cambiare il codice non appena riesci a gestire le modifiche e prova a trovare una convenzione di denominazione migliore la prossima volta.

Non portarlo al tuo capo, il modo maturo per risolverlo è direttamente con il tuo collega, dovrai lavorare con lei dopo di che è stupido da danneggiare la relazione per un litigio facilmente risolvibile.