Czy powinienem zmienić nazwisko autora w pliku klasy, jeśli dokonam więcej niż 80% zmian?

18

Refaktoryzuję istniejący zestaw klas testów Java do automatycznych testów interfejsu użytkownika. Czasami robię ogromne zmiany w pliku klasy lub całkowicie go przerabiam. To sprawia, że ​​myślę, że kiedy przepisuję całą klasę, czy powinienem zmienić nazwisko autora w sekcji komentarza na moje?

Czy jestem chciwy? czy może przydałoby się zobaczyć moje imię i zapytać mnie w razie wątpliwości?

Tarun
źródło
17
Czy używasz kontroli wersji? Uważam, że dzienniki zatwierdzania są bardziej niezawodnym mechanizmem śledzenia autorstwa (jeśli kiedykolwiek istnieje uzasadniona potrzeba dowiedzenia się ...)
rwong
5
Nazwa powinna tam być, jeśli ma jakąkolwiek wartość w kodzie. Czyli osoba kontaktowa. Odpowiedzialność i tak dalej. A jeśli tak, to przyklej go z datą zakończenia i nową nazwą.
Niezależny
15
Jaki jest cel posiadania nazwiska autora w plikach zajęć?
BЈовић
2
Jeśli plik ma symbol zastępczy dla nazwiska autora, istnieje prawdopodobieństwo, że ma on również symbol zastępczy dla dziennika zmian. Umieściłbym swoje nazwisko w dzienniku zmian zamiast oryginalnego autora. W każdym razie nigdy nie zostawiam własnych odcisków palców na kodzie, który piszę, tylko tych mojego szefa.
mouviciel,
1
co jest złego w pozostawieniu ich nazwiska jako autora i dodaniu poniżej wiersza z napisem „przepisana / zrefaktowana data imienia”
Ryathal

Odpowiedzi:

15

To naprawdę zależy ...

Jeśli uważasz, że istnieje niewielka szansa, że ​​ktoś inny może być później zainteresowany pytaniem oryginalnego autora, podaj jego nazwisko w kodzie. Jeśli uważasz, że ktoś może cię zapytać osobiście, podaj w nim swoje imię i nazwisko. A jeśli uważasz, że oba mogą być możliwe, wpuść oba nazwiska (lub komentarz typu „na podstawie pracy ...”).

Oczywiście, gdy stosowanie kontroli źródła jest obowiązkowe w miejscu pracy i jest to jedyny sposób uzyskania dostępu do źródeł, zapisz kłótnię i usuń wszystkie komentarze autora ze źródła. Na przykład w moim miejscu pracy mamy wiele plików źródłowych pod kontrolą źródła, w których nie zawracamy sobie głowy pisaniem nazw w źródłach. Jeśli chcę wiedzieć, kto jest odpowiedzialny za plik, był w przeszłości lub za konkretną zmianę, TortoiseSVN z łatwością wygeneruje mi dziennik.

Z drugiej strony mamy wiele makr VBA, napisanych przez niektórych facetów, przekazanych innym (niektórzy z nich opuścili firmę z biegiem lat) i wiele zostało zmodyfikowanych, wszystkie bez użycia kontroli źródła. Na szczęście komentarze tych plików zawierają często nazwiska autorów i pewnego rodzaju dziennik historii.

Doktor Brown
źródło
13

Właśnie natknąłem się na inny post, w którym OP pyta, czy nazwisko autora powinno być w nagłówku pliku i wydaje się, że co najmniej 2/3 osób, które odpowiedziały, stwierdziło, że nazwa nie powinna być nawet wymieniona i że należy użyć kontroli wersji, aby po prostu śledź, kto zmienił plik. Nie wiem, co się stało z tym postem, ale teraz nie mogę go znaleźć. <- (stąd anonimowy „OP”)

Osobiście uważam, że autor wymieniony w nagłówku pliku jest przydatny, ale z nieco innego powodu (i może to nie dotyczyć innych w ich środowiskach). Mimo że staramy się ćwiczyć własność społeczności i często pracujemy nad różnymi częściami projektu, zwykle mamy niewielu członków zespołu, którzy znają pewne obszary kodu o wiele bliżej niż inne. Kiedy więc ktoś (szczególnie wielu wykonawców, którzy przychodzą i odchodzą) otworzy plik, którego nigdy wcześniej nie widział, autor staje się osobą przechodzącą. Może nie być jedynym współpracownikiem, a nawet większościowym, ale mając swoje nazwisko na szczycie, przyznaje się do pewnej odpowiedzialności za rozpowszechnianie wiedzy / informacji o kodzie wśród reszty zespołu. W nagłówku możemy wymienić więcej niż jedną osobę, ponieważ wiele osób rzeczywiście przyczyniło się i czuje się odpowiedzialnych.

To frustrujące, gdy mam pytanie dotyczące pliku i muszę uciekać się do kontroli wersji, aby zidentyfikować osobę podstawową lub najlepiej znającą się na wiedzy. Potem przechodzą od jednego faceta do drugiego, ponieważ wszyscy zaprzeczają, że naprawdę wiedzą, co robi kod ... po prostu musieli wejść i naprawić błąd.

Ta praktyka działa w naszym zespole, ponieważ nie mamy hand-offów. O ile dana osoba nie zrezygnuje lub nie przeprowadzi się do innego zespołu, ten kod / projekt pozostanie z osobą i naszym zespołem. Oczywiście, jeśli ludzie, którzy utrzymują kod, nie są tacy sami, jak ci, którzy go piszą, to nikogo nie obchodzi, kto jest wymieniony w nagłówku.

Więc w świetle mojego poglądu na nagłówki plików powiedziałbym, że jeśli zmieniłeś 80% pliku i czujesz, że jesteś teraz zwykłym facetem na wszelkie pytania (i prawdopodobnie powinieneś tak poczuć), tak, idź i zaktualizuj nagłówek pliku, aby mieć na nim swoje imię. Jeśli czujesz się źle z powodu usunięcia poprzedniej osoby, możesz zostawić tam również jej nazwisko, przynajmniej na razie. Zawsze możesz zapytać oryginalnego autora i jestem pewien, że nie będzie miało to nic przeciwko, że zmieniłeś nazwę, ponieważ zakładam, że nie ma żadnych trudności w zmianie 80% samego pliku.

AKTUALIZACJA: Znaleziono ten post . Nie mam pojęcia, jak udało mi się wycofać coś z sierpnia. Właśnie skończyłem czytać The Pragmatic Programmer, aw ostatnim rozdziale autorzy opowiadają o podpisywaniu pracy i rozliczalności (inny post wspomniał o niej, dlatego ją sprawdziłem). Książka ma sens i teraz, gdy o niej myślę, może powinniśmy wprowadzić zasady zespołu, że ktokolwiek jest wymieniony jako autor, powinien być uwzględniony we wszystkich recenzjach kodu danego pliku. Nie ma znaczenia, kto zmienił plik jako ostatni lub najbardziej w SVN, autor jest właścicielem i opiekunem.

DXM
źródło
1
Widzę twoje punkty, ale kto to jest „OP”?
Tarun,
Może istnieć strona projektu lub wewnętrzna wiki, na której można umieścić dane kontaktowe, aby wszyscy mogli je zobaczyć. Trudności z przekazaniem tych informacji (dokumentacji i osób kontaktowych) do kontroli źródła powstają ... podczas rozgałęziania i łączenia.
rwong
@ Tarun: OP = „oryginalny plakat” (tzn. Osoba zadająca pytanie). Jest to wyrażenie używane na forach dyskusyjnych online.
sleske,
Zgadzam się z @Tarun, link do postu pomógłby znaleźć odpowiedź w perspektywie. Zgaduję, że to ten ?
yannis,
1
@rwong: Dlaczego podczas rozgałęziania i łączenia występuje problem? Zwykle osoba, która łączy zmianę, powinna ją zrozumieć (w przeciwnym razie, dlaczego ją łączy?). Więc osoba w dzienniku jest tym, o którą należy zapytać.
sleske,
5

Nie uważam, żeby nazwisko autora było bardzo przydatne. Jak pokazuje to pytanie, często nie ma jednego autora, więc nazywanie „autora” nie jest możliwe.

Możesz oczywiście dołączyć listę wszystkich osób, które wniosły duży wkład, ale możesz to już uzyskać z dziennika kontroli wersji - więc po co?

W moim projekcie w większości plików nie ma informacji o autorze. Jeśli masz pytanie, po prostu zajrzyj do dzienników i zazwyczaj jest oczywiste, że jedna lub dwie osoby wykonały większość pracy, więc zadaj je.

Edytować

Odpowiedź zakłada projekt wykorzystujący kontrolę wersji. Jeśli nie (konsekwentnie) korzystasz z VC, umieszczenie autora (listy) i być może historia zmian w pliku może być dobrym rozwiązaniem. Nadal powinieneś zacząć używać VC tak szybko, jak to możliwe, w takim przypadku patrz wyżej :-).

Śleske
źródło
so what's the point?Projekty, które nie są objęte Vcs, projekty, które w pewnym momencie migrowały na inne Vcs (nie wszystkie schematy migracji umożliwiają niestety migrację historii) oraz projekty, które używają więcej niż jednego Vcs jednocześnie - niektóre projekty FLOSS przyjmują to podejście, aby ułatwić ludziom wkład, bez ograniczania ich do jednego vcs (ludzie svn uważają, że git hard, git ludzie uważają, że svn jest bezużyteczny, a my hg ludzie śmieją się z obu)
yannis
1
@YannisRizos: OK, to prawda. Domyślnie założyłem, że każdy projekt oprogramowania użyje kontroli wersji. Edytowałem moją odpowiedź.
sleske,
I oczywiście moje inne punkty powinny być łatwo rozwiązane za pomocą drobnych vcs-fu, niezależnie od zaangażowanych vcs. Ale w praktyce rzadko są niestety.
yannis,
2

Jeśli plik został znacznie zmodyfikowany, dopuszczalne jest dodanie w nim Twojego nazwiska jako osoby, która coś o nim wie.

Paul Nathan
źródło
1

Twórca pliku źródłowego powinien / musi zawsze (IMHO) być wymieniony w pliku źródłowym. To, przy dobrym komentowaniu nagłówków, powinno pokazać, dlaczego autor opracował źródło i jakie było jego zdanie na temat pisania kodu. Jeśli chodzi o opiekuna kodu, dodanie nazwy opiekuna jest kluczowe dla śledzenia kontroli źródła.

Nazwę autora, ponownie IMHO, powinna zawierać źródłowa wersja kodu, poza systemem kontroli wersji, pierwsza data wystąpienia zmiany, a także numer żądania zmiany. Powodem jest to, że jeśli pojawi się decyzja o zmianie VCS, istnieje historia wersji kodu, kim był autor, a także numer żądania zmiany, do którego programiści mogą się odwoływać (jeśli muszą wiedzieć, dlaczego opiekun zrobił to, co on / ona zrobiła). Dlatego w naszej organizacji nasz format jest następujący:

/**
 * $comment
 * <p />
 * $cr_number, $date, $author, $description 
 **/
Buhake Sindi
źródło
3
„jeśli pojawi się decyzja o zmianie VCS, istnieje historia wersji kodu”. Mam nadzieję, że żadna rozsądna organizacja nawet nie rozważy migracji VCS bez migracji historii (przynajmniej najnowszej). W końcu o to właśnie chodzi w korzystaniu z VCS.
sleske,
1
Całkowicie się nie zgadzam. Tego rodzaju informacje należy śledzić za pomocą kontroli wersji. W przeciwnym razie naprawdę nie ma sposobu, aby dowiedzieć się, kto dokonał zmian w jakich wierszach (zakładając, że nad plikiem pracowała więcej niż jedna osoba). Umieszczenie go w pliku jest po prostu duplikatem niskiej jakości informacji dostępnym gdzie indziej.
Bryan Oakley,
1
@Bryan Oakley, w ogóle nie usuwam kontroli wersji, stwierdzam, że rozpoznanie własnego kodu jest sposobem na poznanie, kto pracował na źródle, bez konieczności wykonywania koniecznego wyszukiwania za pomocą kontroli wersji. Poza tym istnieją pewne kody, które są dostępne poza systemami kontroli wersji, czy należy wykluczyć nazwisko autora?
Buhake Sindi,
1

Lubię patrzeć na nazwisko autora, choćby po to, by znaleźć kogoś, kto mógłby zacząć moje poszukiwania odpowiedzi na temat kodu. (Autor zwykle nie pamięta, ale to przynajmniej strzał!)

Polecam po prostu dodać swoje imię i nazwisko poniżej oryginalnego autora.

Nie ma potrzeby zastępowania nazwiska drugiej osoby, ponieważ może ona znać pewien aspekt pierwotnej potrzeby biznesowej, którego ty nie znasz, a także inne osoby, które podążą za tobą, a także być może będą musiały z nią porozmawiać.

ka9cql
źródło
+1 za trzeci akapit, ponieważ oryginalny autor może znać inną osobę, która zrobiła coś w kodzie, ale nie umieściła na nim swojego imienia.
Coyote21
1

Moja polityka dotycząca komentarzy @author to:

  1. Jeśli jest to zupełnie nowy plik, podaję się jako @author.
  2. Jeśli jest to istniejący plik, zostawiam @author w spokoju, niezależnie od tego, co zrobię z plikiem.

Jeśli masz pytania dotyczące czegoś, nie ma znaczenia, kto jest @authorsem pliku - ważne jest, kto @author jest częścią edytowanego fragmentu pliku. Po to [git/svn/whatever] blamejest.

IMO, @author musi odejść.

Michael Moussa
źródło
Z jednej strony podajesz się jako autor w nowym pliku. Z drugiej strony chcesz, żeby autor odszedł?
Anthony Pegram,
1
Standardy kodowania w firmie wymagają obecności znacznika @author. W przeciwnym razie nie używałbym go wcale (bo chcę, żeby zniknął :)).
Michael Moussa,