Verktøy og metoder for å samarbeide om utviklingsprosjekter?

[nomore]

Hei,

 

Tidligere har eg stort sett jobbet på egen hånd med utviklingsprosjekter. Men i det siste har eg begynt å jobbe med andre og da lurer eg litt på hvordan dere andre jobber sammen med andre og hvilke verktøy dere bruker?

 

Jobber stort sett med PHP, MySQL/PostgreeSQL og Apache på Windows og Linux plattform. Eg bruker personlig Programmers Notepad eller vi som teksteditor. Og så prøver eg å pushe frem SVN som versjonshåndteringssystem.

 

Dokumenterer dere? Hvilke utkast lager dere? Osv. Mange spørsmål

Alle bidrag settes pris på.

[asicman]

Og så prøver eg å pushe frem SVN som versjonshåndteringssystem.

 

Personlig foretrekker jeg GIT framfor SVN. Mye bedre med distribuert RCS enn sentralisert samt at GIT er mye raskere, spesielt til brancher og cloning. Windows support for GIT ligger litt etter. Selv ser jeg aldri selve git kommandoene (selv om jeg kan bruke de om jeg vil) siden jeg bruker Egg (GIT overbbygg) i Emacs.

 

Andre foretrekker Darcs, Mercurial eller Bazaar framfor SVN.

[nomore]

Nå liker eg tanken på et sentralt repository samt at SVN har flere klienter(for tiden i det minste). Om eg kommer opp i et prosjekt med noen som bruker git så er det for meg en god grunn til å teste, men for tiden er det SVN eg kan best

[duckers]

Er ikke det litt feil innstilling i en tråd der du spør om tips til verktøy?

 

Har ingen personlig erfaring med Git, men benyttet tidligere SVN og var storfornøyd med det. Som den flittige studenten jeg er tenkte jeg imidlerti at en fremtidig arbeidsgiver forhåpentligvis er kommet over SVN og jobber distribuert. Jeg begynte derfor å se på Mercurial, og kan ikke tenke meg å gå tilbake.

 

Angående dokumentering kan jeg vel bare si at skikkelige mannfolk ikke leser manualen, og dermed ikke trenger å skrive den! (Les: har ingen erfaring, men har hørt at det er lurt.) Personlig prøver jeg å være flink med kommentarer. Jeg har en stor kommentar i begynnelsen av hver klasse som kort beskriver klassen, offentlige metoder og dependencies.

[asicman]

Er ikke det litt feil innstilling i en tråd der du spør om tips til verktøy?

 

Jeg er enig her. Var jeg deg ville jeg lære meg litt om GIT før du tok en avgjørelse.

 

Du kan også sette opp GIT som en sentral server (se f.eks. gitorious og github). Du kan også bruke GIT som en front-end i mot SVN. Jeg selv jobber i mot et SVN repos til daglig, men jeg gjør det i fra GIT.

 

Med et distribuert RCS som GIT kan du klone treet og deretter jobbe videre på denne klonen sammen med enkelte fra teamet ditt. Dere kan slå mange commits i sammen til en (squash) og deretter pushe det opp til reposet som resten av teamet jobber med. I GIT committer man ofte.

 

Videre så er GIT mye raskere enn SVN. Første gang jeg gjorde en git clone trodde jeg noe hadde gått feil siden det tok så kort tid.

 

Det føles som sirup å jobbe i mot SVN etter at man har brukt GIT. Det å lage en branch og sjekke ut en branch i GIT tar meget kort tid.

 

GIT er skrevet av Linus Torvalds og brukes til kildekoden til Linux kjernen. Det er mange egenskape som har med å sende inn patcher via e-post osv. i GIT som jeg aldri har hatt bruk for. Men etter å ha brukt GIT en stund så forstår jeg neste ikke hvordan jeg holdt ut med SVN.

 

Men jeg holder meg så langt jeg kan unna Windows. Å kjøre GIT i cygwin går mye tregere. Jeg vet ikke hvor langt Tortoise-GIT osv. har kommet med full GIT støtte.

[GeirGrusom]

Selv liker jeg godt Mercurial med TortoiseHg og VisualHg.

[siDDis]

SVN er gammaldags, GIT, Bazaar eller Mercurial er dagens versjonskontrollsystemer som ein bør bruke. Eg bruker GIT, men sitter du på Windows så er vell dei to andre eit betre alternativ.

 

For oppgåvefordeling så er Trac eit greit verktøy, JIRA er best, men er eit kommersielt alternativ.

 

Gobby er greit om ein skal programmere i same dokument eller ha code review på telefonen.

 

Av teksteditorer så er det eit fett kva som blir brukt, foretrekker vim/komodo-edit/netbeans. Men ein ting som me her i gjengen har som standard er at alle "indents" er mellomrom og ikkje tab. Om lengda er 2,4,8 er ikkje så farleg.

[duckers]

Men ein ting som me her i gjengen har som standard er at alle "indents" er mellomrom og ikkje tab. Om lengda er 2,4,8 er ikkje så farleg.

 

Vet dette er en diskusjon på høyde med Vi vs. Emacs, men er det ikke forferdelig rotete dersom en skriver med to spaces og en annen med 8? Trodde det universelle svaret var "samma f... hva du bruker så lenge alle på teamet gjør det samme."

 

Og når dere først benytter ulike lengder, er det noen god grunn til å forby tab?

 

(Hilsen en som benytter tab til det den ble laget til )

[GeirGrusom]

Jeg bruker også tab, og irriterer meg hver gang jeg er borti dokumenter som bruker mellomrom.

Det hadde vært gøy å høre en god grunn til å bruke space fremfor tab.

[siDDis]

Fordi forskjellige teksteditorer håndterer tabbing forskjelligt, det blir surr uansett, spaces derimot fungerer alltid med forskjellige teksteditorer og det er derfor mellomrom til indenting er det som er anbefalt for alle Python utviklere.

[GeirGrusom]

Fordelen med tab er at det er opp til teksteditoren å bestemme hvor bredt en tab skal se ut, og backspace vil alltid kun fjerne en indent, og ikke et mellomrom.

[nomore]

Er ikke det litt feil innstilling i en tråd der du spør om tips til verktøy?

Jo, eg er enig i at det er feil innstilling, og legger meg flat der

 

Eg har ikke testet GIT i praksis, men før eg bestemte meg for hvilket versjonshåndteringssystem eg ville ha så leste eg flere artikler, manualer og annen informasjon rundt GIT, svn, cvs og andre lignende system. Ut i fra det eg leste da konkluderte eg med at SVN var det rette å gå for på det tidspunktet, men GIT var, og er, en veldig sterk kandidat fortsatt. Mest av alt ble det ikke valgt pga manglende Windows-klient.

 

Personlig utvikler eg ikke på Windows-plattformen med mindre det er snakk om patching av VB6-kode(grøss), eller .Net-prosjekter. Det meste går på linux servere, fysiske eller virtuelle, med dedikerte webhotell til de forskjellige prosjektene. Men når eg velger ut verktøy/programmer/løsninger så prøver eg å legge vekt på at de skal støtte flere plattformer, og i størst mulig grad være åpen kildekode. Et samarbeid blir fort litt amputert om verktøyene eg bruker kun fungerer på linux, og en i gruppen bruker utelukkende Mac. Det prøver eg å unngå

 

Men for å beskrive litt hvordan eg har jobbet frem til nå. Det første som gjøres i prosjekter, spesielt nettbaserte, er å strukturere en database så den er 90% ferdig. Om eg samarbeider med noen så tar vi en dialog over MSN/telefon mens vi deler en eller flere skjermer så alle ser hva som blir gjort. Det blir ikke dokumentert eller notert noe av dialogen som foregår, kun det endelige produktet. Her bruker eg stort sett MySQL Workbench så relasjoner kan vises grafisk. Når databasestrukturen så er klar så oppretter eg et prosjekt på SVN-serveren og sørger for at alle som trenger det har tilgang. Deretter lager eg et webhotell med en database for å vise resultatet så langt, i tillegg til et webhotell og en database til hver enkelt deltaker. På den måten kan vi alle jobbe med hver vår del av prosjektet, uavhengig av de andre. Så tar vi regelmessige sammenslåinger av koden fortløpende. Om vi trenger å gjøre endringer på databasemodellen så gjør vi dette i fellesskap. Så langt er det minimalt som blir dokumentert eller notert bortsett fra enkelte kommentarer i kildekoden og kommentarer til endringer i SVN.

 

Fremover lurer eg litt på om eg skal prøve å ta i bruk Microsoft Live Meeting til "møter". Vi bruker dette på jobb og da vi har vært nødt til å kjøpe flere lisenser enn nødvendig så får eg disponere en bruker her til private formål. Løsningen støtter da deling av skjerm, tegning, deling av dokumenter, filer, presentasjoner, video, lyd og opptak av alt som foregår. Ulempen her er at løsningen stort sett kun fungerer på Windows. Den har og støtte for java, men da kun visning av skjerm/presentasjoner.

 

Andre tips/forslag? Hva med notater? Noen som noterer på noen spesiell måte? Lurer litt på om det hadde vært praktisk å opprette en wikipedia-løsning hvor prosjektene blir dokumentert og notater lagret. Fordelen er da at alle kan notere uavhengig av hverandre, eller i felleskap.

[Johan]

Hvis dere ikke lager noen form for design-dokument så kommer dette garantert til å bite dere i ræva siden. Dere burde vurdere å ikke lage f-spec for mesteparten av koden som lages, dette er heller ikke store jobben. Muntlige uformelle avtaler er ikke spesifikke nok, og før eller siden kommer dere til å sitte med kode som ikke passer sammen.

 

Ha ting som som kodestandarder som tabs/spaces avklart på forhånd. Lag retningslinjer for hvordan builden skal kjøres mtp statiske og dynamiske datafiler, artifacts osv. Ha en bugtracker!

 

For samarbeidet generelt kan det være greit å bruke Scrum eller annen metodikk, finnes drøss av sider til dette på nettet. Selv om man ikke bruker metodikken helt ut får man oppgavefordeling og slikt på et sentralt sted. IM holder ikke til dette.

[nomore]

Takk for tipset om scrum. Skal se nærmere på denne(og lignende arbeidsmetodikk).

 

Å sette opp funksjonskrav og en generell applikasjonsflyt ser eg er fordelen i. Tips til verktøy for dette? Ser fortsatt for meg en wikipedia-løsning eller evnt Google Docs.

[Johan]

Noe av dette kan kobles direkte inn i de fleste Scrum-sider, ellers er google-docs veldig praktisk og funker på alle platformer. Det å ha en prosjekt-wiki er alltid lurt, men pass på at man er disiplinert med spesifikasjonene, disse skal jo helst ikke endres helt uten videre, og ihvertfall ikke uten at alle er klar over dette.

[asicman]

Fordelen med tab er at det er opp til teksteditoren å bestemme hvor bredt en tab skal se ut, og backspace vil alltid kun fjerne en indent, og ikke et mellomrom.

 

 

Ormebol Mange editorer håndterer tab forskjellig. Mange editorer vil legge inn riktig antall space når man taster tab og fjerne en indent (selv om den består av blanke i filen) når man trykker backspace.

 

Hvis man bruker tab til indentering kan det gå an. Men bruker man tab til aligning av kode blir det ofte feil. Her er et eksempel fra Linux kildekoden hvor det er brukt 8 space indentering for tab som forfatteren av koden bruker:

 

 

Slik ser det ut hos noen som bruker 4 space tab:

 

 

Eller med to:

 

 

Selv tilhører jeg space og monospace-font religionen.

[asicman]

Det å ha en prosjekt-wiki er alltid lurt, men pass på at man er disiplinert med spesifikasjonene, disse skal jo helst ikke endres helt uten videre, og ihvertfall ikke uten at alle er klar over dette.

 

 

Jeg foretrekker også å ha dokumentasjon under revisjonskontroll. Jeg liker LaTeX framfor Word osv. siden det er enklere med revisjonskontroll på ASCII filer. Da er alle klar over evt. endringer.

 

Videre så er jeg enig med de som nevner videokonferanser og en form for content-sharing når man har møter på video.

 

Regresjonstesting er veldig viktig når mange jobber på samme kode på forskjellige steder. Det er viktig å kunne verifisere at man ikke har ødelagt noe før man gjør en commit.

[siDDis]

For videomøter så er dimdim eit flott alternativ

[nomore]

Ja fant dimdim i går, og det såg jo veldig bra ut. Må sjekkes ut

[Sokkalf™]

Når det gjelder indentering av kode, så er jo "indent"-programmet man ofte finner på linux/unix finfint, men dette funker ikke så bra på andre språk enn C.