Jak programiści współpracują przy projekcie?

Zawsze programowałem sam, nadal jestem studentem, więc nigdy nie programowałem z nikim innym, nigdy wcześniej nawet nie korzystałem z systemu kontroli wersji.

Pracuję teraz nad projektem, który wymaga wiedzy o tym, jak programiści pracują razem nad częścią oprogramowania w firmie.

Jak jest kompilowane oprogramowanie? Czy to z systemu kontroli wersji? Czy to przez indywidualnych programistów? Czy to jest okresowe? Czy to kiedy ktoś decyduje się na budowę czy coś? Czy są wykonywane jakieś testy, aby upewnić się, że „działa”?

Cokolwiek się nada.

W rzeczywistości istnieje tyle odmian tych procesów, ile jest firm. Znaczenie: każda firma ma nieco inne konwencje niż inne, ale jest kilka wspólnych najlepszych praktyk, które są powszechnie stosowane w większości miejsc.

Najlepsze praktyki, które są zawsze przydatne

• Cały kod źródłowy projektu i wszystko, co jest wymagane do jego zbudowania, podlega kontroli wersji (nazywanej również kontrolą źródła). Każdy powinien być w stanie zbudować cały projekt jednym kliknięciem.
  Ponadto niepotrzebne pliki (pliki obiektowe lub skompilowane pliki binarne) nie powinny być dodawane do repozytorium, ponieważ można je dość łatwo zregenerować i po prostu marnują miejsce w repozytorium.
• Każdy programista powinien aktualizować i zobowiązać się do kontroli wersji kilka razy dziennie. Przeważnie po zakończeniu zadania, nad którym pracują i przetestowaniu go na tyle, aby wiedzieć, że nie zawiera ono trywialnych błędów.
• Ponownie: każdy powinien być w stanie zbudować projekt jednym kliknięciem. Jest to ważne i ułatwia testowanie dla każdego. Duża zaleta, jeśli osoby nie będące programistami (np. Szef) też to potrafią. (Dzięki temu czują, że mogą dokładnie zobaczyć, nad czym dokładnie pracuje zespół).
• Każdy programista powinien przetestować nową funkcję lub poprawkę błędu, którą dodaje, zanim wprowadzi ją do repozytorium.
• Skonfiguruj serwer, który regularnie (w określonych odstępach czasu) aktualizuje się z repozytorium i próbuje zbudować wszystko w całym projekcie . Jeśli to się nie powiedzie, wysyła e-maile do zespołu wraz z najnowszymi zatwierdzeniami do kontroli wersji (od którego zatwierdzenia nie udało się zbudować), aby pomóc w debugowaniu problemu.
  Ta praktyka nazywa się ciągłą integracją, a kompilacje są również nazywane kompilacjami nocnymi .
  (Nie oznacza to, że programiści nie powinni tworzyć i testować kodu na swoich własnych maszynach. Jak wspomniano powyżej, powinni to robić).
• Oczywiście każdy powinien znać podstawowy projekt / architekturę projektu, więc jeśli coś jest potrzebne, różni członkowie zespołu nie muszą wymyślać koła na nowo. Pisanie kodu wielokrotnego użytku to dobra rzecz.
• Jakiś komunikacji potrzebna jest między członkami zespołu. Każdy powinien przynajmniej trochę zdawać sobie sprawę z tego, co robią inni. Im więcej tym lepiej. Dlatego codzienna walka jest przydatna w zespołach SCRUM.
• Testowanie jednostkowe to bardzo dobra praktyka, która automatycznie testuje podstawową funkcjonalność kodu.
• Oprogramowanie śledzenia błędów (czasem nazywane oprogramowanie śledzące czas ) jest bardzo dobrym środkiem śledzenie jakie błędy są i jakie zadania różne członkowie zespołu. Jest również dobry do testowania: testerzy alfa / beta projektu mogą w ten sposób komunikować się z zespołem programistycznym.

Te proste rzeczy zapewniają, że projekt nie wymknie się spod kontroli i wszyscy będą pracować na tej samej wersji kodu. Proces integracji continuos pomaga, gdy coś idzie strasznie źle.

Zapobiega również wysyłaniu rzeczy, które nie są kompilowane, do głównego repozytorium.
Jeśli chcesz dołączyć nową funkcję, której wdrożenie zajęłoby kilka dni i uniemożliwiłaby innym osobom budowanie (i testowanie) projektu, użyj funkcji gałęzi kontroli wersji.

Jeśli to nie wystarczy, możesz skonfigurować go również do przeprowadzania testów automatycznych, jeśli jest to możliwe w przypadku danego projektu.

Jeszcze kilka myśli

Na pierwszy rzut oka powyższa lista może być bardzo ciężka. Zalecam stosowanie się do niego w razie potrzeby : zacznij od kontroli wersji i narzędzia do śledzenia błędów, a następnie skonfiguruj serwer ciągłej integracji, jeśli tego potrzebujesz. (Jeśli jest to duży projekt, będziesz go wkrótce potrzebować.) Zacznij pisać testy jednostkowe dla najważniejszych części. Jeśli to nie wystarczy, napisz ich więcej.

Kilka przydatnych linków:
Ciągła integracja , Codzienne kompilacje to Twoi znajomi , Kontrola wersji , Testowanie jednostkowe

Przykłady:

Do kontroli wersji używam obecnie Git do moich osobistych projektów. Subversion jest również popularne i na przykład VisualSVN jest dość łatwy do skonfigurowania, jeśli używasz serwera Windows. Dla klienta TortoiseSVN działa najlepiej dla wielu osób. Oto porównanie między Git i SVN.

W przypadku oprogramowania do śledzenia błędów bardzo popularne są Jira i Bugzilla . Używaliśmy również Mantis w poprzednim miejscu pracy.

W przypadku oprogramowania do ciągłej integracji istnieje Teamcity (również godne uwagi są CruiseControl i jego odpowiednik .NET ).

Odpowiedź na Twoje pytanie „kto decyduje o głównym kształcie projektu?”

Oczywiście byłby to główny programista.
W firmach głównym deweloperem jest osoba, która rozmawia z osobami zajmującymi się finansami / marketingiem projektu i decyduje o strukturze arkusza w zależności od możliwości finansowych firmy, planowanych funkcji, wymagań użytkowników i dostępnego czasu.

Jest to złożone zadanie i zwykle zaangażowanych jest więcej niż jedna osoba. Czasami członkowie zespołu są również proszeni o udział lub przeprowadzenie burzy mózgów na temat projektu całego projektu lub określonych części.

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

Zdecydowanie korzystaj z repozytorium. Każda osoba może uzyskać zdalny dostęp do całego kodu i dodawać / usuwać / zmieniać cokolwiek. Ale najlepsze w Subversion jest to, że jeśli ktoś złamie kod, możesz powrócić do wcześniejszej wersji i ocenić, co poszło nie tak. Jednak komunikacja jest nadal kluczowa, wiedz, co robią twoi koledzy z drużyny, aby nie było konfliktów. Nie siedź też na swoim kodzie, wykonuj szybkie, znaczące zmiany w repozytorium, aby były najbardziej efektywne.

** Polecam również narzędzie do śledzenia błędów, takie jak Redmine. Możesz założyć konta dla wszystkich i przydzielać ludziom zadania z różnymi priorytetami, a także śledzić i sprawdzać, czy ludzie rozwiązali pewne problemy, czy też pojawiło się więcej.

Jak już powiedziano, testy jednostkowe bardzo pomogą. Powodzenia! Mam nadzieję, że to pomogło :-)

Wielkie rzeczy to:

• Plan - jeśli ludzie nie wiedzą, dokąd idą, nigdzie nie pójdą. W związku z tym, aby rozpocząć każdy projekt, potrzeba kilku osób (często siwobrodych), aby zebrać się w rwetes i opracować plan; plan nie musi być bardzo szczegółowy, ale nadal jest wymagany.
• System kontroli wersji - bez tego nie będziecie pracować razem. Potrzebujesz również zdecydowanego zaangażowania, że ​​jeśli coś nie jest popełnione, to się nie liczy. „Och, jest w jednej z moich piaskownic” to tylko kiepska wymówka.
• Tracker problem - nie można śledzić te rzeczy przez foldery wiadomości e-mail. Zdecydowanie powinien być oparty na bazie danych.
• System powiadomień - ludzie muszą wiedzieć, kiedy coś jest związane z kodem, którym zarządzają lub kiedy pojawiają się komentarze dotyczące błędów, za które są odpowiedzialni. E-mail może do tego działać, podobnie jak IRC (oczywiście pod warunkiem, że wszyscy go używają).
• System budowania - tak naprawdę nie ma znaczenia, jak to się stanie, o ile za pomocą jednej akcji można uzyskać pełną kompilację aktualnego stanu rzeczy, zarówno piaskownicy programistycznej, jak i głównego repozytorium. Najlepsza opcja zależy od używanego języka (języków).
• Zestaw testów - zestaw testów pomaga ludziom uniknąć głupich błędów. Musi być równie łatwy do uruchomienia, jak kompilacja (bycie częścią kompilacji jest dobre ). Zauważ, że testy są tylko prymitywnym substytutem poprawności, ale są o wiele lepsze niż nic.

Wreszcie, potrzebujesz chęci do wspólnej pracy nad zrealizowaniem planu. To zbyt często trudna część.

jak programiści pracują razem nad częścią oprogramowania w firmie

Programiści nigdy nie pracują w zespole. Zespoły są do niczego. Dilbert jest zabawny nie dlatego, że jest komiczną postacią jak Goofy. Jest zabawny, ponieważ jest prawdziwy i ludzie rozpoznają sytuacje, w których się znajduje.

Ogólnie rzecz biorąc, dobrą praktyką jest nie sprawdzanie artefaktów kompilacji w repozytorium. Repozytorium będzie zawierało drzewo źródłowe, konfigurację kompilacji itp. - wszystko, co zostało napisane przez człowieka. Inżynierowie oprogramowania pobiorą kopię swojego kodu na lokalny system plików i zbudują ją lokalnie.

Dobrą praktyką jest również przeprowadzanie testów jednostkowych, które są uruchamiane jako część procesu kompilacji. W ten sposób programista będzie wiedział natychmiast, czy jego zmiany unieważniły którykolwiek z testów jednostkowych i będzie miał możliwość ich naprawienia przed sprawdzeniem wprowadzonych zmian.

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

Nie ma standardu dla rzeczy, o które pytasz. Są raczej konwencje, które w dużym stopniu zależą od wielkości i dojrzałości organizacji. Jeśli jesteś w małej organizacji, powiedzmy kilku programistów, prawdopodobnie sytuacja będzie nieco nieformalna, gdy indywidualni programiści zajmują się kodowaniem, kompilacją i testowaniem.

W większych organizacjach może istnieć dedykowany inżynier kompilacji i proces. Tego rodzaju organizacje zazwyczaj regularnie wykonują formalną kompilację, powiedzmy raz dziennie, przy użyciu dowolnego kodu źródłowego, który został zarejestrowany. Proces ten zwykle obejmuje również BVT (Build Validation Tests) i być może niektóre testy regresji. Programiści pobiorą kod z repozytorium, popracują nad własnym fragmentem lokalnie, a następnie go sprawdzą.

W największych organizacjach, takich jak Microsoft czy Google, będą mieli całkowicie dedykowaną grupę i pełne laboratorium, które będą budować w sposób mniej lub bardziej ciągły, udostępniając wyniki każdego przebiegu. Organizacje te mają bardzo formalne procesy i procedury dotyczące tego, co i kiedy jest sprawdzane, jakie są procesy przeglądu kodu itp.

Nie ma książki kucharskiej do pracy z tworzeniem oprogramowania, ale generalnie system kontroli wersji powinien być sercem twojego systemu kompilacji, nawet jeśli pracujesz w projekcie, w którym jesteś jedynym programistą. Nawet w tym przypadku możliwość przywracania wersji i czytania dziennika wersji jest bardzo pożądaną pomocą przy naprawianiu błędów. Nie jest to jedyna cecha systemu kontroli wersji, ale sama w sobie uzasadnia instalację, konfigurację i utrzymanie systemu kontroli wersji.

Kompilację może wykonać każdy programista podczas dodawania nowego kodu lub okresowo przez „serwer kompilacji”. To ostatnie podejście wymaga więcej konfiguracji, ale pomaga szybciej wykryć błędy kompilacji.

Krótka odpowiedź - „To zależy”.

Obecnie sam pracuję nad projektem, więc to ja buduję / używam VCS. Znam inne miejsca, w których masz zespoły pracujące razem nad projektem, przez e-mail z dreszczykiem . Lub duże (+5) zespoły korzystające z VCS.

W związku z tym gorąco polecam opanowanie przynajmniej niektórych VCS, a Joel Spolsky ma świetny samouczek wprowadzający do Mercurial. Bazar (mój osobisty wybór) jest podobny, a następnie Git jest następny pod względem podobieństwa, ale prawdopodobnie bardziej popularny niż jeden z nich (przynajmniej ATM). Potem masz SVN, który jest dość słaby w porównaniu.

Właściwie, Joel mówi o większości twoich pytań - poleciłbym przeczytać 10 lat archiwów, które posiada - wszystkie są bardzo przydatne informacje, a większość z nich dotyczy twojej obecnej i bliskiej przyszłości sytuacji.

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

Przede wszystkim zespoły pracują przy użyciu repozytoriów (które mogą być profesjonalną kontrolą wersji lub po prostu zbiorem katalogów uważanych za „żywe”, chociaż system kontroli wersji jest de facto standardem). Również sposób zarządzania projektem zależy od tego, jak pracujesz (kaskada, zwinność itp.). Jeśli pracujesz w iteracjach, tworzysz komponenty / wtyczki / moduły / biblioteki, które są samowystarczalne, i wykonujesz testy jednostkowe, dopóki nie zostaną zatwierdzone jako zakończone. Jako zespół pracujesz w zespole, co oznacza, że ​​nie pracujesz nad całym projektem wszędzie w tym samym czasie. Zamiast tego otrzymujesz zadanie do wykonania w sferze projektu. Czasami musisz naprawić kod, który nie jest twój, ale zwykle pojawia się, gdy pojawia się dziwne zachowanie. Zasadniczo testujesz opracowane przez siebie części.

Pozwól, że ci to wyjaśnię. Jesteś w zespole pracowników budowlanych. Architekt przychodzi z planem budynku, brygadzista sprawdza, jakie są potrzeby do budowy, a następnie zatrudnia konstruktorów. Murarz robi ściany, sprawdza je pod kątem wytrzymałości i ładnie skleja. Elektryk wykonuje całe okablowanie wewnątrz budynku, aby umożliwić przepływ prądu. Każdy mężczyzna ma swoją pracę. Czasami elektryk może chcieć porozmawiać z murarzem, czy można wyrzeźbić określone ściany, ale zawsze w porozumieniu z brygadzistą.

Mam nadzieję, że to dla Ciebie pomoc!

Zazwyczaj system kontroli wersji zawiera kod źródłowy i zwykle nie ma plików binarnych. Jeśli chcesz go zbudować i uruchomić, sprawdź kod i zbuduj go na komputerze lokalnym.

W niektórych miejscach są uruchamiane nocne kompilacje, aby upewnić się, że wszystko działa. Mogą nawet istnieć testy automatyczne uruchamiane po stronie serwera. Jeśli kompilacja lub cokolwiek innego się nie powiedzie, ktoś jest powiadamiany automatycznie.

Dobrym wprowadzeniem do metody korzystania z kontroli źródła jest Source Control HOWTO Erica Sinka http://www.ericsink.com/scm/source_control.html

W swoich przykładach używa SourceGear Vault, odkąd go napisał, i tak dalej, ale metody te można zastosować w innych systemach kontroli wersji.

To kolejny dobry powód, dla którego warto przyjrzeć się projektom Open Source.

Główni programiści pracujący w dużych projektach OpenSource (takich jak Chromium, Mozilla Firefox, MySQL, Popular Gnu Software) to profesjonaliści. Mają duże doświadczenie, a projekty te ewoluowały przez lata dzięki pomysłom setek takich profesjonalistów.

Wszystko, o czym inni wspomnieli w ich odpowiedziach (plan, system kontroli wersji, śledzenie problemów, system powiadomień, system kompilacji, zestaw testów) można znaleźć w tych projektach OpenSource.

Jeśli naprawdę chcesz zdobyć praktyczne doświadczenie, zdecydowanie sugeruję, abyś przejrzał kilka popularnych i dużych projektów OpenSource, a następnie pobierz źródło z dowolnego projektu (używając kontroli wersji) i zbuduj je samodzielnie.

PS: Jestem również studentem i zaangażowanie w projekty OpenSource to najlepsza rzecz, jaką kiedykolwiek zrobiłem. Zaufaj mi! Ty też poczujesz to samo.