Kiedy przeglądam zmiany w żądaniu ściągnięcia, czasami natrafiam na komentarz z notatką „DO ZROBIENIA”, który może być tam z różnych powodów, w naszym przypadku głównie z powodu:
- rozwiązanie zastosowane do rozwiązania problemu można ulepszyć, ale wymagałoby to znacznie więcej czasu. Autor wybrał szybsze rozwiązanie, ale skomentował, że lepsza opcja jest potencjalnie dostępna
- istnieje tymczasowy kod do obejścia istniejącego błędu, który powinien zostać wkrótce naprawiony
Wiedząc, że TODO
ogólnie pozostanie w bazie kodu przez cały okres jej działania, jak mam na nie zareagować w żądaniu ściągnięcia? Jak mogę uprzejmie poprosić o uniknięcie tego, a jeśli jest to naprawdę uzasadnione, w jaki sposób mogę się upewnić, że autor PR podejmie dalsze kroki w przyszłości?
Odpowiedzi:
Gdy powiesz, że „zazwyczaj pozostają w bazie kodu przez cały okres istnienia bazy kodów” w zespole / dziale / organizacji, weź pod uwagę następujące kwestie:
TODO
,FIXME
czy należy unikać podobnych tagów.TODO [ID-123] Description ...
Jak wspomniano w moim komentarzu , ostatnie stwierdzenie prawdopodobnie ma sens tylko w środowisku, w którym bilety nie gniją (np. Jeśli przestrzegasz zasady zerowego błędu ).
Osobiście uważam, że czasami
TODO
są rozsądne, ale nie należy ich nadmiernie wykorzystywać. Zaczerpnięte z „Clean Code: A Handbook of Agile Software Craftsmanship” Roberta C. Martina (s. 59):źródło
TODO nie są złe. Jestem wielkim fanem nigdy nie sięgania głębiej niż na jedną warstwę i zawsze naprawiam 1 problem na bilet trackera.
Często używam TODO lub FIXME jako sposobu na przypomnienie sobie, że potrzebuję lub chcę wrócić, aby naprawić problem.
Na przykład mogę wywołać add (a, b) i dodać TODO, aby zmienić metodę dodawania. Nie chcę teraz pracować nad metodą dodawania, ale chcę do niej wrócić.
Więc w żądaniu ściągnięcia zobaczysz TODO lub FIXME. Używam FIXME na przykład, aby ostrzec innych twórców kodu o obszarach, za które są odpowiedzialni i że nie powinienem z tym zadzierać. Na przykład dodawanie FIXME nie może przyjmować liczb ujemnych.
Aby obejść problem, że nie są one widoczne lub ignorowane, używam skryptu, który wyświetla wszystkie wiersze TODO FIXME i DEGUG. I to jest dołączane do komunikatu zatwierdzenia.
Trudno zignorować komunikat zatwierdzenia linii 400, który jest wszystkimi TODO. Dlatego ludzie je naprawiają, dotykając już danego kodu lub tworząc nowe zgłoszenia i usuwając samodzielny kod problemu.
Szczerze mówiąc, upewniam się również, że każdy projekt ma wbudowany czas czyszczenia kodu. Tak, może być gotowy do uruchomienia 15, ale robił czyszczenie kodu od 15 do 30. (wydaje się to dziwne, ale jeśli kiedykolwiek zarządzałeś produktem, wiesz, że jeśli spróbujesz mieć zadania o niskiej widoczności przed uruchomieniem, nigdy nie będziesz mógł się do nich dostać. Coś innego zyska priorytet.)
źródło
TODO
same w sobie nie są złe, ale używanie ich tak często uważam za hałas. Myślę również, że wiadomość zatwierdzenia 400 linii łatwo jest ignorowana, ponieważ ludzie często pomijają tak dużo tekstu. Co więcej, wiele nakładek Git / VCS (np. GitHub) obcina dowolny wiersz tematu dłuższy niż pewna liczba znaków.Zdarzy się, że są żądania ściągania, które nie są idealne. W tej chwili wykonuję pracę, którą można wykonać „wystarczająco dobrze” w dostępnym czasie, ale nie idealnie. Dlatego przesyłam żądanie ściągnięcia, umieszczam TODO z komentarzami we właściwych miejscach w kodzie, a jednocześnie dodaję kolejne żądanie zmiany, aby zmienić rzeczy z „wystarczająco dobrego” na „doskonałe”.
To nowe żądanie zmiany może następnie zostać uszeregowane według priorytetów i zostanie obsłużone, gdy będzie to element o najwyższym priorytecie. Jeśli zdecyduje się, że musi być teraz idealny , będzie to następna sprawa.
Teraz twoje pytanie: „Jak mogę uprzejmie poprosić, aby tego uniknąć, lub jeśli jest to naprawdę uzasadnione, w jaki sposób mogę się upewnić, że autor PR podąży za nim w przyszłości?” Z tym, co opisuję, wydaje się to raczej głupie. Jeśli mam wybór między późną wysyłką a wysyłką tego, co jest wystarczająco dobre, to nie twoja decyzja. Jeśli chcesz, możesz zapytać o to swojego menedżera produktu. I „upewnij się, że autor PR podąży za nim”? Jeśli masz zespół, powinieneś upewnić się, że jest on zalogowany w twoich systemach, i mam nadzieję, że twój zespół jest wystarczająco dobrze zorganizowany, aby zarejestrowane rzeczy się nie zgubiły, a ktoś w końcu to naprawi, gdy nie będzie elementów o wyższym priorytecie. Pamiętaj, że to wysiłek zespołu.
źródło
Jeśli twój projekt śledzi oczekujące elementy w kodzie źródłowym z
TODO
komentarzami, musisz na to pozwolić.Fakt, że obecność
TODO
komentarza w żądaniu ściągnięcia jest błędna, powinieneś powiedzieć, że śledzenie oczekujących elementów w kodzie źródłowym jest złym pomysłem. W ten sposób rzeczy giną lub są ignorowane. Teraz, jeśli mówisz o żądaniu ściągnięcia do „działającego widelca”, sytuacja jest inna. „Roboczy widelec” jest właśnie tym - praca w toku. Ale taki rozwidlenie zwykle nie wymaga żądania ściągnięcia. Sugerowane tutaj „reguły domowe” dotyczą wniosków ściągania dla gałęzi master .Zasada domowa nr 1 - wszystkie zatwierdzenia do masterowania powinny być gotowe do testowania, ponieważ master jest budowany codziennie po każdym zameldowaniu. Te zatwierdzenia powinny również obejmować wszelkie dodatkowe wymagane testy.
Jeśli
TODO
komentarz istnieje, ponieważ kod nie został ukończony lub testy nie są zakończone lub kod nie jest w żaden sposób gotowy do testowania, kod ten należy do lokalnego zatwierdzenia, a nie żądania ściągania. Zadzwoń, kiedy będzie gotowy.Zasada domowa nr 2 - Wszystkie informacje dotyczące otwartych problemów są przechowywane w narzędziu do śledzenia problemów. Wszystko. Notatki, bazgroły, przeczucia, cokolwiek.
Jeśli
TODO
komentarz dotyczy otwartego problemu i nie jest faktyczną poprawką dla tego problemu, to ta informacja należy do narzędzia do śledzenia problemów. W ten sposób przed zamknięciem problemu wszystkie informacje można w razie potrzeby przejrzeć i zweryfikować, aby upewnić się, że problem został rzeczywiście rozwiązany.Zasada domowa nr 3 - Wszystkie informacje dotyczące oczekujących zadań projektowych należą do kolejki priorytetowej (lub jakiejkolwiek innej nazwy twojego systemu).
Dla wyjaśnienia, oczekujące zadanie projektowe jest czymś, co należy wykonać w projekcie, który ma ustalony priorytet, niezależnie od tego, czy jest to defekt wykryty przed wygenerowaniem zgłoszenia problemu, czy też realizacja określonego wymagania projektowego lub jednego z niezbędne komponenty tego wymagania.
Jeśli w
TODO
komentarzu jest powiedziane, że nowy kod wpłynie na oczekujące zadanie, lub wskazać coś innego w bazie kodów, które należy sprawdzić, co zostało odkryte podczas implementacji nowego kodu, to informacja ta należy do kolejki priorytetowej, albo istniejące zadanie lub jako nowe.Zasada domowa nr 4 - sugestie należą do skrzynki pomysłów (lub cokolwiek innego).
Jeśli
TODO
komentarz sugeruje zmianę w projekcie lub implementacji oprogramowania, to ta informacja należy do okna pomysłów projektu lub „vNext” lub „Uwagi do projektu”, lub cokolwiek innego, co masz do tego rodzaju rzeczy.Reguła nr 5 -
TODO
komentarze nie są dozwolone w kodzie źródłowym. KROPKA.Jeśli będziesz trzymać się tej zasady, nie będziesz musiał się martwić, że ktokolwiek będzie cię śledził.
źródło