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

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?

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.

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.

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

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

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 
 **/

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

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