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

63

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.

anon
źródło
29
Mimo że pracujemy w zespołach, istnieje koncepcja tego, kto jest właścicielem i przed zmianą kodu, którego autorem jest ktoś inny, należy poprosić o pozwolenie. Raz to zrobiłem (wstydzę się powiedzieć) i otrzymałem reprymendę. Kiedy mi się to przydarzyło, zmieniłem to z powrotem i poprosiłem, żeby tego nie robili.
Mike Dunlavey,
30
Pojedynek o świcie! ...
46
Masz kopię zapasową / SVN, prawda? Przywróć do tuż przed jej zmianami i zrelaksuj się.
JYelton,
11
jeśli ktoś zmieni nazwę mojego kodu, wyrwałbym z nich życie jak Shang Tsung!
Glenn Ferrie
24
Jeśli ma jakieś dzieci, zmień ich nazwę.
Matt

Odpowiedzi:

81
  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.

DKnight
źródło
81
Nawiasem mówiąc, jeśli jej rola w projekcie jest w rzeczywistości „testerem”, nie ma absolutnie żadnego prawa do zmiany kodu źródłowego. Kropka. Ale chciałbym dodać, że aby zapobiec takiej sytuacji, powinieneś napisać mały (punktory!) Dokument określający konwencję nazewnictwa, ponieważ w przyszłości Twoja firma może zatrudnić kogoś do współpracy, a nawet koordynować Ciebie, a zmiana jego nazwy byłaby w zakresie jego prawa, gdyby nie było oficjalnej konwencji.
Bruno Brant,
1
Zgadzam się z tą odpowiedzią. Jeśli nic nie zrobisz, ustanowisz precedens, który może zaostrzyć przyszłe spory.
JYelton,
2
Wyjaśnij jej, jak działa konwencja nazewnictwa
GerManson,
13
Upewnij się, że zabierze jej prawa do edycji bazy danych podczas gdy jesteś na to ...
Ant
1
@Ant: Jeśli przykładem OP jest cała historia, myślę, że może to być trochę trudne. Jeśli jest coś więcej (lub nigdy nie powinny mieć prawa do edycji), możesz mieć rację.
BCS,
117

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ć.

konrad
źródło
2
Chciałem powiedzieć, żeby to zmienić i poprosić ją, żeby tego nie robiła, ale twoja odpowiedź jest jeszcze lepsza.
Mike Dunlavey
To całkiem niezłe miejsce.
Wayne Molina,
20
A potem niech zmieni ją na
7
@konrad, przeoczyłeś jedną kluczową kwestię - tester nie ma ani autorytetu, ani żadnego rodzaju działalności gospodarczej zajmującej się tego rodzaju edycją . @anon jest programistą odpowiedzialnym za programowanie, konwencje nazewnictwa są właściwie jego decyzją i nie mogą głosować w komitecie, nie mówiąc już o jednostronnych zmianach dokonanych przez kogoś, kto nigdy nie będzie musiał debugować kodu.
Shadur
36
  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.
Mike Sherrill „Catcall”
źródło
To bardzo dobry punkt. Zastanawiałem się, dlaczego tester miałby do tego dostęp.
Justin Ohms
Ponieważ to Access. W programie Access nie ma GRANTU ani Cofnięcia. W ogóle nie ma żadnych uprawnień.
Kibbee,
7
Właściwie istnieją uprawnienia w Accessie, ale jeszcze nie spotkałem kogoś, kto rozumie, jak mają być używane (nie mówiąc już o ich implementacji)
Mchl
1
Ponieważ bez wątpienia ta sama firma prawdopodobnie nawet nie ma systemów kontroli źródła, nie mówiąc już o wykwalifikowanym DBA, który zablokował Access. btw powinieneś to sprawdzić, nie jest to bardzo trudne.
Anonimowy Wpisz
21

„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ł.

l0b0
źródło
2
+1 dobry punkt. wszyscy inni, którzy odpowiedzą, zakładają, że pytający ma prawidłowy schemat nazewnictwa. Co jeśli on / ona jest tak naprawdę „firmą gromadzącą informacje”. Być może to tester naprawdę ułatwia wszystkim innym (i każdemu nowemu) w firmie wyszukiwanie zapytań.
Anonimowy Wpisz
Słuszne uwagi. Jeśli schemat nazewnictwa jest dobry, wówczas obie strony będą mogły go używać (po przyzwyczajeniu się do niego) bez względu na to, kto go wymyślił.
BCS,
2
@ bcs Nawet w takim przypadku właściwym sposobem byłoby poinformowanie programisty PIERWSZEJ i poproszenie go o zmianę konwencji nazewnictwa, zamiast wkradania się i czekania, aż przyjdzie do pracy następnego dnia i odkryć całą jego / jej strukturę.
Shadur
16

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.

Jim G.
źródło
Zgoda. Najpierw sprawdź z nią, że nie ma dobrego powodu, dla którego nowe imiona są lepsze. Jeśli nie, po prostu zmień to z powrotem.
Richard
11
Kiedy „Stocz tę wojnę” jest zawsze dobrą radą?
Sverre Rabbelier
3
@Sverre Rabbelier: ... Gdy n00b próbuje zainstalować nieoptymalne praktyki oprogramowania. OP próbował ją przekonać. Teraz nadszedł czas, aby rozwiązać problem. Dyskusja na temat reklamy w muzeum z numerem n00b na temat czegoś tak oczywistego jest nieproduktywnym i zmarnowanym ruchem.
Jim G.,
4
@ Jim Być może OP jest nowością?
Joe Phillips
3
Jeśli ona nie jest twoim szefem, zmień to gówno i nie oglądaj się za siebie. Nie mówię o wojnie, ale na pewno nie pozwól, aby ktoś zachowywał się tak, jakby był właścicielem tego miejsca. Kierownicy projektów to ci, którzy mają egzekwować standardy kodowania. Tu nie chodzi o autorytet, ale o doświadczenie, porządek i produktywne środowisko pracy.
Jonathan Henson
10

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.

Tyanna
źródło
8

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.

Morgan Herlocker
źródło
5

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ł.

dr jimbob
źródło
2

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

Wiewiórka
źródło
2

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.

Tundey
źródło
To jedyna poprawna odpowiedź. Jeśli istnieje standard nazewnictwa, wówczas nazwy powinny być zgodne ze standardem, a każdy, kto chce mieć inne nazwy, jest w błędzie. Jeśli nie ma standardu nazewnictwa, powinien istnieć standard nazewnictwa - zespół, kierownik techniczny lub ktokolwiek - powinien go napisać. Takie konwencje kodowania są nudne, ale są istotną częścią struktury społecznej, która pozwala zespołowi działać.
Tom Anderson,
1

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.

Ian
źródło
1

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.

Craig
źródło
1

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.

Renaud Bompuis
źródło
0

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ę. :)”

AareP
źródło
0

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.

Chepech
źródło