Co powinienem zrobić, gdy już zbyt długo czekałem między zatwierdzeniami?

Byłem niegrzeczny ... Za dużo „kodowania kowbojów”, za mało popełniania. Teraz jestem z ogromnym zobowiązaniem. Tak, powinienem był cały czas się angażować, ale teraz jest już za późno.

Co jest lepsze?

1. Zrób jeden bardzo duży zatwierdzenie, wymieniając wszystkie rzeczy, które zmieniłem
2. Spróbuj podzielić go na mniejsze zatwierdzenia, które prawdopodobnie się nie skompilują, ponieważ pliki zawierają wiele poprawek, zmian, dodatkowych nazw metod itp.
3. Spróbuj wykonać częściowe odwracanie plików tylko dla odpowiednich zatwierdzeń, a następnie odłóż nowe zmiany z powrotem.

Uwaga: w tej chwili jestem jedynym programistą pracującym nad tym projektem; jedyną osobą, która spojrzy na te komentarze, są ja, przynajmniej dopóki nie zatrudnimy większej liczby programistów.

Przy okazji: używam SVN i Subclipse. Utworzyłem nowy oddział przed wprowadzeniem tych zmian.

Więcej informacji : zadałem osobne pytanie dotyczące tego, jak dostałem się do tej sytuacji: jak przygotować się do przepisania kleju aplikacji

Aby odpowiedzieć, musisz zadać sobie pytanie, w jaki sposób zamierzasz wykorzystać wyniki tych zmian w przyszłości. Najczęstsze przyczyny to:

• Aby zobaczyć, w jakiej wersji wprowadzono błąd.
• Aby zobaczyć, dlaczego obecny jest określony wiersz kodu.
• Aby połączyć się w inną gałąź.
• Aby móc sprawdzić poprzednią wersję w celu rozwiązania problemu, który klient lub tester widzi w tej wersji.
• Aby móc uwzględnić lub wykluczyć niektóre części z wydania.

Dwa pierwsze powody mogą być obsługiwane równie dobrze za pomocą jednego dużego zameldowania, przy założeniu, że możesz utworzyć komunikat odprawy, który będzie równie dobrze pasował do każdej linii zmienionego kodu. Jeśli jesteś jedynym programistą, mniejsze zatwierdzenia nie ułatwią ci scalenia. Jeśli nie planujesz robić wydania lub testowania tylko z częścią nieprzesłanych zmian, dwa ostatnie powody nie mają zastosowania.

Są inne powody dokonywania małych zatwierdzeń, ale dzieje się tak, gdy jesteś w trakcie zmian, a ten czas już minął. Powody te ułatwiają wycofanie się z pomyłki lub eksperymentalnej zmiany oraz ułatwiają synchronizację z kolegami bez ogromnych przerażających połączeń.

Z mojego rozumienia twojej sytuacji, którą opisałeś, wydaje się, że podzielenie twojego zatwierdzenia w tym momencie nie ma żadnej korzyści.

Myślę, że cokolwiek zrobisz, staraj się unikać wpisywania kodu, o którym wiesz, że się nie skompiluje.

Jeśli uważasz, że twoja trzecia opcja jest wykonalna, może to być dobry sposób na zrobienie tego, o ile możesz upewnić się, że sekwencja zatwierdzeń nie stworzy niemożliwego do kompilacji systemu. W przeciwnym razie po prostu wykonaj jedną dużą zmianę. To brzydkie, ale proste, szybkie i gotowe. Idąc dalej, dokonuj częściej .

Najważniejszym powodem dokonywania częstych, małych i znaczących zmian jest pomoc w zrozumieniu historii kodu. W szczególności bardzo trudno jest zrozumieć, jak zmienił się kod, jeśli trudno jest wygenerować zrozumiałe różnice.

Opcja 1 zaciemnia historię wprowadzonych zmian, ale w przeciwnym razie nie spowoduje żadnych problemów.

Opcja 2 zaciemnia historię dokonanych zmian, być może nieco mniej niż opcja 1, ale może powodować inne problemy dla ciebie lub innych, jeśli założą oni lub w inny sposób stwierdzą, że zatwierdzenia są różne, np. Mogą zostać niezależnie połączone z innymi gałęziami. O ile nie istnieje silny praktyczny powód, dla którego jest to preferowane w porównaniu z opcją 1, jest to mniej idealne niż to.

Opcja 3 jest najlepsza, wszystkie pozostałe są równe, ale jeśli, jak opisano w innym miejscu, zrobienie tego wymagałoby „ekstremalnych” ilości czasu lub pociągnęłoby za sobą inne znaczące koszty, będziesz musiał porównać te koszty z oczekiwanymi korzyściami tworzenie czystszych zatwierdzeń.

W oparciu o informacje, które podałeś, wybrałbym opcję 1. Może powinieneś skonfigurować przypomnienia z prośbą o zatwierdzenie zmian?

Prototypowanie i przepisywanie

Kolejną kwestią, o której należy pamiętać, szczególnie w świetle notatki o byciu jedynym programistą oraz mojego podejrzenia, że ​​pracujesz nad stosunkowo nową bazą kodu, jest to, że prawdopodobnie dobrze jest rozwinąć różne nawyki dotyczące dokonywania zmian w przypadku „prototypowanie nowego kodu w porównaniu z utrzymywaniem lub rozszerzaniem istniejącego kodu. Prawdopodobnie nie ma strasznie ostrego podziału między nimi, ale myślę, że nadal jest to użyteczne rozróżnienie.

Kiedy prototypujesz nowy kod, zatwierdzaj, kiedy chcesz zapisać zmiany, prawie na pewno w oddziale, ale być może w osobnym projekcie. A może nawet całkowicie działają poza kontrolą wersji. Zamiast tego możesz skupić się na gromadzeniu dowodów na temat wykonalności różnych hipotez lub projektów, które rozważasz. Często piszę małe prototypy przy użyciu różnych narzędzi, np. LINQPad zamiast Visual Studio for C #.

Po zweryfikowaniu konkretnej hipotezy lub projektu, przepisz ją w głównym projekcie, najlepiej w oddziale, i wykonaj małe, znaczące zatwierdzenia, które najlepiej pomogą zrozumieć inne (w tym ciebie w przyszłości), co do charakteru zmian robisz.

Chociaż jedyną rozsądną odpowiedzią jest to, aby nigdy nie łamać bagażnika , czasami nie jest to możliwe. Na przykład, svn może przerwać zatwierdzanie, jeśli popełnisz zbyt dużo (być może opcja lub funkcja, nie jestem pewien). W takich szczególnych przypadkach wystarczy zameldować się w częściach. Ponieważ jesteś jednym programistą, nikomu to nie będzie przeszkadzać.

Dlatego wybrałbym opcję 1. Jeśli nie jest to możliwe, wybierz opcję 2.

Opcja 3 wymaga dużego wysiłku i po prostu nie jest tego warta.

Spróbuj podzielić go na mniejsze zatwierdzenia, które prawdopodobnie się nie skompilują, ponieważ pliki zawierają wiele poprawek, zmian, dodatkowych nazw metod itp.

Kiedy znalazłem się w podobnej sytuacji, zastosowałem następującą technikę:

1. Dodaj tylko kod odpowiedni dla konkretnej funkcji: git add --patch
2. Ukryj wszystkie inne zmiany: git stash save --keep-index
3. Uruchom testy / spróbuj skompilować
4. Zatwierdź zmiany, jeśli wszystko jest w porządku, jeśli nie, przejdź do 1

Nie znam SVN, więc nie wiem, czy dotyczy to konkretnej sytuacji, ale podstawa powinna być taka sama - izoluj małe części kodu i testuj je indywidualnie.

Co powiesz na opcję 4: Wykonaj kopię zapasową bieżącego stanu repozytorium w tymczasowym miejscu, przywróć repozytorium do jego pierwotnego stanu, zrób listę wszystkich dokonanych zmian (nadal możesz spojrzeć na tymczasową kopię zapasową), a następnie ręcznie wykonaj ponowną implementację (i skompiluj i przetestujcie!) jako osobne zatwierdzenia.

Powinno to być łatwiejsze, ponieważ kod został już napisany, wystarczy dowiedzieć się, które części skopiować i wkleić z tymczasowej kopii zapasowej.

Po ponownym zaimplementowaniu każdej zmiany w sposób czysty, a tym samym upewnieniu się, że zatwierdzenia są niezależne, małe i kompilowane, możesz usunąć tymczasową kopię zapasową, a wszystko będzie prawie dokładnie tak, jak (oprócz czasu / daty zatwierdzeń) byłoby, gdybyś zrobił to od samego początku.

Jesteś jedynym programistą; po prostu wykonaj jedną masową odprawę, szczegółowo opisując ważne fragmenty tego, co zrobiłeś.

Czy prawdopodobnie wycofasz „części” tego, co zrobiłeś? Jeśli nie, koniecznie przejdź do opcji 1.

Istnieje kilka powodów, aby sprawdzić kod w systemie kontroli wersji. I WSZYSTKIE z nich, gdy jesteś jedynym programistą, obracają się wokół bezpieczeństwa - mianowicie, jeśli spieprzysz, maszyna umrze lub cokolwiek innego, zawsze możesz wrócić do tego ostatniego punktu kontrolnego.

Programiści wchodzący później do projektu raczej nie chcą przywracać wersji, która się nie kompiluje. Tak więc, IMHO, opcja 2 to szaleństwo.

Opcja 3 brzmi jak taki czas, że gdybym był twoim szefem i zobaczył, że marnujesz godziny na robienie tego, porozmawiam z tobą o tym, ile twój czas jest wart.

Aby iterować: sprawdzając kod, zakrywasz / zapisujesz tyłek w przypadku awarii na twoim komputerze. Wszystko inne, w jednoosobowym zespole, to ozdoby do okien.

Moja zasada brzmi: brak odprawy bez poważnego przeglądu kodu. Jeśli jestem sam, będę musiał przejrzeć kod, ale zostanie sprawdzony. Wygląda na to, że wprowadzono wiele zmian w kodzie, których nie mógł sprawdzić ktoś inny, dlatego nie można go przejrzeć samodzielnie (sprawdzenie własnego kodu jest trudniejsze i wymaga większej dyscypliny, ponieważ automatycznie przyjmuje się błędne założenie, że własny kod jest poprawny ).

Całkowicie nie do złamania jest zasada, że: Nigdy nie melduj kodu, który nawet się nie buduje, i poważnie unikaj meldowania się kodu, który nie działa.

Rozwiązanie: Skopiuj zmieniony kod i wróć do pierwotnego punktu. Scalaj jedną zmianę na raz z oryginalnym kodem, przeglądaj go, testuj, sprawdzaj. Za pomocą opisanej metody programowania na pewno znajdziesz w ten sposób poważne błędy.

To także dobry sposób na ćwiczenie dobrych nawyków programistycznych.

Myślę, że zbytnio się martwisz. Jeśli jesteś jedynym programistą i nie masz arkusza specyfikacji, na którym możesz pracować, to od Ciebie zależy, co zrobisz. Zakładam, że nikt nie będzie cię karać za dokonanie dużego zatwierdzenia, więc jedyne problemy, na które się natkniesz, są technologiczne, takie jak niemożność wycofania indywidualnych zmian plików w zatwierdzeniu. Ponieważ w tej chwili masz wyłączną kontrolę nad repozytorium, nie powinno to stanowić większego problemu.

Należy oddzielić pragmatyzm od dogmatyzmu. To, co zrobiłeś, nie byłoby dobrym pomysłem w zespole i prawdopodobnie nie powinno być powtarzane w przyszłości, ale w twojej sytuacji po prostu poddałbym się dużemu zatwierdzeniu.

Problemem nie są duże opóźnienia między zatwierdzeniami, ale fakt, że kod utrzymuje się zbyt długo w stanie niemożliwym do kompilacji. Po pierwsze, jaka jest twoja definicja „długiego”? Dla niektórych osób 5 minut na przejście w stan przejściowy to za dużo, ale niektórzy mogą wypolerować swój kod na kilka dni, nawet nie próbując uruchomić kompilatora.

W rzeczywistości nie ma to znaczenia - ważne jest to, że straciłeś kontrolę nad kodem, kod stał się niemożliwy do zarządzania. Jest to normalne, oznacza to po prostu, że masz dług technologiczny i czas pomyśleć o refaktoryzacji. Jesteś sfrustrowany? Twój kod się nie kompiluje, nawet nie masz testów jednostkowych? Jak możesz myśleć o refaktoryzacji w tym przypadku? Bez obaw. Zakończ „kodowanie kowboja” i zacznij go czyścić. Najlepiej spróbuj napisać kilka testów. Nie masz na to czasu? Ok, zacznij od drobnych ulepszeń.

Niektóre zmiany nie wymagają testów. Zmień nazwę zmiennej, aby była bardziej odpowiednia, przenieś powtarzalny kod do oddzielnej funkcji itp. Dostaniesz lepszy obraz swojego kodu. Następnie możesz wprowadzać większe zmiany. Ponownie spróbuj napisać testy, jeśli to możliwe. Uczyń swój kod zarządzalnym.

Następnie zobaczysz, że następna zmiana nie zajmie ci „zbyt długo” (cokolwiek to znaczy).