Wybieram niepisaną opcję (4): Podziel swój projekt na wysoce wyspecjalizowane zestawy / biblioteki, aby niepowiązane błędy zawsze znajdowały się w innym miejscu w drzewie kontroli wersji.
Przepraszam jeśli powyższe dźwięki snarky, ale mam na myśli to szczerze. Kulę się, gdy widzę monolityczny projekt ze sto formami i przestrzeniami nazw, które nie mają ze sobą nic wspólnego. Często mierzyłem się z tym samym dylematem, zastanawiając się, czy i jak powinienem rozbijać commity dotyczące różnych obszarów funkcjonalnych; Dopiero znacznie później zdałem sobie sprawę, że posiadanie tych wszystkich różnych obszarów funkcjonalnych w ramach jednego projektu, który można zlecić, samo w sobie było poważną wadą projektową.
Nadal często znaleźć zupełnie niepowiązanych błędów, a ja pracuję w funkcji konkretnego. Być może pracuję nad interfejsem użytkownika i znajduję błąd w logice biznesowej i muszę go naprawić, zanim będę mógł przejść dalej. Różnica polega na tym, że logika biznesowa zawsze znajduje się w innym zestawie / projekcie niż interfejs użytkownika, więc wszystko, co muszę zrobić, to dokonać jednej bardzo drobnej zmiany w BL i kontynuować jedną bardzo niewielką zmianę, a następnie kontynuować pracę.
Mając bardzo dobrą organizację projektu sprawia, że nie tylko możliwe, ale dość łatwe do rozwiązania tych problemów bez grzebania zmianę, łamiąc build, lub uzyskiwanie pogrążone w irytujący oddział / scalania (nawet jeśli używasz dvcs to nie jest całkowicie bezbolesny ).
Jeśli brakuje ci tej opcji - tzn. Jesteś młodszym deweloperem, który nie ma nic do powiedzenia w organizacji projektu - po prostu wybrałbym numer 1 i zrobiłbym odpowiednie notatki w dzienniku, aby inni wiedzieli, dlaczego zrobiłeś to, co zrobiłeś. Jeśli popełnił poważne zmiany, a następnie również złożyć raport o błędzie w systemie śledzenia emisyjnej dać wgląd w to, co już ustalone i dlaczego.