Jak mam pamiętać, co robiłem i dlaczego w projekcie sprzed trzech miesięcy?

72

Pracowałem nad projektem trzy miesiące temu, a potem nagle pojawił się kolejny pilny projekt i zostałem poproszony o zwrócenie mojej uwagi.

Od jutra wracam do starego projektu. Zdaję sobie sprawę, że nie pamiętam, co dokładnie robiłem. Nie wiem od czego zacząć.

Jak mogę udokumentować projekt, aby za każdym razem, gdy patrzę wstecz, nie zabierało mi więcej niż kilka minut, aby zacząć od miejsca, z którego wyjechałem. Czy są najlepsze praktyki?

Aquarius_Girl
źródło
98
komentarze i zatwierdzanie wiadomości, jest powód, dla którego ludzie każą ci je zostawiać
maniak ratchet,
5
Czy to naprawdę nie zależy od tego, jak śledziłeś projekt? Czy powinniśmy założyć, że robisz wszystko z pamięci, a nie z innej dokumentacji?
JeffO
4
@ratchetfreak Już miałem powiedzieć: „Jest to przydatne tylko dla programistów”, dopóki nie zdałem sobie sprawy, że możesz zastosować tę samą zasadę do wszystkiego. Większość repozytoriów dokumentów ma sekcję notatek lub opis; elementy dostarczane za pośrednictwem poczty e-mail mają treści wiadomości (często ignorowane). Dokumenty mogą mieć śledzone zmiany i adnotacje. W świecie PM jest też cały ekosystem komentarzy i komunikatów! </epiphany>
corsiKa
6
Używam systemu kontroli wersji, aby przypomnieć mi, co zrobiłem ostatnim razem, oraz narzędzia do śledzenia błędów, aby dowiedzieć się, co jeszcze należy zrobić.
Lie Ryan
2
O tak, raz po trzymiesięcznej przerwie w pracy poproszono mnie na rozmowie kwalifikacyjnej o opisanie mojego ostatniego projektu. Zrobiłem to, ale kiedy poprosili o szczegóły, nie mogłem ich zapamiętać. Odrzucili mnie, ponieważ najwyraźniej jestem fałszywy, jeśli nie pamiętam tego. Stało się to około 15 lat temu, ale wciąż to pamiętam.
Andrew Savinykh,

Odpowiedzi:

35

Chciałem tylko przekazać kilka rad, które nie będą przydatne w obecnej sytuacji, ale możesz zacząć je wdrażać, aby pomóc w przyszłości.

Oczywiście są oczywisti kandydaci, tacy jak listy rzeczy do zrobienia i dzienniki problemów; przyjrzenie się ostatnio dodanym problemom powinno dać ci wskazówkę co robiłeś, kiedy byłeś wyłączony z projektu.

Przy poprzednich projektach, nad którymi pracowałem, oczekiwano, że ludzie będą prowadzić dziennik projektu w ramach procesu zarządzania jakością. Treść nie była bardzo jasno sprecyzowana, ale pomysł polegał na prowadzeniu codziennego dziennika rzeczy związanych z projektem, które mogą być przydatne do dalszej pracy w przyszłości lub do przeglądu działań po zakończeniu; na przykład:

  • Obserwacje dotyczące jakości projektu

    ten kod może wymagać pewnego refaktoryzacji

    zrobiłem szybką implementację, aby to zadziałało, ale ABC byłoby lepsze.

  • Todo elementy / problemy , których nie chcesz formalnie rejestrować w narzędziu do śledzenia problemów

    ”powinno sprawić, że ta metoda będzie działać, x < 0ale obecnie jest to poza zakresem.

  • Decyzje projektowe - szczególnie nietrywialne.

    Nasza standardowa funkcja sortowania wykonuje szybkie sortowanie, ale to nie zachowuje kolejności elementów równych w warunkach sortowania, których tutaj potrzebujemy.

    Oczywistym algorytmem byłby ABC, ale tutaj zawodzi, ponieważ xmoże być negatywny, więc potrzebujemy formy uogólnionej ( link z Wikipedii ).

  • Napotkane problemy i sposób ich rozwiązania. Bardzo ważny, moim zdaniem: kiedy napotkasz problem, zanotuj go w dzienniku.

    Sprawdziłem kod, ale dał błąd XYZ0123, okazało się, że najpierw musiałem zaktualizować komponent C do wersji 1.2 lub wyższej.

Te dwa ostatnie punkty są bardzo ważne. Często napotykałem podobną sytuację lub problem - czasami w zupełnie innym projekcie - i myślałem „hmm, pamiętam, że spędziłem nad tym dzień, ale jakie było rozwiązanie ponownie?”

Kiedy po pewnym czasie wrócisz do projektu, czytanie dziennika projektu (niezależnie od tego, czy jest to Twój, czy najnowszy programista) powinno przywrócić Cię do przepływu, który miałeś po opuszczeniu projektu, i ostrzec Cię przed niektórymi pułapkami w przeciwnym razie mogą wpaść ponownie.

CompuChip
źródło
68

Listy rzeczy do zrobienia są magiczne. Ogólnie rzecz biorąc, musisz zachować aktywną listę rzeczy do zrobienia dla każdego projektu, a nawet gdy jesteś zajęty programowaniem, jeśli pomyślisz o czymś, co trzeba zrobić i nie możesz tego zrobić natychmiast, to trafia na listę. Przechowuj tę listę w dobrze znanym miejscu, w arkuszu kalkulacyjnym lub pliku tekstowym w folderze projektu elektronicznie lub w dzienniku papierowym.

Ponadto, ilekroć opuszczasz projekt na noc (lub w weekend), weź notatkę z napisem i napisz następną rzecz, którą zamierzasz zrobić na notatce, i przyklej ją do monitora. To zwiększa prawdopodobieństwo, że szybko wrócisz do niego następnego ranka.

Edytuj :

Powinienem wspomnieć, że listy rzeczy do zrobienia (w szczególności listy rzeczy do zrobienia z priorytetem posegregowane według miejsca i projektu) są kluczową częścią książki Getting Things Done , na którą mam duży wpływ.

Scott Whitlock
źródło
22
A jeśli pracujesz nad sprawnym projektem z małymi zadaniami, zaległości powinny być twoją podstawową listą rzeczy do zrobienia dla tego projektu.
Bart van Ingen Schenau
1
Niedawno zacząłem robić to, o czym wspomniałeś w ostatnim akapicie, a to bardzo pomogło mi zacząć rano.
TMH
5
W rzeczy samej. Zawsze parkuj z góry. To kwestia przyzwyczajenia. Nigdy nie zostawiam bazy kodu bez robienia notatek w kodzie lub na mojej liście rzeczy do zrobienia, co dalej. Upewniam się również, że wszystko, co wiem, co muszę zrobić, to todo albo w źródle (używam konwencji TODO: w komentarzach, które moje IDE może wykryć i przedstawić jako listę), lub na mojej osobnej liście todo (I mają tylko jeden dla wszystkich projektów, ale jest podzielony na kategorie i ma priorytet).
Joeri Sebrechts
3
TODO w kodzie są doskonałe, ale musisz uważnie je umieszczać, nawet w przypadku drobnych drobiazgów. Uwzględniając todocel w swoim makefile, który zrzuca je również użyteczne.
Blrfl,
4
trello.com to ratownik . Nawet na te spotkania zespołu Monday Monring, w których staram się pamiętać, co zrobiłem w zeszłym tygodniu i nad czym powinienem pracować w tym tygodniu. Jest również bezpłatny.
SimonGates
33

Co zrobić teraz?

Teraz od jutra wracam do mojego starego projektu i zdaję sobie sprawę, że nie pamiętam, co dokładnie robiłem i od czego zacząć!

Domyślam się, że nie zrobiłeś żadnej z następnej sekcji. Więc wyszukiwanie listy rzeczy do zrobienia nie będzie działać.

  1. Zablokuj okres czasu. Umieść to w swoim kalendarzu i spędzaj czas na recenzowaniu projektu. Może to być przegląd dokumentacji, kodu, wymagań itp.
  2. Zaakceptuj to, że powrót do prędkości zajmie trochę czasu. Upewnij się, że wszyscy zaangażowani zdają sobie z tego sprawę. Upewnij się, że zdajesz sobie z tego sprawę.
  3. Zacznij od małego zadania. Odbuduj trochę pewności siebie, robiąc coś małego. Jeśli masz listę nowych przedmiotów, najpierw przeprowadź mniejsze. To nie tylko odbudowuje twoją pewność siebie, ale także pomaga zapoznać się z projektem.

Jak ulepszyć to dla siebie w przyszłości?

Chcę wiedzieć, jak udokumentować projekt w taki sposób, aby za każdym razem, gdy się oglądam, nie zabierało mi więcej niż kilka minut, aby dotrzeć do miejsca, z którego wyjechałem!

Po pierwsze, musisz mieć system śledzenia twoich todos. Czy masz teraz taki system? Jak zarządzasz obecną pracą projektową?

Mogłem jutro zostać potrącony przez autobus, a mój zespół miałby dobry pomysł na ponad 90% moich akcji. Wynika to z faktu, że mam spójny system dokumentowania moich:

  • Natychmiastowe czynności (przedmioty <1 tydzień)
  • Todos „Miło mieć”
  • Kamienie milowe i makro do wykonania (tam, gdzie specyfika nie ma znaczenia)
  • Wymagania / notatki ze spotkania

Ponadto używam VCS i komentuję mój kod, jeśli to konieczne.

Działa to dla mnie i mojego zespołu, ponieważ jestem głównym programistą. Możesz użyć jakiegoś systemu śledzenia problemów dla zespołu. Lub zaległości podczas pracy z Agile. Istnieje mnóstwo opcji. Jeśli naprawdę Cię to interesuje, przeczytaj artykuł Getting Things Done lub inne odpowiednie metodologie zarządzania zadaniami, które istnieją niemal dokładnie z powodu tego, co opisujesz.

Jaki jest sens?

Specyfika systemu jest mniej istotna niż to, że jest to system spójny i używasz go . I że go używasz. I użyj tego. To jest ważne. Ważniejsze niż ładny, idealny system, którego nie używasz. Nie rób „dobrze, większość mojej pracy jest tutaj, ale niektóre są w mojej głowie”, bo inaczej będziesz nienawidził wracania do projektu.

Upewnij się także, że twoje komentarze wyjaśniają „dlaczego”, a nie tylko „co” dla kodu. O wiele łatwiej jest przeczytać „to naprawić błąd w IE8” i przypomnieć sobie, co robi kod, niż komentarz po prostu wyjaśniający szczegóły techniczne.

kraina krańca
źródło
@ TheIndependentAquarius nie ma problemu, cieszę się, że był pomocny. Ta sytuacja może być przytłaczająca.
enderland
@ TheIndependentAquarius prawdopodobnie dlatego, że generalnie komentarze mają być mniej więcej post-it / stickies. Sposób, w jaki Stack Exchange ma takie rzeczy do powiedzenia: „ta odpowiedź była świetna”, to albo poprawianie opinii, albo przyjmowanie odpowiedzi. Komentarze tutaj niekoniecznie muszą trwać.
enderland
Znacznie bardziej usprawniona wersja tej listy rzeczy do zrobienia polega na wykorzystaniu systemu śledzenia problemów. Dostępnych jest wiele bezpłatnych systemów, a wielu bezpłatnych dostawców Git ma wbudowany taki system w swoje usługi (patrz: GitHub).
BTownTKD
@BTownTKD Mówię to w mojej odpowiedzi :)
enderland
To dobra odpowiedź; dodano dla podkreślenia.
BTownTKD,
14

Moim zdaniem „wznowienie” projektu kodu składa się z dwóch części:

  1. Ustalenie, gdzie przerwałeś
  2. Pamiętając, co pozostało, musisz zrobić

Jest to jedna z tych rzeczy, które moim zdaniem, jeśli wykonujesz kontrolę wersji we właściwy sposób, będzie to twój „drugi mózg”.

Gdzie skończyłeś ? Tak długo, jak często popełniasz kod, spójrz na swój ostatni zestaw zmian. Najprawdopodobniej pobudzi coś do myślenia. Jeśli nie, spójrz na kilka ostatnich, zaczynając od najstarszych i powtarzając zatwierdzenia.

Jeśli chodzi o to, co pozostało do zrobienia , zaległości powinny służyć temu celowi (lub liście rzeczy do zrobienia lub jakkolwiek chcesz ją nazwać. Zasadniczo elementy na przyszłość).

Nie jestem etatowym programistą. Jestem programistą, który hakuje w nocy i weekendy. Z tego powodu, kiedy praca lub inne rzeczy niezwiązane z programowaniem mają wyższy priorytet, czasami mogę spędzać dni i tygodnie, nawet nie podnosząc mojego kodu na pierwszy rzut oka. Powyższe okazało się dość skuteczne.

Thomas Stringer
źródło
10

To nie ma być pełna odpowiedź - jest już kilka bardzo dobrych, które wspominają o ważnych rzeczach, takich jak korzystanie z VCS i oprogramowania do zarządzania projektami - ale raczej uzupełnienie dodające kilka punktów, których nie widziałem w żadnym innym, okaże się bardzo pomocny i mam nadzieję, że inni również mogą być pomocni.

1. Żadne zadanie nie jest za wcześnie ani za małe, aby je spisać

Ludzie zwykle sporządzają listy rzeczy do zrobienia dla rzeczy, które planują robić w przyszłości , ale ponieważ programowanie wymaga koncentracji, a ponieważ możemy przerwać w dowolnym momencie , uznałem, że pomocne jest zapisanie nawet tego, co robię teraz, lub co mam zacząć w ciągu kilku sekund . Możesz czuć, że znajdujesz się w strefie i nie możesz zapomnieć o rozwiązaniu, które właśnie uderzyło cię w tej chwili aha , ale kiedy twój współpracownik wpadnie do twojej kostki, aby pokazać zdjęcie jego zainfekowanego palca u nóg , i jesteś tylko w końcu się go pozbyć, zaczynając gryźć się na własnym ramieniu , możesz żałować, że nie napisałeś szybkiej notatki, nawet jeśli tylko na kartce Post-It ™.

Oczywiście lepszy może być inny, bardziej trwały nośnik (szczególnie lubię OmniFocus ), ale chodzi o to, żeby przynajmniej gdzieś go mieć , nawet jeśli skończysz za 20 minut, a potem wyrzucisz Post-It ™. Chociaż możesz odkryć, że informacje te stają się przydatne, aby wystawiać klientowi arkusze czasu pracy lub faktury, lub gdy szef / klient pyta cię, nad czym pracowałeś i nie pamiętasz. Jeśli upuścisz wszystkie te notatki w pudełku, szufladzie lub folderze, to kiedy nadejdzie duża przerwa - przerywający projekt - możesz je przejrzeć i zapamiętać wiele rzeczy, które zrobiłeś, aby doprowadzić kod do punktu, w którym znajdź go po powrocie do projektu.

2. Użyj tablicy na biurku, aby uchwycić pomysły na duże obrazy

Obok biurka mam tablicę o wymiarach 3 x 4, więc kiedy rozpoczynam projekt, mogę przeprowadzić burzę mózgów na temat rozwiązań wszystkich problemów, które dostrzegam w projekcie. Mogą to być schematy architektoniczne, przypadki użycia, listy zagrożeń i przeszkód lub cokolwiek, co wydaje się istotne dla Ciebie.

Niektóre bardziej sformalizowane podejścia wymagają generowania diagramów i przypadków użycia i tak dalej jako „rezultatów” w formie papierowej lub elektronicznej, ale uważam, że może to spowodować wiele dodatkowej pracy i po prostu stać się serią podprojektów, które kończą się oderwanie się od faktycznego celu głównego projektu i tylko część sformalizowanego procesu, który musisz zrobić, ale na który nikt nie zwraca dużej uwagi. Tablica to najprostsza rzecz, która faktycznie działa, przynajmniej z mojego doświadczenia. Jest tak wytrwały, jak chcesz (z kamerą) i, co najważniejsze, pozwala od razu odrzucić pomysły.

Myślę, że lepiej z piórem w dłoni, więc zrzut myśli na białą powierzchnię przychodzi mi naturalnie, ale jeśli nie uważasz, że tak jest w twoim przypadku, oto kilka pytań, które mogą pomóc ci zdecydować, co jest istotne :

  • Gdybym był głównym programistą, który zamierzał spędzić miesiąc miodowy przez 3 miesiące, podczas gdy inni deweloperzy zakończyli projekt, jaki ogólny kierunek chciałbym im dać? O jakich pomysłach chciałbym się upewnić, że wiedzieli, lub jakie podejścia chciałbym mieć, aby się upewnić? Jakie biblioteki lub inne przydatne rozwiązania chciałbym mieć pewność, że są świadome?
  • Gdyby ten projekt był moim pomysłem na milion dolarów, o którym wiedziałem, że zapewni moją przyszłą niezależność finansową, ale zostałem zaplanowany na krytyczną operację, która obezwładniałaby mnie na 3 miesiące, co chciałbym mieć w przyszłości, aby zapewnić pomyślne zakończenie projekt?

(Kiedy po raz pierwszy spisuję pomysły, martwię się tylko tym, że mają one sens dla mojego obecnego ja. Gdy są już na dole, mogę bardziej krytycznie na nie spojrzeć i wprowadzić zmiany, aby upewnić się, że mają sens dla mojego przyszłego ja lub innych. o komunikowaniu się z innymi podczas ich zapisywania na początku może prowadzić do blokowania pisarzy - umysłu zablokowanego przez konkurujące ze sobą cele. Najpierw zejdź na dół; martw się o jasność później).

Polecam wydać pieniądze, aby kupić przyzwoitą tablicę, co najmniej 3 „x 4”, i powiesić ją w miejscu, w którym normalnie pracujesz. Tablica fizyczna ma wiele zalet w porównaniu z dowolnym systemem wirtualnym.

  • To jest duże. Zajmując dużo miejsca, sprawia, że ​​jego obecność jest odczuwalna, a plany wydają się być częścią twojego obszaru roboczego, pomagając przez cały czas wskazywać właściwy kierunek.
  • Jest tam uporczywie: nie masz uruchomionej określonej aplikacji lub strony internetowej, aby uzyskać do niej dostęp, i nie ryzykujesz zapomnienia, jak się do niej dostać, lub zapomnienia, że ​​tam jest.
  • Jest natychmiast dostępny, gdy masz pomysł, który chcesz przemyśleć.

Tracisz wiele korzyści, jeśli po prostu użyjesz tablicy w pokoju konferencyjnym, a następnie zrobisz migawkę telefonem. Jeśli zarabiasz na programowaniu, jest to warte kosztu porządnej tablicy.

Jeśli masz inny projekt, który przerwie ten, który zapełnił twoją tablicę, być może będziesz musiał skorzystać z migawki w telefonie, ale przynajmniej będziesz miał to za 3 miesiące, kiedy „pilny” projekt zostanie zakończony i będziesz musiał wróć do drugiego. Jeśli chcesz odtworzyć go na swojej tablicy, prawdopodobnie zajmie to tylko 15 minut i może się okazać, że możesz go znacznie ulepszyć, co sprawia, że ​​ta niewielka inwestycja czasu jest bardzo opłacalna.

3. Poinformuj interesariuszy o kosztach przerwania projektu

Metafora samolotu jest dla mnie pomocna: rozpoczęcie i ukończenie projektu jest jak latanie samolotem. Jeśli wyskoczysz w połowie lotu, samolot nie będzie po prostu siedział w powietrzu i czekał, aż wrócisz do niego, i potrzebujesz sposobu na podróż z bieżącego projektu / lotu do następnego. W rzeczywistości, jeśli jesteś w środku lotu z Phoenix do Fargo i powiedziano ci, że musisz przerwać ten lot, aby wziąć inny samolot z Denver do Detroit, musisz wylądować pierwszy samolot w Denver (który na szczęście nie jest daleko od toru lotu - nie zawsze tak jest z rzeczywistymi przerwami) i ktoś musi wymyślić, co zrobić z ładunkiem i pasażerami. Nie będą tylko siedzieć i czekać wiecznie.

W przypadku projektów chodzi o to, że przejście z jednego projektu do drugiego wymaga dużego nakładu czasu i pozostawia wiele do stracenia, z którymi trzeba sobie poradzić.

W projekcie jest oczywiście i nieuchronnie wiele rzeczy, które dzieją się w twojej głowie podczas pracy i nie każda myśl może być przekształcona do postaci seryjnej na piśmie, i nie każda część tych myśli, które zserializowane, pozostanie po deserializacji. Chociaż możemy częściowo uchwycić nasze myśli na piśmie, jest to format bardzo stratny.

Problem (jak widzę) polega na tym, że menedżerowie projektów i inni ludzie biznesu myślą o projektach jako o szeregu kroków, które często można dowolnie zamawiać (chyba że istnieje wyraźna zależność od ich wykresu Gantta) i które można łatwo rozdzielić między ludzi lub opóźnione, aż będzie to najwygodniejsze dla firmy.

Każdy, kto dokonał dowolnej ilości programowania, wie, że projekty oprogramowania nie mogą być traktowane jak klocki Lego, które można przenosić w dowolny sposób. Uważam, że metafora podróży lotniczych daje przynajmniej zainteresowanym stronom coś konkretnego, o czym mogą myśleć, że nie można tego traktować jako szeregu różnych kroków, które należy zmienić według kaprysu. Przynajmniej ułatwia zrozumienie , że takie zakłócenia wiążą się z pewnymi kosztami. Oczywiście nadal jest to ich decyzja, ale chcesz uświadomić im o tym, zanim przerwie jeden projekt, aby dać ci inny. Nie bądź wojowniczy, ale udzielaj pomocnych informacji i pomocnej perspektywy programisty, gotów zrobić wszystko, czego od ciebie potrzebują, ale po prostu oferuj informacje, których mogą nie być świadomi, jeśli im nie powiesz.


W skrócie:

  1. Zapisz wszystko, co masz zamiar zrobić, nawet jeśli nie wydaje ci się, że może być potrzebne. Nawet krótki ołówek bije długą pamięć.
  2. Przeprowadź burzę mózgów na dużym obrazie na fizycznej tablicy, do której masz stały dostęp.
  3. Państwo może uniknąć przerw projektowych jeśli się decydenci świadomy, że istnieje koszt takich przerw, a przynajmniej będziesz mieć wyznaczone oczekiwania tak wiedzą, że projekt potrwa trochę dłużej po wznowieniu go.
ikonoklasta
źródło
1
Interesariusze zakładają, że płacą profesjonalnemu programistowi, który komentuje i dokumentuje kod, aby on (później) lub ktoś inny (w dowolnym momencie) mógł przejąć projekt. Oczywiście ich założenie jest przez większość czasu błędne.
JeffO
I powinieneś komentować i dokumentować! Mam nadzieję, że nie pomyślałeś, że sugeruję inaczej. (Nawiasem mówiąc, zgadzam się z twoim komentarzem.)
iconoclast
2

Możesz sprawdzić historię projektu w oprogramowaniu do kontroli wersji sprzed trzech miesięcy. Przeczytaj swoje komunikaty zatwierdzania i najnowsze różnice, aby dowiedzieć się, nad czym pracujesz.

Kevin
źródło
Dziwię się, że ta odpowiedź nie została oceniona. Dziennik kontroli wersji to doskonały sposób, aby dowiedzieć się, gdzie ktoś był kilka miesięcy temu, gdy projekt został tymczasowo zawieszony. Wyczyść logi bardzo pomaga. Różnice i listy zmienionych plików to dodatkowy sposób na uzyskanie obrazu tego, co działo się w projekcie przed zawieszeniem. Wreszcie, jest więcej programistów, którzy używają kontroli wersji w porównaniu do liczby programistów, którzy używają systemu śledzenia błędów (lub nawet prostej listy rzeczy do zrobienia), co sprawia, że ​​ta odpowiedź jest cenna dla większej liczby osób w porównaniu z wysoko ocenioną odpowiedzią Scott Whitlock.
Arseni Mourzenko
2

Korzystanie z systemu kontroli źródła z odpowiednimi strategiami rozgałęziania i łączenia w połączeniu z systemami śledzenia problemów (takimi jak Redmine lub GitHub ) pomaga w podziale dokonanych zmian, nadaje im kierunek i dokumentuje brakujący „kontekst” jako naturalna część przepływu pracy.

  1. Przed rozpoczęciem zmiany kodu upewnij się, że w systemie śledzenia problemów jest zarejestrowany „problem”. Obejmuje to brakujący fragment „twojej pracy”.
  2. Utwórz gałąź w systemie kontroli źródła i upewnij się, że zmiany w tej gałęzi dotyczą TYLKO wspomnianego wyżej problemu. Pomoże ci to wyodrębnić zmiany i da ci historię zmian, odpowiadając na pytanie „gdzie przestałem?” kiedy wrócisz do pracy później.
  3. Po zakończeniu zmiany połącz ją z powrotem do bagażnika i zamknij problem.
BTownTKD
źródło
1

Jest wiele długich odpowiedzi. Oto krótkie pytanie o tym, co najbardziej mi pomaga:

  • Wyczyść kod.
  • Wyczyść kod.
  • Wyczyść kod.
  • Kontrola wersji (różnice i komentarze do zatwierdzenia).
  • Notatka Post-It, Lista Todo lub Tablica Kanban (patrz np. Trello i Evernote)

Jednak różnice, komentarze, komentarze post-it, listy rzeczy do zrobienia lub tablica Kanban mogą z czasem być interpretowane z powodu braku kontekstu. Oto jedna najważniejsza rzecz:

CZYSTE KOD.

fresnel
źródło
W jaki dokładnie sposób czysty kod czysty kod pomaga wyczyścić kodJak powinienem pamiętać, co robiłem i dlaczego w projekcie sprzed trzech miesięcy? ” I odzyskać pominięty kontekst? Czy czysta architektura czysta architektura czysta architektura nie pomogłaby o wiele więcej? Zwykle najpierw nie zagłębia się w szczegóły. Chodzi o uzyskanie pełnego obrazu przed zbadaniem szczegółów. Wszechobecny wujek niestety ci w tym nie pomoże. Niemniej jednak absolutnie zgadzam się z pozostałymi dwoma punktami.
JensG,
@JensG: Kod to architektura. W dobrze napisanym programie widzę funkcjonalną górę architektury programu main, która dla programu o dużych rozmiarach będzie raczej abstrakcyjna. Następnie mogę zanurkować głębiej i zobaczyć na przykład architekturę tego, jak program sam się oczyszcza. Ponadto czysty kod oznacza, że ​​funkcje / zmienne / itp. mają nazwy, które mają sens i zawierają oświadczenie o ich znaczeniu. Jeśli zamiast tego piszę kod Spaghetti / tylko do zapisu, często budzę się następnego ranka / miesiąca / roku, patrzę na mój kod, a jedyną myślą będzie wtf-did-i-do-tam. Tak samo jest, gdy ...
Fresnel
... czyta lub pisze książkę: Czy to bełkot ze wskaźnikiem czytelności Flescha-Kincaida wynoszącym 10, z dużymi frazami, wieloma skomplikowanymi konstrukcjami słów, pozwalając czytelnikowi skupić się na składni zamiast semantyki, czy też jest łatwy do odczytania z indeksem około 80, a więc nie przeszkadza samej historii.
fresnel
Chociaż widzę (i nie wątpię w żaden sposób) wartość czystego kodu, zdecydowanie nie zgadzam się z tym, że kod jest architekturą. Kod może być idealnie czysty i czytelny według wszystkich standardów, ale nadal napisany w taki sposób, aby nie uzyskać dużego obrazu. Następnie pytanie brzmiało: „ jak mam pamiętać, co robiłem ” i „ nie wiem od czego zacząć ”. Nie widzę żadnego przecięcia między bieżącym stanem (czystego) kodu a tym, czego szuka OP: dokładny punkt w procesie, który prowadzi od pomysłu do produktu.
JensG
@JensG: Rozumiem twój punkt widzenia. Myślę, że po prostu interpretujemy „zdaję sobie sprawę, że nie pamiętam, co dokładnie robiłem” inaczej. Dla mnie brzmiało to bardziej jak „Zdaję sobie sprawę, że nie pamiętam, które algorytmy i struktury danych kodowałem i jak mogę je rozszerzyć”, dla ciebie było to (jak sądzę) bardziej jak „Zdaję sobie sprawę, że nie pamiętam, co właśnie starałem się wdrożyć i jego cel ”. Niejednoznaczny ludzki język. ...
fresnel,
1

Jak mogę udokumentować projekt, aby za każdym razem, gdy patrzę wstecz, nie zabierało mi więcej niż kilka minut, aby zacząć od miejsca, z którego wyjechałem.

Po pierwsze, oznacza to, że w projekcie istnieje opis wysokiego poziomu i struktura kodu, które można łatwo zrozumieć w ciągu kilku minut - w przeciwieństwie do zillionowych linii kodu bez widocznej struktury i bez komentarzy.

Czy są najlepsze praktyki?

Oto najlepsze praktyki, które zastosowałem w ciągu ponad 20 lat kariery w projektach od bardzo małych do bardzo dużych i dobrze służyły mi i moim zespołom. Zastosuj w kolejności podanej w miarę rozwoju projektu:

  1. Użyj kontroli wersji, co daje bezpłatny zapis tego, co się stało, kiedy i kto zastosował zmiany. Pozwala także w dowolnej chwili wrócić do wcześniejszej wersji.

  2. Zmodularyzuj swój kod (w zależności od języka i środowiska programistycznego, użyj klas, modułów, pakietów, komponentów).

  3. Udokumentuj swój kod. Obejmuje to dokumentację podsumowującą na górze każdego pliku (co to robi? Dlaczego? Jak go używać?) Oraz szczegółowe komentarze na poziomie funkcji, procedur, klas i metod (co to robi? Argumenty i zwracane wartości / rodzaje? skutki uboczne?).

  4. Dodawaj TODOi FIXMEkomentuj podczas kodowania. Pomaga to zapamiętać, dlaczego i dziwactwa, które nieuchronnie wejdą do twojej bazy kodu, i że później poprosisz WTF ?! . Na przykład:

    //TODO shall actually compute X and return it
    ... some code that does not compute X yet (maybe returns a fixed value instead)
    
    //FIXME make this constant time instead of n^2 as it is now 
    ... some code that works but is not efficient yet
    
  5. Przyzwyczaj do rysowania diagramów w celu dokumentowania struktury i złożonych zachowań, takich jak sekwencje wywołań między modułami / obiektami / systemami itp. Osobiście wolę UMLet, ponieważ jest szybki w użyciu, tworzy ładną grafikę i, co najważniejsze, nie przeszkadza . Ale oczywiście powinieneś użyć dowolnego znalezionego narzędzia do rysowania. Pamiętaj, że celem takich rysunków jest krótka komunikacja, a nie precyzyjne określenie systemu (!!).

  6. Dodaj testy jednostkowe wcześnie. Testy jednostkowe świetnie nadają się nie tylko do testowania regresji, ale są także formą dokumentacji użytkowania modułów.

  7. Dodaj dokumentację zewnętrzną kodu wcześnie. Zacznij od README, który opisuje wymagane zależności do uruchomienia i rozwoju projektu, jak go zainstalować, jak go uruchomić.

  8. Nawyk automatyzacji powtarzalnych zadań . Np. Cykle kompilacji / kompilacji / testowania powinny być skrypty w jakiejś formie (np. W JavaScript grunt, Python fabric, Java Maven). Pomoże to szybko przyspieszyć po powrocie.

  9. W miarę rozwoju projektu dodaj więcej dokumentacji, generując dokumenty kodu źródłowego (używając jakiejś formy komentarzy w stylu JavaDoc i odpowiedniego narzędzia do generowania z niego HTML lub PDF).

  10. Jeśli Twój projekt wykracza poza pojedynczy komponent i zawiera bardziej złożone wdrożenie, pamiętaj o dodaniu dokumentacji projektowej i architektury . Ponownie zauważ, że celem tego jest przekazanie struktury i zależności, a nie drobiazgowych szczegółów.

miraculixx
źródło
0

Oprócz sugestii dotyczących śledzenia projektu, list rzeczy do zrobienia, Trello itp. Coś, co przeczytałem raz, co pomaga, jeśli ćwiczysz TDD, polega na tym, aby zawsze odejść od projektu z nowym testem negatywnym, który można wdrożyć za każdym razem, gdy powrócisz do projektu (jutro , w przyszłym tygodniu lub w przyszłym miesiącu)

Usiądź, wykonaj „Uruchom testy” i wybierz miejsce, w którym zostało przerwane.

Pete
źródło
1
Ma to dwie wady. Po pierwsze, jeśli korzystasz z ciągłej integracji, świadome przeprowadzenie testu, który się nie powiedzie, nie wchodzi w rachubę. Po drugie, jeśli jesteś w zespole więcej niż jednego, inne osoby mogą nie docenić, jeśli wykonasz test zakończony niepowodzeniem.
Arseni Mourzenko
1
@MainMa Nie powiedziałem commit. Tylko lokalnie.
Pete
Moją sugestią dla dowolnego programisty jest zobowiązanie się, gdy nie będzie on pracował nad projektem nawet przez kilka dni. Rzeczy się zdarzają. Twój komputer może zostać skradziony lub możesz nie być w stanie uruchomić go jutro, ponieważ kontroler RAID zawiódł. Możesz opuścić projekt, a drugi programista może zająć twoje miejsce. Możesz zostać potrącony przez autobus. Możesz usunąć projekt lokalnie, ponieważ zajmuje on zbyt dużo miejsca lub ponieważ wirus zabił twój system operacyjny. Więc nie, poleganie na nieprzypisanym kodzie nie jest opcją.
Arseni Mourzenko
1
@MainMa następnie zatwierdza i wypycha do oddziału o nazwie next-steps. Nie jestem pewien, co obawy dotyczące specyfiki podejścia do kontroli wersji mają wspólnego z podstawową zasadą niepowodzenia testu jako pomocy w uruchomieniu mózgu po powrocie do czegoś. Ponownie zaproponowano to oprócz standardowych metod, takich jak zaległości, listy rzeczy do zrobienia itp.
Pete
2
@MainMa: kontrola wersji może mieć wiele wspólnego z kopiami zapasowymi, ale to nie jest jej główny cel. Jeśli potrzebujesz systemu zapasowego, a sposób, w jaki używasz kontroli wersji, uniemożliwia mu spełnienie tego celu, zdobądź Time Capsule lub coś podobnego. Nigdy nie powinieneś być zmuszany do przedwczesnego popełniania tylko po to, aby zmusić swój system VCS do wykonania kopii zapasowej. I nigdy nie powinieneś powstrzymywać się od robienia czegoś innego, co byłoby korzystne, ponieważ postępujesz zgodnie z polityką „natychmiast wszystko zatwierdzaj”.
iconoclast
0

Oprócz komentarzy / list rzeczy do zrobienia / zobowiązań ważne jest, aby być realistycznym.

W zależności od wielkości, złożoności i stanu, w którym opuściłeś pracę, ponowne rozpoczęcie pracy nad projektem może trochę potrwać. W przypadku znacznej bazy kodu złożonej z wielu współdziałających elementów uzyskanie pełnej prędkości może zająć kilka dni.

Przydaje się stara dobra cierpliwość.

Kiedy po pewnym czasie wracam do projektu przytłoczony, zazwyczaj wybieram najprostszą i najmniejszą jednostkę zadania i realizuję ją. Nie pozwala mi się zgubić, próbując zapamiętać wiele rzeczy naraz, i nieco podbija pewność siebie. Często zdarza mi się, że w ciągu kilku godzin automatycznie podejmuję coraz większe zadania.

Amol
źródło
0

Prowadzę dziennik mojej pracy. Co zrobiłem dzisiaj, co było dzisiaj trudne, jaki jest następny krok, jakie pomysły miałem dzisiaj na przyszłość. Dodaję też trochę narracji o tym, jak wyglądał ten dzień: czy była interesująca rozmowa lub spotkanie? Czy coś złościło lub zachwyciło? Pomaga to spojrzeć na to z innej perspektywy, kiedy później czytam swój dziennik.

Kiedy po pewnym czasie wracam do projektu, czytam kilka ostatnich pozycji w dzienniku, aby przyspieszyć projekt. Wszystkie te codzienne szczegóły są niezwykle ważne dla zapamiętania procesu rozwoju. Robią naprawdę dużą różnicę w porównaniu do listy rzeczy do zrobienia lub zwykłej dokumentacji projektu, ponieważ przypominają o tym, jak to było pracować nad projektem, a nie tylko jak korzystać z produktu.

bastibe
źródło
wydaje się, że nie oferuje to nic istotnego w porównaniu z punktami podanymi i wyjaśnionymi we wcześniejszych 11 odpowiedziach
gnat
0

Dla mnie uważam, że najprostszym sposobem wznowienia projektów jest po prostu ciągłe zapisywanie notatek na temat twojej pracy. Uważam, że „OneNote” Microsoftu jest szczególnie dobry do przechowywania i grupowania stron notatek. W szczególności pasek wyszukiwania sprawia, że ​​niezwykle łatwo jest szybko znaleźć swoje notatki.

Oto kilka rzeczy, które robię w OneNote, które pomagają mi wznowić postępy w projektach:

  • Dzienniki dzienne / tygodniowe - prowadź dzienny lub tygodniowy dziennik postępów, aby pomóc Ci zorientować się w postępach, które już osiągnąłeś w projekcie.

  • Lista rzeczy do zrobienia - mam ogólną listę rzeczy do zrobienia, ale prowadzę również osobną listę rzeczy do zrobienia dla projektów, nad którymi pracuję, aby zapamiętać, co jeszcze muszę zrobić dla projektu. Czasami zostawiam również // TODO: elementy w moim kodzie.

  • Uwagi do projektu - rzeczy, na które zwracam uwagę, obejmują łącza do elementów śledzenia / śledzenia projektu, fragmenty kodu, napotkane problemy, podjęte decyzje, plany i opisy potencjalnych rozwiązań, listę zmian kodu, linki do katalogu repozytorium kodów, wiadomości e-mail do projektu i linki do dokumentacja projektu.

Tak więc, za każdym razem, gdy wracam do projektu, mogę otworzyć notatki i prawie natychmiast mogę zobaczyć, jak duży postęp został osiągnięty w projekcie, ile pracy pozostało do zrobienia, a nawet zobaczyć mój tok myślenia.

Ciaran Gallagher
źródło
-2

W przypadku prostych projektów robię to:

  1. Prosty plik README w katalogu głównym (który dlatego też skończy się kontrolą wersji), w którym zauważam, co pojawia się podczas tworzenia: rzeczy do zrobienia, błędy, ulepszenia / pomysły. To pierwszy plik, który przeczytam, gdybym musiał umieścić projekt na tylnym palniku.
  2. Komentarze TODO / FIXME / XXX
  3. Często używam również ToDoList
axd
źródło