Jak programiści pracują razem nad projektem?

Jestem studentem, który niedawno ukończył kurs inżynierii oprogramowania, na którym cały semestr składał się z gigantycznego projektu grupowego. Pozwól, że zacznę od tego, że moglibyśmy zrobić z 3 osobami to, co zajęło nam 12 przez cały semestr. Praca z ludźmi to ciężka sprawa. Komunikacja jest kluczowa.

Zdecydowanie korzystaj z repozytorium. Każda osoba może zdalnie uzyskać dostęp do całego kodu i dodać/usunąć / zmienić cokolwiek. Ale najlepsze w subversion jest to, że jeśli ktoś złamie Kod, możesz wrócić do wcześniejszej wersji i ocenić, co poszło nie tak. Komunikacja jest jednak nadal kluczowa, wiedz, co robią Twoi koledzy z drużyny, aby nie było konfliktów. Nie siedź też na swoim kodzie, twórz szybkie, znaczące commity do repozytorium, aby były najbardziej skuteczne.

* * polecam również tracker błędów, takich jak Redmine. Możesz skonfigurować konta dla każdego i przypisać ludziom zadania o różnych priorytetach, a także śledzić i sprawdzać, czy ludzie zadbali o to niektórych problemów, lub jeśli pojawiło się więcej.

I, jak już zostało powiedziane, testy jednostkowe bardzo pomogą. Powodzenia! Mam nadzieję, że to pomogło: -)

Wielkie rzeczy to:

• plan - jeśli ludzie nie wiedzą dokąd idą, to nigdzie nie pójdą. Rozpoczęcie każdego projektu wymaga zatem kilku osób (często graybeards projektu), aby zebrać się i wymyślić plan; plan nie musi być bardzo szczegółowy, ale nadal jest wymagany.
• system kontroli wersji - bez tego nie będziecie współpracować. Potrzebujesz również zdecydowanego zaangażowania, że jeśli rzeczy nie są zaangażowane, nie liczą się. "Och, jest w jednej z moich piaskownic" to tylko kiepska wymówka.
• Issue tracker - nie możesz śledzić tych rzeczy przez foldery e-mail. Powinno być oparte na bazie danych.
• System Powiadomień - ludzie muszą wiedzieć, kiedy rzeczy są zaangażowane w kod, który utrzymują lub komentarze są robione do błędów, za które są odpowiedzialni. E-mail Może działać w tym celu, podobnie jak IRC(oczywiście pod warunkiem, że wszyscy go używają).
• Build system - nie naprawdę ważne Jak to się dzieje, o ile za pomocą jednej akcji możesz uzyskać pełną kompilację aktualnego stanu rzeczy, zarówno twojego deweloperskiego piaskownicy, jak i głównego repozytorium. Najlepsza opcja zależy od tego, jakiego języka(języków) używasz.
• zestaw testów - zestaw testów pomaga uniknąć głupich błędów. Musi być tak łatwy do uruchomienia jak build(bycie częścią build jest dobre ). Zauważ, że testy są jedynie surowym substytutem poprawności, ale są o wiele lepsze niż nic.

Wreszcie, potrzebujesz gotowości do współpracy w celu realizacji planu. To zbyt często najtrudniejsza część.

Ogólnie dobrą praktyką jest nie sprawdzanie artefaktów wbudowanych w repozytorium. Repozytorium będzie zawierało drzewo źródłowe, konfigurację kompilacji itp. - wszystko, co napisał człowiek. Inżynierowie oprogramowania sprawdzą kopię swojego kodu na lokalnym systemie plików i zbudują go lokalnie.

Dobrą praktyką jest również posiadanie testów jednostkowych, które są uruchamiane w ramach procesu budowania. W ten sposób programista będzie natychmiast wiedział, czy jego zmiany unieważniły którekolwiek z testów jednostkowych, oraz będzie miał okazję je naprawić przed sprawdzeniem swoich zmian.

Możesz zajrzeć do dokumentacji dla systemu kontroli wersji (Subversion, CVS, Git, itp.) oraz dla systemu budowania (na przykład w Javie są Ant i Maven).

Jak Programiści współpracują nad oprogramowanie w firmie

Programiści nigdy nie pracują jako zespół. Drużyny są do bani. Dilbert jest zabawny nie dlatego, że jest komiczną postacią jak Goofy. Jest zabawny, bo jest prawdziwy i ludzie rozpoznają jego sytuacje.

Nie ma standardu dla rzeczy, o które prosisz. Istnieją raczej konwencje, które w dużej mierze zależą od wielkości i dojrzałości organizacji. Jeśli jesteś w małej organizacji, powiedzmy kilku programistów, to prawdopodobnie sprawy będą nieco nieformalne, gdy poszczególni programiści będą kodować, kompilować i testować.

W większych organizacjach, może być dedykowany Inżynier budowy i procesu. Tego rodzaju organizacja zwykle robi formalne budować na regularnie, powiedzmy raz dziennie, używając dowolnego kodu źródłowego. Proces będzie również zwykle obejmować BVT (Build Validation Tests) i być może niektóre testy regresyjne. Programiści będą sprawdzać kod z repozytorium, pracować nad własną częścią lokalnie, a następnie go sprawdzać.

W największych organizacjach, takich jak Microsoft czy Google, będą one miały całkowicie oddaną grupę i pełne laboratorium, które będzie budować na bardziej lub mniej ciągłych podstawach, dzięki czemu wyniki każdego biegu dostępny. Organizacje te mają bardzo formalne procesy i procedury dotyczące tego, co i kiedy jest sprawdzane, jakie są procesy przeglądu kodu itp.

Krótka odpowiedź - "to zależy".

Obecnie pracuję nad projektem sam, więc to ja buduję / używam VCS. Wiem o innych miejscach, że masz zespoły pracujące nad projektem razem przez shudder e-mail. Lub duże (+5) zespoły korzystające z VCS.

W tej kwestii, Gorąco polecam nauczenie się przynajmniej niektórych VCS, a Joel Spolsky ma świetny wstęp tutorial dla Mercurial. Bazaar (mój osobisty wybór) jest podobny, a potem Git jest najbliższy pod względem podobieństwo, ale chyba bardziej popularne niż którekolwiek (przynajmniej ATM). Po tym masz SVN, który jest dość słaby w porównaniu.

Właściwie, Joel mówi o większości twoich pytań-polecam przeczytać 10 lat archiwów, które ma - to bardzo przydatne informacje, a większość z nich odnosi się do twojej obecnej i bliskiej przyszłości sytuacji.

Nie ma książki kucharskiej do pracy z rozwojem oprogramowania, ale ogólnie system kontroli wersji powinien być sercem Twojego systemu budowania, nawet jeśli pracujesz w projekcie, w którym jesteś jedynym programistą. Nawet w tym przypadku, możliwość przywrócenia wersji i przeczytania dziennika wersji jest bardzo mile widzianą pomocą w naprawianiu błędów. Nie jest to jedyna funkcja systemu kontroli wersji, ale to samo uzasadnia instalację, konfigurację i utrzymanie systemu kontroli wersji.

The budowanie może być wykonywane przez każdego dewelopera podczas dodawania nowego kodu lub okresowo przez "serwer budowania". Ostatnie podejście wymaga większej konfiguracji, ale pomaga szybciej wykryć błędy kompilacji.

Właściwe programowanie to głęboka rzecz, która czerpie ogromne korzyści z doświadczenia. Programowanie par jest jak uruchamianie wielu procesorów świadomości... jeden może przeoczyć coś widzianego przez drugiego i tak długo, jak komunikują się to może doprowadzić do wielkiego postępu.

Przede wszystkim zespoły pracują przy użyciu repozytoriów (które mogą być profesjonalną kontrolą wersji lub po prostu kilkoma katalogami, które są uważane za "żywe", jednak system kontroli wersji jest de facto standardem). Ponadto, jak projekt jest zarządzany strategia zależy od tego, jak pracujesz (wodospad, zwinny, itp.). Jeśli pracujesz w iteracjach, budujesz komponenty / wtyczki/Moduły/biblioteki, które są samowystarczalne i wykonujesz testy jednostkowe, dopóki nie zostanie ono podpisane jako zakończone. Jako zespół, ty pracuj w zespole, co oznacza, że nie pracujesz nad całym projektem wszędzie w tym samym czasie. Zamiast tego otrzymujesz zadanie do wykonania wewnątrz obszaru projektu. W niektórych przypadkach musisz naprawić kod, który nie jest Twój, ale zwykle pojawia się, gdy wystąpi dziwne zachowanie. Zasadniczo, robisz testowanie części, które opracowujesz.

Pozwól, że ci to wyjaśnię. Jesteś w zespole pracowników budowlanych. Architekt przychodzi z planem budynku, brygadzista patrzy Co trzeba budować, a potem zatrudniać konstruktorów. Murarz robi ściany, sprawdza je pod kątem wytrzymałości i ładnie je skleja. Elektryk wykonuje wszystkie okablowanie wewnątrz budynku, aby prąd mógł płynąć. Każdy ma swoją pracę. Czasami elektryk może chcieć omówić z murarzem, czy niektóre ściany mogą być rzeźbione, ale zawsze w połączeniu z brygadzistą.

Mam nadzieję, że to jakaś pomoc dla Ciebie!

Zazwyczaj system kontroli źródła zawiera kod źródłowy i zazwyczaj nie ma binariów. Jeśli chcesz go zbudować i uruchomić, sprawdź kod i zbuduj go na lokalnej maszynie.

Niektóre miejsca uruchamiają nocne Kompilacje, aby upewnić się, że wszystko działa. Mogą nawet istnieć zautomatyzowane testy, które są uruchamiane po stronie serwera. Jeśli kompilacja lub cokolwiek innego nie powiedzie się, ktoś zostanie automatycznie powiadomiony.

Dobrym wprowadzeniem do metody wykorzystania kontroli źródeł jest HOWTO kontroli źródeł Erica Sinka http://www.ericsink.com/scm/source_control.html

W swoich przykładach używa SourceGear Vault, ponieważ go napisał i w ogóle, ale metody mogą być stosowane do innych systemów kontroli wersji.

To kolejny dobry powód, dla którego warto zajrzeć do projektów Open Source.

Wiodącymi programistami pracującymi w dużych projektach OpenSource (takich jak Chromium , Mozilla Firefox, MySQL , popularne oprogramowanie Gnu) są profesjonaliści. Mają duże doświadczenie i projekty te ewoluowały przez lata z pomysłami od setek takich profesjonalistów.

Wszystko, co inni wymienili w swoich odpowiedziach (Plan, system kontroli wersji, Issue tracker, system powiadomień , system budowania, Test suite,) można znaleźć w tych projektach OpenSource.

Jeśli naprawdę chcesz mieć praktyczne doświadczenie, zdecydowanie sugeruję, abyś przejrzał popularne i duże projekty OpenSource, a następnie zdobył źródło z dowolnego projektu (używając kontroli wersji) i zbudował je sam.

PS: jestem również studentem i zaangażowanie w projekty OpenSource jest najlepszą rzeczą, jaką zrobiłem w życiu. Zaufaj mi! ty też poczujesz to samo.