Jak działa praca w zespole (w projekcie OO)? [Zamknięte]

Sam programuję w Javie w bardzo OO. Nigdy nie miałem okazji współpracować z innymi programistami (przynajmniej nie jestem profesjonalistą).

Z ciekawości chciałem zapytać: Jak działa praca z zespołem nad projektem, szczególnie podczas pracy nad projektem OO?

Jak działa podział zadań? Jak stworzyć coś, co z powodzeniem będzie współpracować z czymś opracowanym przez innego programistę? Jak i kiedy komunikują się programiści?

Dzięki

Mam nadzieję, że mogę ci trochę pomóc, a przynajmniej wskazać właściwy kierunek!

Jest to jednak trochę zrzeczenie się odpowiedzialności, jest to ogromny temat - i myślę, że naprawdę trzeba go „ wrzucić ”, aby uzyskać głębokie zrozumienie. To powiedziawszy, omówię dwa główne problemy:

1. Kod i kontrola źródła
2. Komunikacja i kilka wskazówek.

Jeśli chodzi konkretnie o projekty OOP - szczerze mówiąc, nie widzę zbyt wielu problemów specyficznych dla OOP, których nie ma nigdzie indziej.

W rzeczywistości myślę, że programowanie w stylu OOP jest niezwykle odpowiednie do rozwoju zespołu. Jednym z kluczowych etosów OOP jest to, że nie powinienem znać wszystkich szczegółów na temat każdego obiektu, z którym wchodzę w interakcje: po prostu muszę wiedzieć, co on może zrobić i jak mogę to zrobić.

Abstrakcje, które może zapewnić OOP, są niesamowite w zespole.

Kontrola źródła

Musi istnieć centralne miejsce do przechowywania projektu, i takie, które pozwala wielu programistom na dostęp do bazy kodów jednocześnie. To tutaj pojawiają się systemy takie jak Git (lub SVN).

Mogę tylko mówić konkretnie o Git, ponieważ nigdy nie korzystałem z SVN - jednak uważam, że są one podobne, ale mają inną terminologię.

Za pomocą Git mogę utworzyć repozytorium z całym kodem źródłowym dla danego projektu, a następnie pozwolić mojemu zespołowi na dostęp do repozytorium. Dla każdej wprowadzonej następnie funkcji lub poprawki błędu, programiści mogą stworzyć własną „gałąź”, co oznacza, że ​​rozwój może odbywać się równolegle.

Po zakończeniu funkcji lub poprawki można ją „ scalić ” z powrotem w bazie kodu głównego projektu. Wszelkie „ konflikty ” mogą być następnie wykryte przez Git i rozwiązane na poziomie źródła przez odpowiedzialnego programistę.

Nie jestem pewien, czy używałeś Gita wcześniej, ale na początku może wydawać się dość skomplikowany - ale dzięki jego niedawnej popularności (częściowo Githubowi ) istnieje całe mnóstwo samouczków i zasobów.

Jeśli nie korzystałeś z niego wcześniej, zalecamy zarejestrowanie się w GitHub i sprawdzenie tego w ten sposób! (Alternatywnie, Bitbucket jest podobną alternatywą, ale pozwala ci mieć prywatne repozytoria za darmo.)

Git Flow to doskonały przepływ pracy oparty na Git, który jest niezwykle przydatny dla zespołów. Podobnie jak Git w ogóle, kiedy będziesz z nim pracować przez chwilę, trudno sobie wyobrazić pracę bez niego w zespole!

Komunikacja

Kiedy miniesz wszystkie bariery techniczne, naprawdę sprowadzasz się do podstawowej kwestii, która nęka większość projektów (technicznych lub nie) - i to jest komunikacja.

Cały zespół musi wiedzieć, kto co robi, kiedy to robi i co to ma wpływ.

Odpowiedzialność musi być jasno określona

Jest to oczywiste, ale większość projektów korzysta z jakiejś formy systemu sprzedaży biletów - w której wszelkie żądania funkcji lub błędy są rejestrowane, a następnie przypisywane do konkretnego członka personelu. ( JIRA , Unfuddle itp.) Często są one wbudowane w system kontroli źródła, co ułatwia życie. (Zarówno BitBucket, jak i GitHub zapewniają śledzenie problemów dla hostowanych na nich repozytoriów Git).

To powstrzymuje lub pomaga przynajmniej zapobiegać przypadkowym pracom programistów nad tymi samymi problemami.

Nie jest to jednak kompletna poprawka; nadal musisz upewnić się, że programiści są świadomi obowiązków innych programistów. Wiem, że w przeszłości naprawiłem inne problemy, na które natknąłem się podczas naprawy konkretnego błędu, tylko dlatego, że ma to sens. („ Cóż, już tu jestem. To może zrobić z refaktorem i być może mogę sprawdzić inne problemy. ”) Następnie musiałem przeprosić innych programistów, którzy pracowali nad tymi innymi problemami, które mam naprawione - marnowanie naszego czasu.

Zasadniczo te problemy można rozwiązać przez ...

Regularne spotkania

Niektóre metodologie zarządzania projektami / rozwoju określają określone metody komunikacji lub terminy spotkań. Ogólnie rzecz biorąc, najbardziej produktywnymi systemami, jakie widziałem, były poranne spotkania stand-up, podczas których wszyscy w zespole szybko podsumowują to, co robią - jeśli ograniczysz to tylko do członków zespołu programistów i będziesz mieć jasne wytyczne na temat tego, co komunikowanie się może być niezwykle skuteczne. Zawsze starałem się trzymać:

Pracuję nad X,

Aby osiągnąć / naprawić Y,

Który obejmuje modyfikację / zmianę Z.

Inni członkowie zespołu mogą od razu zrozumieć, że „ Fergus pracuje nad naprawieniem tego błędu, który został zarejestrowany innego dnia, jednak oznacza to, że pracuje nad kodem, który muszę przejrzeć - skontaktuję się z nim przed wprowadzeniem jakichkolwiek zmian. „.

Spotkania architektoniczne

Niedawno współpracowałem ze wspaniałym zespołem, który co dwa tygodnie przeprowadzał „ czat techniczny ”, podczas którego omawiano większe / architektoniczne problemy. Każdy członek zespołu miał czas na zrozumienie większych problemów stojących przed projektem i mógł omówić potencjalne poprawki.

Osobiście to uwielbiałem, nie włożyłem dużo wkładu, ponieważ byłem całkiem nowy w projekcie - ale możliwość wysłuchania dyskusji dało mi dużo wglądu; już wkrótce mogłem zrozumieć projekt oraz indywidualne style myślenia.

Komunikacja to jedyny problem, który może powalić każdy zespół. Technicznie czy nie, jeśli ludzie nie są świadomi większego obrazu, istnieje większe prawdopodobieństwo, że poniosą porażkę.

Inne sprawy

Dobrze jest upewnić się, że każdy ma taką samą konfigurację lub styl podczas pracy w zespole. Co mam na myśli?

Konfiguracja

Jeśli pracujesz nad projektem Java - być może dobrym pomysłem może być zapewnienie (przynajmniej dla środowisk programistycznych, na pewno nie do testowania) wersji JVM w zespole? Następnie IDE. Pomaga to w znacznej mierze, jeśli cały zespół używa Eclipse lub NetBeans lub twojego IDE.

W przypadku projektu internetowego może się zdarzyć, że wszyscy programiści potrzebują określonego stosu; z konkretnymi wersjami Apache lub PHP .

Myślenie o takich czynnikach pozwala mi po prostu „żelować” nieco szybciej.

Styl

Tabulatory a spacje? CamelCase czy spacing_with_underscores? Tak małe, jak te pytania, mogą być, gdy pracujesz sam, pracując z większym zespołem, naprawdę chcesz dążyć do wspólnego stylu.

W rzeczywistości nie powinieneś naprawdę wiedzieć, kto napisał określoną sekcję kodu - powinieneś po prostu wiedzieć, że należy .

Właśnie dlatego wiele projektów typu open source otwarcie publikuje wytyczne / przewodniki po stylach kodu źródłowego - aby dowiedzieć się, co one zawierają, zapoznaj się z Google StyleGuides dla ich własnych projektów typu open source.

Zadania i testy jednostkowe

Nie ogranicza się to do drużyn, ale zamierzam to szybko omówić z jednego powodu, w szczególności: znacznie ułatwia życie zespołowe.

Jeśli masz złożony przepływ pracy z wieloma zależnościami lub długi proces kompilacji - często warto zautomatyzować to za pomocą programu uruchamiającego zadania. W przypadku projektów internetowych GruntJS jest niesamowity, chociaż wydaje się, że pochodzący z Javy Apache Ant może być całkiem podobny.

Jako osoba indywidualna używam GruntJS do budowy mojej witryny przed wdrożeniem jej na serwerze FTP - wystarczy jedno polecenie Grunt, aby skompilować i zminimalizować mój CSS / Sass , skompresować moje zasoby, a następnie przesłać moje pliki.

Jako członek zespołu mogę jednak używać GruntJS, aby sprawdzić, czy nie przełamałem żadnych testów - i nie wprowadziłem żadnych błędów, ponieważ nie jestem w pełni świadomy innych części projektu. Jest to oczywiście dodatkowe korzyści, jakie daje mi jako indywidualny programista.

Mogę go również użyć, aby móc sklonować projekt za pomocą mojego fantazyjnego pakietu kontroli źródła (Git) - i uruchomić jedną komendę, aby zainstalować wszystkie moje zależności. To duży plus, ponieważ czas poświęcony nowemu deweloperowi na pozycję, w której mogą rozpocząć tworzenie, może być dość duży - nawet bez uwzględnienia czasu potrzebnego na przyzwyczajenie się do nieznanej bazy kodu.

Dokumentacja

Najlepsze projekty, jakie widziałem, miały dokumentację (i często dość nadmierną) skierowaną do programistów. Tego rodzaju dokumenty mogą wyjaśniać takie rzeczy jak:

1. Środowisko programistyczne:

„Obecnie wdrażamy na serwerze z uruchomionym stosem LAMP , ponieważ programiści powinni kierować się na wersje przedstawione w…”

2. Przepływ pracy

„Wszystkie funkcje należy opracować w gałęzi„ feature / * ”i połączyć z gałęzią„ testowania ”, zanim zostaną uznane za gotowe do wydania.”

3. Obowiązki w zespole:

„W przypadku problemów z bazą danych porozmawiaj ze Stevem. W przypadku problemów z platformą porozmawiaj z Davidem.”

4. „ Rurociąg ” na przyszłość

„Tworząc nowy kod, pamiętaj, że od czerwca 2014 r. Chcemy wdrożyć X - starszy kod może wymagać przeglądu, zanim to nastąpi.”

Przykłady

Warto przyjrzeć się przepływowi pracy projektu open source, aby przekonać się, jak to działa - niezależnie od tego, czy jest to ustalony z własnym przepływem pracy (często mocno udokumentowany), czy jednym z wielu przykładów na GitHub.

Ostatnie słowo ostrzeżenia

Jeśli znajdziesz się w pracy w zespole, który zarządza, aby zrobić wszystko z tego prawa .. będziesz nienawidzić będąc nigdzie indziej ..! Zabierz to ode mnie, gdy poznasz dobry zespół, nagle problemy w innym miejscu mogą naprawdę cię sprowadzić. (To jednak historia na inny post!)