Jak radzić sobie z niezaimplementowaną jeszcze metodą, która zostanie wykonana przez współprogramistę?

To pytanie o pracę w zespołach.

Ostatnio pracowałem nad moim pierwszym większym (~ 80 klas, Java) projektem programistycznym z zespołem 6 osób, chociaż tylko 4 z nas pracowało nieprzerwanie nad kodem. Rozdaliśmy pracę do wykonania wcześnie i w pewnym momencie musiałem wywołać metodę, która nie została jeszcze zaimplementowana przez jednego z moich współprogramistów. Jak zalecany sposób poradzić sobie z tym?

Opcje, które widziałem, choć tak naprawdę nie lubię żadnej z nich:

Piszę sobie //TODOi przeglądam ten wiersz kodu później, aby sprawdzić, czy metoda została zaimplementowana w międzyczasie.
Poprosienie odpowiedniego członka zespołu o wdrożenie go teraz .
Zgłaszanie niestandardowego środowiska wykonawczegoException z jasnym opisem tego, co jeszcze nie zostało zaimplementowane. (Przynajmniej nie musimy długo szukać, aby dowiedzieć się, czego brakuje)
Dodając potrzebną metodę do ich klasy i zapisując je //TODOw treści wiadomości, być może również wyślesz im szybką wiadomość o tej zmianie. (Teraz nie jest to już mój problem, ale może to powodować irytujące konflikty scalania, jeśli w międzyczasie pracowali nad tą metodą)
Definiowanie abstrakcyjnych klas lub interfejsów dla wszystkiego przed napisaniem kodu, który działa. (Nie działało zbyt dobrze, ponieważ te interfejsy były często zmieniane)

teamwork

— lucidbrot
źródło

Myślę, że ten przepływ pracy, w którym potrzebujesz metody napisanej przez kogoś innego, jest niewłaściwy. Pracujesz nad funkcją. Jeśli ta funkcja wymaga metody, TY ją wdrażasz. Jeśli dwie osoby mają wdrożyć jedną funkcję, albo łączą się, albo integrują i komunikują się tak często, że prawie wygląda na to, że się łączą.

— Euforia

@Euphoric Wiele razy spotkałem się z sytuacją, w której dość duża nowa funkcja miała zostać opracowana w stosunkowo krótkim czasie i jako taki interfejs użytkownika, logika biznesowa i warstwy API musiały zostać podzielone na różne zadania, nad którymi jednocześnie pracowano, w przeciwnym razie termin nigdy nie zostałby dotrzymany. Właśnie tam osoba pracująca nad interfejsem użytkownika powinna deklarować BL metody dostępu do danych i polecenia jako interfejsy i pozwolić innym osobom pracować nad implementacją, pracując wyłącznie nad interfejsem użytkownika.

— Andy,

@DavidPacker To, co opisujesz, nie jest jedynym sposobem rozwiązania tego problemu. Plastry pionowe, częsta integracja, małe funkcje to lepsze rozwiązania niż plastry poziome z każdą osobą pracującą na osobnej części.

— Euforia

@Euphoric Nie mogę się z tobą więcej zgodzić. Jeśli to możliwe, wybieramy sposób usuwania złożonej nowej funkcji części niekrytycznych (tj. Tych, które poprawiłyby UX, ale nie były od razu potrzebne). Niestety, czasami wymienione opcje, ani funkcja usuwania funkcji, nie są możliwe. Biznes mówi, że programiści tak. Tak więc, chociaż twoje punkty są solidne, istnieje również prawdopodobieństwo, że ktoś spotka się z sytuacją, w której konieczne będzie dokonanie pewnego podziału pracy w celu spełnienia potrzeb firmy.

— Andy

Co o rozmowy z nim, jak chce go obsłużyć?

— Aganju

Odpowiedzi:

To interesujące pytanie, a odpowiedź może być łatwiejsza niż myślisz.

Mówiąc prosto, napisz testy, które potwierdzą twoje założenia. Nie ma znaczenia, czy wykonasz implementację, czy twoi koledzy programiści

Długa odpowiedź.

Każda z opcji, że liście są nieco pasywne i wymagają Państwo wrócić i ponownie kod (jeśli istnieje) prędzej czy później.

Komentarze muszą być czytane i obsługiwane przez partnera odpowiedzialnego za wdrożenie. W międzyczasie Twój kod nie może zostać skompilowany. Jeśli sprawdzisz taki stan w repozytorium kodu, potok ciągłej integracji nie będzie działał, a mimo to jest to zła praktyka ... nigdy nie sprawdzaj uszkodzonego kodu
Wyjątki czasu wykonywania wydają się lepsze, ale nadal są toksyczne, ponieważ inny programista może założyć, że implementacja została już wykonana bez sprawdzania, pozostawiając również system w niestabilnym stanie. Jeśli metoda jest uruchamiana nie tak często, może to prowadzić do zepsucia kodu produkcyjnego ... również złej praktyki ... nigdy nie sprawdzaj wyjątków „niezaimplementowanych”
Oczekiwanie na innych programistów na wdrożenie metod lub kodu pośredniczącego również zniechęca. Przerywa przepływ pracy i przepływ pracy innych programistów. Co się stanie, jeśli będą chorzy, podczas spotkania lub przerwy na kawę, czy chcesz spędzić czas na oczekiwaniu? ... nie czekaj na kogoś, jeśli nie musisz
zdecydowanie zaimplementuj brakujące metody . Ale co się stanie, jeśli twoja implementacja nie spełnia całego przypadku użycia i twoi koledzy programiści muszą go zmienić lub zmienić? W jaki sposób Ty i oni upewniacie się, że jest on nadal zgodny z zamierzonym? Odpowiedź znów jest łatwa. Pisz testy, które weryfikują, opisują i dokumentują twoje zamiary. Jeśli testy zakończą się, łatwo to zauważyć. Jeśli trzeba wprowadzić zmiany w tej metodzie, które zepsują twoją funkcję ... natychmiast ją zobaczysz. Oboje macie powód do komunikowania się i decydowania, co robić. Czy podzielić funkcjonalność? Zmień implementację itp. ... nigdy nie wpisuj kodu, który nie jest wystarczająco udokumentowany testami

Aby osiągnąć wystarczający poziom testowania, sugeruję przyjrzeć się dwóm dyscyplinom.

TDD - rozwój oparty na testach - upewni się, że opisałeś swoje zamiary i wystarczająco je przetestowałeś. Daje także możliwość kpienia lub fałszowania metod i klas (również przy użyciu interfejsów), które nie zostały jeszcze zaimplementowane. Kod i testy nadal będą się kompilować i pozwolą na przetestowanie własnego kodu w oderwaniu od kodu innych programistów. (patrz: https://en.wikipedia.org/wiki/Test-driven_development )
ATDD - rozwój oparty na testach akceptacyjnych - stworzy to zewnętrzną pętlę (wokół pętli TDD), która pomoże przetestować tę funkcję jako całość. Testy te zmienią kolor na zielony, gdy cała funkcja zostanie zaimplementowana, dając w ten sposób automatyczny wskaźnik, kiedy twoi towarzysze zakończą swoją pracę. Całkiem fajnie, jeśli mnie zapytasz.

Zastrzeżenie: W twoim przypadku pisałbym tylko proste testy akceptacyjne i nie próbowałbym wnieść zbyt dużej części strony biznesowej, ponieważ byłoby to po prostu zbyt wiele na początek. Napisz proste testy integracyjne, które składają się na wszystkie części systemu, których wymaga ta funkcja. To wszystko, co jest wymagane

Umożliwi to umieszczenie kodu w potoku ciągłej integracji i uzyskanie wysoce niezawodnej implementacji.

Jeśli chcesz przejść dalej w tym temacie, sprawdź następujące linki:

— Jesko R.
źródło

103

Poproś o odcinki.

Lub napisz je sam. Tak czy inaczej, ty i twoi współpracownicy musicie uzgodnić interfejsy i sposób ich użycia. Porozumienie to musi być stosunkowo solidne, abyś mógł opracować go przeciwko skrótom - nie wspominając o tym, abyś mógł stworzyć własne symulacje do testów jednostkowych ...

— svidgen
źródło

^^ To. Jeśli właściwie używasz interfejsów, nie powinieneś potrzebować implementacji, dopóki drugi facet nie skończy ich pisać.

— Robert Harvey

I dalej komentarz Roberta, jeśli nie używasz właściwie interfejsów w projekcie specjalnie zaprojektowanym do podziału na wiele osób, to będziesz miał zły czas ...

— corsiKa

Szkoda, że Java nie ma plików nagłówkowych. W świecie C / C ++ możesz opracować interfejsy API i najpierw napisać wszystkie nagłówki, a brak implementacji staje się problemem dla linkera. (Nieznaczne uproszczenie, ABI musi również pozostać na stałym poziomie, aby było to po prostu kwestia linkera).

— Wes Toleman

@WesToleman Zabawnie, jedną z moich ulubionych rzeczy w Javie jest to, że nie ma plików nagłówkowych. „Interfejsy”, o których wspominali Robert i corsiKa, doskonale wypełniają tę rolę. Najpierw opracowujesz interfejsy API, piszesz interfejsy, a brak konkretnej implementacji nie stanowi problemu dla kompilatora.

— GrandOpener

@WesToleman Czy to Ci odpowiada? W moich uszach brzmi to trochę jak wodospad, i przypuszczam, że musisz zaktualizować interfejs, gdy zdasz sobie sprawę, że przegapiłeś ten „ważny parametr”?

— netigger

W twojej sytuacji rozmawiałbym z członkiem zespołu odpowiedzialnym za tę funkcję. Możliwe, że są w stanie ustalić priorytet rozwoju tej funkcji, abyś mógł zacząć z niej korzystać wcześniej.

Uniknę twojej czwartej opcji. Napisałeś cały swój kod i, jak mówisz, nie uważasz już, że to twój problem. Twój kolega pisze następnie implementację funkcji i nie uważa już jej za problem. Kto faktycznie przetestuje poprawność kodu, który napisałeś?

— Pete
źródło

Powinieneś poprosić o API dla tej funkcji, która powinna dać jeden lub więcej interfejsów. Dobrym pomysłem może być zrobienie tego razem, ponieważ będziesz musiał użyć tego interfejsu, aby zaprojektować początkowe przypadki testowe na podstawie danych wejściowych. Rzeczywista implementacja może później nastąpić (łącznie z możliwymi zmianami API)

— Thorbjørn Ravn Andersen