Jak najlepiej zaangażować młodszego programistę w projektowanie aplikacji od podstaw? [Zamknięte]

Jesteśmy zespołem 3 programistów (2 doświadczonych programistów i juniorów).

Właśnie rozpoczęliśmy nowy projekt. Zaprojektowaliśmy aplikację, skoncentrowaliśmy wysiłki na wyborze odpowiedniej architektury, a teraz układamy pierwsze linie kodu. Piszemy jego rdzeń, który będzie podstawą całej aplikacji.

To też nie jest łatwa aplikacja. Trudne wymagania dotyczące wydajności, masowo rozproszony, złożony model jednostki itp

Wszyscy jesteśmy poza naszą strefą komfortu, szczególnie junior. Nie ma doświadczenia, aby z góry stworzyć dobry projekt. Nie jest to jednak problem, ponieważ ja i pozostali deweloperzy jesteśmy po to, aby pomóc i oboje wierzymy w mentoring i budowanie zespołów, ale ... nie wiemy dokładnie, jaki byłby najlepszy sposób, aby to zrobić, więc on dostaje przyjemne doświadczenie i uczy się maksymalnej ilości umiejętności.

Obaj zdaliśmy sobie sprawę, że nie mieliśmy juniora przy nowych projektach, tylko przy istniejących, gdzie było łatwiej, ponieważ miał całą bazę kodu, z której mógł się uczyć i inspirować. Ale dla tej aplikacji nie mamy prawie żadnego kodu. Właśnie zaczęliśmy.

Myśleliśmy o kilku podejściach:

• poproś go, aby spróbował sam przez kilka dni, a następnie zainterweniuj i popraw kod razem z nim, skieruj go we właściwym kierunku, a następnie powtórz => To może nie być dla niego zabawne doświadczenie, ponieważ będziemy wskazywać jego błędy na każdym refaktorze ;
• poproś go, aby sparował programowanie z jednym z nas => może stać się tylko „obserwatorem” i zgodzić się ze wszystkim, co robimy, bez faktycznego uczenia się i trawienia dużej ilości informacji;
• kazać nam zbudować szkielet każdego modułu, z solidną konstrukcją, a następnie przekazać mu moduł, aby dodać brakujące elementy => może nie być zabawne, aby podnieść się za nami i istnieje ryzyko, że zwróci on uwagę tylko na wypełnienie luk a nie cały projekt.

Jak możemy zaangażować go w projekt, aby nie czuł się jakoś poza nim i aby wiele się nauczył z tego doświadczenia i zyskał wystarczającą pewność siebie, aby wypróbować go samodzielnie?

Polecam następujące wytyczne:

• Zaangażuj młodszego programistę w spotkania projektowe i zdobądź jego wkład. To sprawi, że pomyśli o dużym obrazie, nawet jeśli sam nie jest gotowy do wykonania projektu na wysokim poziomie.
• Spróbuj wyizolować i jasno zdefiniować moduł aplikacji, który ma zostać przypisany do młodszego programisty. Opisz na piśmie, jakie są wejścia / wyjścia i inne wymagania modułu. Unikaj przypisywania mu modułu, którego nie można łatwo przetestować lub który można przetestować tylko po zintegrowaniu z innymi modułami, które mają być jeszcze napisane.
• Być może młodszy programista mógłby pomóc w inny sposób niż kodowanie podstawowej aplikacji. Na przykład mógłby napisać kod testowy. Pisanie dobrych skryptów testowych nie tylko nie jest zwykłą pracą, ale stanowi cenny wkład w projekt, a także zapewnia młodemu programistowi solidne zrozumienie projektu.

Myślę, że to zależy od tego, w którym obszarze chcesz ulepszyć tego młodszego programistę. Kiedy byłem (bardzo) młodszy, dawali mi API, że muszę zbudować jedną konkretną ograniczoną rzecz, taką jak:

• ta funkcja podaje N liczby personelu z tabeli Personnel
• ta funkcja zapewnia statystyki personelu na podstawie jego identyfikatora

->

Zadanie: zbuduj stronę z listą personelu, która pokazuje jego statystyki po kliknięciu rekordu personelu. Oto prosta przykładowa strona zbudowana wcześniej w projekcie.

Najważniejszym aspektem danego zadania jest to, że można je rozwiązać tylko dzięki danym zasobom i nie wymagają one żadnych zmian w nich.

Wszystkie 3 sposoby wyglądają dla mnie dobrze. Właściwie wypróbowanie 10 różnych zwinnych metod w tym samym czasie powinno wkrótce dać dobre wyniki, przynajmniej będziesz wiedział, który sposób działa, a który nie (który z nich będzie najlepszy, zależy bardzo od osobowości graczy).

Problem z programowaniem par nie wystąpi, jeśli będziesz trzymać się procesu z przełączaniem kapeluszy do pisania / myślenia co 10 minut (lub tak), bez wyjątku, zgodnie z procesem pierwotnie opisanym przez Kenta Becka (nie pamiętam gdzie)

Jeśli chodzi o zaangażowanie innych osób w projektowanie - to, co odkryliśmy, pomaga w tym, że w fazie projektowania tworzone są dokumenty projektowe (z niektórymi modelami UML). Inne osoby (twój młodszy) mogą następnie je przeczytać, przejrzeć, zagrać w adwokata diabła. Ta rola niezależnej, nieskażonej strony trzeciej może być w rzeczywistości bardzo korzystna, np. W przypadku testów eksploracyjnych - http://www.softwaretestinghelp.com/exploratory-testing-beyond-traditional-testing-boundaries