Przeskakując do pracy nad różnymi funkcjami, gdy utkniesz, czy jest to przyczyną niepowodzeń projektu?

W przypadku osobistych projektów (lub pracy), jeśli ktoś utknie na problemie lub czeka na rozwiązanie problemu, jeśli przejdziesz do innej sekcji kodu, nie sądzisz, że będzie to dobry powód, dla którego twoja aplikacja będzie wadliwy lub gorzej, ale nigdy nie zostanie ukończony?

Zakładając, że nie używasz git i kodu każdej funkcji do określonej gałęzi, sprawy mogą wymknąć się spod kontroli, ponieważ masz 3 różne funkcje, nad którymi pracujesz, i masz nierozwiązane problemy w każdej z nich.

Kiedy skończysz pracę, stresujesz się, ponieważ masz problemy z zawieszaniem się i na wpół upieczony kod.

Jaki jest najlepszy sposób na uniknięcie tego problemu? (Jeśli to masz)

Zgaduję, że użycie czegoś takiego jak git i utworzenie gałęzi według funkcji jest najbezpieczniejszym sposobem uniknięcia tego złego nawyku.

Jakieś inne sugestie?

To nie jest problem. Tymczasowe odejście od kłopotliwego problemu jest jednym z najlepszych sposobów na przełom w takim problemie (albo później, kiedy o tym myślisz, albo następnym razem, gdy usiądziesz ze świeżym spojrzeniem / umysłem).

Zawsze upewnij się, że właściwie używasz rozgałęzień kontroli źródła i nie będziesz musiał martwić się o połowę rozwiązań w kodzie. Niektórzy ludzie nigdy nie popełniają przerw, ale to tylko osobisty wybór. Jednak nigdy nie powinieneś naciskać na przerwy, aby dzielić się z innymi.

Jak wspomniano smp7d , przeskakiwanie może dać ci dobrą przerwę umysłową od problemu. Należy jednak pamiętać, że kod, nad którym pracowałeś, jest nadal niekompletny. Upewnij się, że wiesz, gdzie przerwałeś.

Jak wspomniano w smp7d, kontrola źródła i rozgałęzianie to świetny sposób na rozdzielenie nowego kodu funkcji i zobaczenie, jak różni się on od głównej bazy kodu.

Jedną z moich sugestii jest to, że jeśli pracujesz nad określoną metodą, upewnij się, że wokół tej metody jest dobrze nazwany test jednostkowy . W ten sposób, pracując nad tym kodem następnego dnia / tygodnia / miesiąca / roku, powinieneś być w stanie jasno powiedzieć, co ma zrobić metoda , nawet jeśli obecnie nie przejdzie testu.

To jest problem? Nie, gdy pojawi się 10% funkcji, które próbujesz wdrożyć. Czasami umysł staje się wyraźniejszy, gdy najpierw robisz coś innego.

Oczywiście jest to problem, gdy utkniesz w 90% funkcji, które próbujesz wdrożyć - wtedy albo potrzebujesz pomocy od innych, albo lekkiego kopniaka od szefa, aby dokończyć to, co zacząłeś (oczywiście to drugie bądź przeciwwskazany, jeśli utknąłeś z powodu prawdziwych problemów technicznych).

Najlepszą opcją w tym przypadku jest często próba podzielenia funkcji, nad którą pracujesz, na mniejsze podfunkcje lub „segmenty funkcji”, które mogą być implementowane, testowane i debugowane jeden po drugim. Dla mnie pomaga napisać fragmenty funkcji, otwarte problemy, części do zrobienia na liście, nadać im priorytety (wystarczy A, B, C) i najpierw pracować nad rzeczami o najwyższym priorytecie.

Z mojego doświadczenia wynika, że ​​„skakanie dookoła”, a ściślej „skakanie losowo dookoła”, jest objawem pilniejszego problemu, jednym z źle określonych celów.

Jeśli masz bardzo jasne wyobrażenie, na piśmie, czy post-it z boku monitora lub w formalnych specyfikacji załączonych do śledzenia błędów wyboru, to prawie zawsze wiedzą dokładnie, co do pracy na następny . Jeśli zawsze pracujesz nad jedną z tych następnych rzeczy, będziesz mieć dużą szansę na sukces z projektem.

Z drugiej strony, jeśli twoje wyobrażenie o tym, co jest najważniejsze, jest mgliste, o wiele trudniej jest znaleźć coś, nad czym można by rozwiązać problem, który projekt ma rozwiązać, a ściślej - i osuszają przy podejmowaniu decyzji, że ta konkretna zmiana jest zakończona i rozwiązuje konkretny problem.

Jeśli masz taki cel, jak „ułatwienie korzystania z interfejsu użytkownika”, cóż, prawie niemożliwe jest określenie, jaka będzie kolejna poprawka, lub kiedy zakończysz „naprawianie interfejsu” i możesz przejść do czegoś innego. Z drugiej strony, jeśli Twoim celem jest „połączyć te listy rozwijane w polu wyszukiwania z autouzupełnianiem”, a „foo” powinno się automatycznie uzupełnić do „Fooly Brand Baring” ”, jest to całkowicie oczywiste, kiedy naprawiłeś ten problem.

Nie pisz żadnego kodu, dopóki nie masz naprawdę jasnego pojęcia, kiedy przestać , a jeśli nie masz żadnych jasnych pomysłów, pracuj nad uzyskaniem jednego z nich zamiast uruchamiania innej gałęzi dla jakiejś ogólnej funkcji.

Jeśli masz tak dobrą specyfikę pracy (nawet przy projektach osobistych), „przeskakiwanie” jest całkowicie w porządku, bezpieczne i przydatne.

Uniknięcie problemu może pomóc w jego rozwiązaniu, ale należy pamiętać, że zmiana kontekstu wiąże się z pewnymi kosztami. Powinieneś próbować to zrobić tylko wtedy, gdy naprawdę utkniesz lub gdy pojawia się zadanie o znaczeniu krytycznym (np. Klient nie działa).

Jeśli ciągle przełączasz się między zadaniami, możesz skończyć z kilkoma niedokończonymi funkcjami i dużą ilością zmarnowanego czasu. Dlatego praktyki takie jak kan-ban zachęcają do ustawienia limitu pracy w toku. W ten sposób możesz skupić się na wykonywaniu co najwyżej kilku zadań na raz, zwiększając w ten sposób przepustowość.

Czasami pomocne może być ograniczenie liczby funkcji wdrażanych równolegle. Odmów rozpoczęcia wdrażania dodatkowej funkcji, jeśli limit zostanie przekroczony, dopóki jedna inna funkcja nie zostanie zakończona. Takie podejście nazywa się Kanban