Współpracownik zmienił nazwę wszystkich moich zapytań [zamknięte]

Nie wiem czy powinienem być bardzo zirytowany czy co. Samodzielnie zbudowałem ponad 300 zapytań dla dużej bazy danych i opracowałem konwencję nazewnictwa, aby móc je później znaleźć. Nikt inny w moim biurze nawet nie wie, jak zbudować zapytanie, ale przyszedłem wczoraj, by przekonać się, że zmieniono ich nazwy. Trudno mi teraz znaleźć rzeczy i próbuję wymyślić, co robić.

Rozmawiałem z osobą odpowiedzialną, a ona po prostu lekceważyła całą sprawę. Powiedziała, że ​​zmieniła ich nazwę, aby łatwiej je znaleźć. Niestety jestem jedynym, który wie, jak je budować, edytować i utrzymywać, a jedynym powodem, dla którego musiała je znaleźć, było przetestowanie zapytań. Nowa konwencja nazewnictwa w ogóle nie ma sensu i mam wrażenie, że cofnęliśmy się w procesie rozwoju.

Próbuję to rozgryźć:

1) Czy przesadzam?

2) Jaki jest najlepszy sposób, aby sobie z tym poradzić? Nie chcę o tym wspominać szefowi, ale po wczorajszej rozmowie ze współpracownikiem już mogę powiedzieć, że czuje się, jakby nie zrobiła nic złego.

1. Nie bardzo - to niesamowicie lekceważąca rzecz.

2. Rozmawiałeś z nią, a my nie, ale wygląda na to, że przysługują Ci prawa do przywrócenia poprzednich konwencji nazewnictwa z kopii zapasowej lub przywrócenia ich, jeśli są pod kontrolą źródła. Powiadom o tym szefa i współpracownika i podaj powód (nie możesz utrzymać własnej pracy).

Ostatnią rzeczą, którą chcesz zrobić, jest wdawanie się w tę i z powrotem w tę kwestię, ale radzę sobie z tym, ponieważ sytuacja wydaje się rozwiać, ale należy to przynajmniej udokumentować na wypadek, gdyby stała się częścią wzoru braku szacunku.

Dlaczego po prostu nie poradzisz sobie z tym jak dorośli: usiądź, bez konfrontacji, i wymyśl listę zalet i wad dla schematu nazewnictwa, uzgodnij jeden z nich i oficjalnie pisz krótki dokument opisujący go. Wywołaj autentyczne zainteresowanie jej wkładem, aby czuła się (i jest) zaangażowana.

Jeśli jest to głównie kwestia gustu i jeśli ona jest osobą, która absolutnie musi mieć rzeczy po swojemu, po prostu ciesz się, że jesteś większą osobą i pozwól temu odejść. Życie jest zbyt krótkie, aby wziąć udział w konkursie na sikanie schematów nazw.

Czy problemem jest schemat nazewnictwa lub czujesz, że nie zyskujesz szacunku? Jeśli tak, być może możesz popracować nad relacją roboczą. Jeśli uważasz, że nie warto, to dlaczego przejmujesz się tym, co ona myśli? :) Inną opcją może być to, że naprawdę nie uważa, że ​​to wielka sprawa, a jeśli ładnie wyjaśnisz, że masz problemy ze znalezieniem rzeczy, być może możesz to zmienić.

1. Projektowanie bazy danych obejmuje uprawnienia (GRANT i REVOKE).
2. Testowanie obejmuje uprawnienia do testowania.
3. Stosunkowo niewiele osób powinno mieć uprawnienia do zmiany nazw obiektów bazy danych.
4. Twój współpracownik nie jest jednym z niewielu.

„Nowa konwencja nazewnictwa w ogóle nie ma sensu” brzmi tak, jakby miała miejsce jedna z poniższych:

1. Zastosowała wobec nich jakąś normę firmy. Są one często używane, aby upewnić się, że kod jest co najmniej spójny, aw najlepszym wypadku mogą pomóc peryferyjnym rzeczom, takim jak małe niestandardowe skrypty, w łatwym znajdowaniu kodu. W takim przypadku musisz zrozumieć normę i dlaczego „nie ma ona sensu” w twojej sytuacji. Jeśli nadal uważasz, że lepiej jest, aby wszyscy programiści pozostawili ją taką, jaka była, wyjaśnij im, dlaczego dokładnie twoja metoda jest lepsza, i zapytaj, czy możesz zmienić normę (prawdopodobnie OK, jeśli zgadzają się, że jest lepsza) lub zrezygnować z niej w twoim przypadku (mało prawdopodobne i niechlujne w dłuższej perspektywie).
2. Wymyśliła na miejscu swój własny standard i zastosowała go. Jest to bardziej prawdopodobne, jeśli jest nowa i powinna wyjaśnić swoje uzasadnienie. Możesz się czegoś nauczyć i / lub ona może się czegoś nauczyć, jeśli następnie wyjaśnisz swoje uzasadnienie.

Ważną kwestią jest to, że nie jest to twój (pojedynczy) kod, jeśli cokolwiek należy i będzie modyfikowane przez całą grupę. Nie należy nigdy krytykować kodu, kto go napisał.

Rozmawiałem z osobą odpowiedzialną, a ona po prostu lekceważyła całą sprawę.

Więc powiem ci bezwstydnie:

Cofnij zmiany.

Tocz tę wojnę. Twój menedżer powinien cię wspierać i umocnić swój autorytet.

1) Nie, nie reagujesz zbytnio. Ktoś zmienił twoją pracę, nie mówiąc ci o tym, i odrzucił ją, kiedy spytałeś ich dlaczego. To bardzo pozbawiony szacunku i niegrzeczny imho.

2) Czy jesteś oficjalnym DBA, a przynajmniej osobą, która została posiadaczem DB? Jeśli tak, zmień nazwy i napisz dokument konwencji o tym, jak to robisz. Napisz również dokument w stylu „Podręcznik użytkownika”, aby ktoś musiał wejść do bazy danych i znaleźć coś, co może.

Wysłałbym to do grupy, nie wskazując palcami, z pomocną notatką, że chętnie usiądziesz i poprowadzisz ludzi przez niektóre niuanse struktury.

Jeśli nie, wymyśl konwencje jako zespół i postępuj zgodnie z nimi jako zespół.

Na marginesie, dla kogoś, kto musiał przetestować coś, aby zmienić nazwy ponad 300 zapytań, wydaje się dość dziecinna. Ile czasu marnowała, robiąc to, i tylko po to, żeby znaleźć rzeczy? Zamiast po prostu iść i poprosić kogoś o pomoc, zmarnowała swój czas, twój czas i czas firmy. Nie wspominając już o tym, że kod prawdopodobnie złamał się, gdy to zrobiła, marnując w ten sposób czas innego członka zespołu.

Gdybym był tobą, czekałbym, aż trochę się ochłodzisz, spróbuj ponownie z nią porozmawiać. Jeśli to nie zadziała, weź to z szefem. Ten rodzaj mentalności kowbojskiej ostatecznie doprowadzi do upadku całego zespołu.

Losowa zmiana nazwy w bazie danych może łatwo spowodować awarię środowiska produkcyjnego. Odwołanie się do tych procedur gdzieś w kodzie może mieć poważne konsekwencje. Możesz cofać, ale jeśli taki tester tak naprawdę nie wie, co robi, to nie jest tak daleko, aby zobaczyć, jak tester wprowadza pewne zmiany w produkcji. Może to oznaczać utratę działalności, dlatego powinieneś spróbować wdrożyć osobne role użytkowników dla programistów i testerów. Robimy to z naszymi testerami i działa świetnie. Testerzy często to doceniają, ponieważ nie muszą żyć w obawie przed zepsuciem danych na żywo.

Wydaje się, że nie jest poruszany gdzie indziej, ale każde źródło (np. Zapytanie) umieszczone w miejscu publicznym powinno podlegać systemowi kontroli wersji.

Następnie, jeśli współpracownik zmieni schemat nazewnictwa, możesz łatwo powrócić do schematu roboczego (i zobaczyć ich zmiany; i ewentualnie przywrócić w razie potrzeby). Wiążesz także zmiany z konkretnymi użytkownikami, abyś mógł zobaczyć, kto coś pomieszał.

Nie patrz końowi prezentowi w usta.

Po pierwsze, własność zbiorowego kodu - nie powinny być „twoje”.

Po drugie, jeśli zmienili ich nazwy, zapytaj o uzasadnienie dotyczące nowego schematu nazewnictwa. Albo używają zapytań - w takim przypadku jest to rodzaj ich połączenia; lub jest to pierwszy krok w tym, że zaczynają ci pomagać w ich utrzymaniu.

Jeśli wszyscy myślą, że są „twoje”, nigdy się ich nie pozbędziesz i przejdziesz do czegoś nowego. A

Nie wiem, czy o to pytano, ale która konwencja nazewnictwa jest oficjalną wersją? Jeśli twoja wersja jest oficjalna, powiem o rozwiązaniu problemu z perspektywy. Zamiast więc powiedzieć „Osoba X wycofała wszystkie moje zmiany”, po prostu powiedz „Osoba X dokonała zmian sprzecznych z oficjalnymi konwencjami nazewnictwa”. Jeśli nie ma oficjalnej konwencji, sugeruję poinformowanie jej, że nie doceniasz wprowadzonych zmian bez uprzedniej konsultacji.

W obu przypadkach myślę, że przeprowadzenie „wojny” nie jest odpowiedzią. Nawet jeśli wygrasz, przegrasz.

To przerażające zachowanie. Wygląda na to, że nie żałuje, więc zanieś to swojemu szefowi i zrób sprawę, aby jej dostęp został cofnięty, dopóki nie zostanie przekonana, że ​​nie będzie się bałagać.

Jeśli twój szef nie jest techniczny, wyjaśnij to w sposób zrozumiały. Wyobraź sobie, że zaczynasz pracę w pokoju pocztowym, w którym poczta jest sortowana w gołębiach gotowych do wysyłki. Decydujesz jednostronnie, aby posortować dziury dla gołębi według podłogi, a następnie nazwiska zamiast obecnego systemu wydziału, a następnie podłogi. W krótkim okresie może to ułatwić ci życie, ale zostaniesz zamordowany przez innych pracowników poczty.

To jest nieuprzejme. Byłbym wściekły.

Oprócz ustawiania uprawnień, aby zatrzymać przypadkowe osoby zmieniające je, powinieneś również wyjaśnić, ponieważ jej zadaniem jest testowanie funkcjonalności, nie możesz dać żadnej gwarancji niezawodności, jeśli przypadkowe osoby wprowadzają zmiany w kodzie.

Jak wszyscy mówili, nie powinna tego robić, choćby z szacunku dla ciebie, ponieważ jesteś twórcą tych zapytań.

Powiedziawszy to, nie widzę, aby ktokolwiek wspominał fakt, że jeśli zmieniła nazwę twoich zapytań w pierwszej kolejności, to dlatego, że nie mogła zrozumieć twojej konwencji nazewnictwa.
Tak więc problem można łatwo rozwiązać, dokumentując konwencję nazewnictwa i zapewniając, że współpracownicy mają dostęp do dokumentu i mogą znaleźć to, czego potrzebują.

Musisz także zachować ostrożność i wziąć pod uwagę, w jaki sposób inne osoby będą znajdować i korzystać z twoich zapytań: jeśli twoja konwencja nazewnictwa nie pozwala im na wydajne wykonywanie pracy, prawdopodobnie musisz zachować dokładniejszą listę twoich zapytań, używając być może tagi i uzgodnione słowa kluczowe, aby inni mogli znaleźć to, czego szukają.

Uważam, że kluczem tutaj jest to, że nikt nie pracuje w izolacji, a najlepszym sposobem uniknięcia wzajemnego stąpania jest porozumienie się i uzgodnienie wspólnych podstawowych zasad.

Odpowiedziałbym w ten sam sposób - bagatelizując twoją decyzję o cofnięciu wszystkiego. Po prostu cofnij jej zmiany i napisz naprawdę krótką wiadomość e-mail do współpracowników:

„Na razie cofnąłem zmianę rXXXX, ponieważ nie rozumiałem tej konwencji nazewnictwa. Dziękuję za próbę. :)”

Tak, przesadzasz.

Jest coś, co nazywa się kontrolą wersji, które między innymi nie musi bić $ 7! Ze współpracowników, gdy robią bałagan z twoimi rzeczami. Po prostu cofnij się do poprzedniej wersji i zablokuj plik, pozwalając jej opanować gniew. To otworzy Ci możliwość wyjaśnienia, że ​​dokonywanie radykalnych zmian w kodzie, które są zależne od cudzych rzeczy bez solidnego powodu i bez uprzedniego pytania, nie jest po prostu złe, wyjątkowo niepraktyczne i praktycznie grzechem.

Oczywiście zakłada to, że twoja konwencja nazewnictwa jest lepsza niż jej i że możesz faktycznie wykonać kopię zapasową tej decyzji za pomocą solidnych obiektywnych argumentów, jeśli nie jest to najmądrzejsza rzecz, aby zrobić zmianę kodu, jak tylko będziesz w stanie obsłużyć zmiany i spróbuj wymyślić lepszą konwencję nazewnictwa następnym razem.

Nie zabieraj go do swojego szefa, dojrzały sposób na rozwiązanie go bezpośrednio ze współpracownikiem, po tym będziesz musiał z nią pracować, więc głupio jest zepsuć relację w przypadku łatwej do rozwiązania kłótni.