Jeśli napotkam niekrytyczną literówkę w kodzie (powiedzmy, błędną apostrofę w instrukcji print (error)), czy warto podjąć zobowiązanie, aby rozwiązać ten błąd, czy może po prostu należy go zostawić w spokoju?

W szczególności jestem ciekawy, jak porównać przeglądanie dziennika zmian do wartości rozwiązania tych niekrytycznych literówek. Skłaniam się do ich rozwiązania. Czy jestem pedantyczny?

Osobiście uważam, że poprawa jakości jest warta drobnych niedogodności związanych z dodatkowym wpisem w dzienniku zatwierdzeń, nawet w przypadku drobnych ulepszeń. W końcu małe ulepszenia liczą się bardzo, gdy weźmie się pod uwagę efekt rozbicia okna .

Możesz chcieć poprzedzić go TRIVIAL:tagiem lub oznaczyć jako trywialny, jeśli twój VCS go obsługuje.

Nie jesteś pedantyczny i lepiej rozwiązywać je indywidualnie. Im bardziej atomowa jest zmiana, tym lepiej - nie chcesz, aby naprawiana usterka była mieszana z 500 zmianami komentarzy / literówek.

W ogólnym przypadku: tak

To zawsze warto zwiększyć konserwacji swojego oprogramowania.

Po prostu to zrób.

Jeśli masz zamiar wysłać wydanie ...

... a jeśli nie jesteś liderem zespołu, skontaktuj się z nim / nią .

Odnośnie zawartości dziennika zmian ...

Zgadzam się z innymi, że powinieneś przynajmniej napisać coś, co odróżnia go od zatwierdzeń związanych z „cechą”, jeśli chodzi tylko o naprawienie pojedynczej literówki.

Powszechną praktyką jest wykonywanie w narzędziu do śledzenia problemów niektórych niekończących się zadań w celu śledzenia ponadczasowych i niekończących się zmian. Na przykład często zdarza się, że masz zadanie:

• duże zautomatyzowane nieszkodliwe porządki (zamiatanie białych znaków),
• polowania na gramatykę i literówki,
• budować modyfikacje systemu,
• itp...

Tylko bądź ostrożny, aby nie były one używane jako wyrzucane identyfikatory zadań dla prawie wszystkiego, gdy ludzie leniwie robią poprawnie udokumentowane bilety. Zwłaszcza jeśli odrzucisz zatwierdzenia, które nie są powiązane z identyfikatorem (to dobrze, ale duże zadania takie będą jeszcze bardziej atrakcyjne dla leniwych programistów).

Literówki należy dodać jako zatwierdzenie. Naprawa błędnie napisanych słów lub błędów gramatycznych zwiększy czytelność twojego kodu.

Użycie komunikatu zatwierdzenia, takiego jak „Naprawiono literówkę” lub „Naprawiono literówkę w pliku.c” pomoże ci odróżnić te zatwierdzenia od innych, głównych zatwierdzeń kodu.

Tak, absolutnie powinieneś to zrobić, szczególnie na początku projektu.

Dlaczego? Dwa punkty:

1. Prawdopodobnie nie będziesz wiedział, czy literówka jest „krytyczna”, czy nie, dopóki nie będzie za późno. Niektóre poprawki prawdopodobnie nie zostaną naprawione, ponieważ wszyscy myślą, że to nie będzie wielka sprawa. Aż tak będzie.

2. Wcześniejsze i celowe naprawianie literówki będzie znacznie łatwiejsze niż naprawianie po kilkuset wierszach wywołań kodu / funkcji. Ponownie, tymczasowe włamania mogą zaskakująco szybko stać się półtrwałe. Dlatego mam do czynienia z obiektami, które mają zarówno metody „CollapseAll” ORAZ „ColapseAll”.

W przypadku błędów gramatycznych, które mogą być widoczne dla użytkownika końcowego, to tak, za wszelką cenę warto dokonać zatwierdzenia, ponieważ jest całkiem możliwe, że użytkownik lub QA może przyjść i zgłosić błąd i będzie musiał być śledzony. Jeśli jest już naprawiony, może przyspieszyć czas potrzebny do rozwiązania problemu.

Jeśli jednak jest to błąd gramatyczny w komentarzach do kodu, nie zrobiłbym nic, chyba że jest to część zmian w rzeczywistym kodzie, w którym to przypadku aktualizujesz dokumentację kodu.

Jeśli martwisz się o zebranie dziennika zmian, robisz coś innego źle. :-) Częste zmiany są dobrą rzeczą! Cały czas popełniam poprawki literówek. Wkrocz do bazy kodów jak najszybciej i przyśpiesz cykl tworzenia aplikacji!

Głosuję tak. Zamelduj się. Pracowałem dla firmy, która nienawidziła osób sprawdzających rzeczy. Mam na myśli prawie wszystko. Recenzje kodu były obszerne, więc jeśli zarejestrowałeś zmianę, która naprawiła literówkę, na którą narzekałeś. Możesz sobie wyobrazić stan kodu. W rzeczywistości kod nie był straszny, ale płynął jak melasa, a nie płynął jak wino.

Czy proces zarządzania zmianami na to pozwala?

W moim środowisku każde zatwierdzenie, które dokonuję, musi być powiązane z żądaniem zmiany, o które poprosili użytkownicy biznesowi lub obowiązkowa zmiana na poziomie systemu, wraz z odpowiednimi procesami testowania użytkownika końcowego. Prosta literówka, którą opisujesz, prawdopodobnie nie zostałaby zapisana jako jedna z tych (znalazłem literówki i błędy gramatyczne w jednej z moich aplikacji, które istniały przez ponad 4 lata, nikt tego nie zauważył), więc jeśli / kiedy przyjdą audytorzy dzwoniąc, miałbym bardzo trudne wytłumaczenie siebie.

Zapisałbym zmianę, którą opisujesz (a tak naprawdę ją mam - nazwa metody jest błędnie napisana i właśnie ją odkryłem) na czas, kiedy mam „prawdziwą” zmianę, która musi być wykonane również i umieścić w dzienniku „naprawiono różne literówki”.

Użyj DVCS do edycji historii

Jeśli obawiasz się o czystą historię zatwierdzeń, rozważ wykonanie głównej pracy w gałęziach funkcji . Jeśli zdarzy ci się pracować z rozproszonym VCS , możesz łatwo edytować swoją historię zatwierdzeń przed przekazaniem jej do głównej gałęzi. Jeśli korzystasz z SVN, wypróbuj Git - może on współdziałać dwukierunkowo z Subversion, a także możesz edytować historię, zanim przystąpisz do Subversion.

W przeciwnym razie zachowaj zdrowy rozsądek

Jeśli nie chcesz lub nie możesz edytować historii zatwierdzeń, nie ma funkcjonalnego powodu, aby zrobić wczesne lub atomowe zatwierdzenie niewielkiej literówki , która nie wpływa na automatyczne testy lub kompilację . W tym przypadku, moim zdaniem, utrzymywanie historii zmian w czystości powinno być ważniejsze niż dokonywanie naprawdę atomowych zmian. Mieszanie jednej lub dwóch poprawek literowych z „zwykłą” modyfikacją nie zaszkodzi żadnemu potencjalnemu procesowi przeglądu. Możesz jednak zgrupować kilka trywialnych poprawek w jednym zatwierdzeniu, być może podczas „czyszczenia” po większej sesji kodowania.

Zauważ, że błędy funkcjonalne nadal powinny być zatwierdzane jak najszybciej w zatwierdzeniu atomowym.

Ogólny ton odpowiedzi tutaj sugeruje strategię „szybko wszystko zatwierdzaj” nawet w przypadku niewielkich literówek. Zwykle nie zgadzam się i witam dyskusję.