www.elektronik.si Seznam forumov www.elektronik.si
Forum o elektrotehniki in računalništvu
 
 PomočPomoč  IščiIšči  Seznam članovSeznam članov  SkupineSkupine  StatisticsStatistika  AlbumAlbum  DatotekeFilemanager DokumentacijaDocDB LinksPovezave   Registriraj seRegistriraj se 
  PravilaPravila  LinksBolha  PriponkePriponke  KoledarKoledar  ZapiskiZapiski Tvoj profilTvoj profil Prijava za pregled zasebnih sporočilPrijava za pregled zasebnih sporočil PrijavaPrijava 

Multi developer project

 
Objavi novo temo   Odgovori na to temo   Printer-friendly version    www.elektronik.si Seznam forumov -> Programiranje embedded sistemov
Poglej prejšnjo temo :: Poglej naslednjo temo  
Avtor Sporočilo
Auslander
Član
Član



Pridružen-a: Tor 08 Mar 2005 9:53
Prispevkov: 43
Aktiv.: 0.19

PrispevekObjavljeno: Sre Okt 23, 2013 12:27 am    Naslov sporočila:  Multi developer project Odgovori s citatom

Zanima me če se je že kdo izmed vas srečal z multi developer projekti?

Do sedaj smo na šihtu imeli prakso, en razvijalec (FW) na projekt. Ker so naši generali končno doumeli, da ena oseba ne more več obladovati 500.000+ vrstic kode. so si zastavili cilj, da bo več ljudi delalo na enem projektu, sanja pa se jim ne kako.

Zanima me, kako projekt zastaviti? Da vsi lahko "čačkajo" (popravljajo drug drugemu) po celotni kodi projekta ali raje ločiti, tako da vsak naredi svoj object file, ki se ga nato zlinka skupaj?

se posamezniku določi "memory map", od te od te addrese sme pisati po flashu ramu naprej pa ne...

kako je z interrupti? upravlja ena oseba z njimi alil lahko kdor koli?

kakršen koli hint bi bil dobrodošel.
Nazaj na vrh
Odsoten Poglej uporabnikov profil Pošlji zasebno sporočilo
bpavsic
Član
Član



Pridružen-a: Pet 03 Apr 2009 20:45
Prispevkov: 354
Aktiv.: 1.94
Kraj: Maribor

PrispevekObjavljeno: Sre Okt 23, 2013 7:41 am    Naslov sporočila:   Odgovori s citatom

Nekdo mora bit odgovoren za celoten projekt in tudi imeti pregled nad vsem.
Ta nekdo tudi razdeli projekt na posamezne (bolj abstraktne) dele (black box), pri čemer mora poznati zahteve posameznega dela (koliko in katere lokacije pomnilnika, če/katere interrupte itd..), kako se ti deli obnašajo v celoti.
Nato pa te posamezne dele (module) razdeli med ostale, ki dejansko delajo na FW. Če nekdo, ki programira, ugotovi, da potrebuje kaj več, o zahtevah obvesti tega "nadzornega" in skupaj potem ugotovita, kako naprej.
V glavnem, nekdo mora imet pregled nad vsem (to pa ne pomeni, da mora obvladat vseh 500k vrstic dejanske kode).
Če ni nikogar, ki bi zadevo poznal v celoti, potem se naj naredi sestanek (oz. več sestankov) z vsemi, ki bodo delali na FW, kjer vsak poda svoje zahteve za svoj del in se potem skupaj doreče, kako bo vse delovalo (več glav več ve) in se potem tudi zastavi dokumentacija za celoten projekt.
Nazaj na vrh
Odsoten Poglej uporabnikov profil Pošlji zasebno sporočilo
.
Neznanec
Neznanec



Pridružen-a: Pet 01 Okt 2004 1:17
Prispevkov: 1
Aktiv.: 0.00

PrispevekObjavljeno: Sre Okt 23, 2013 10:32 am    Naslov sporočila:   Odgovori s citatom

Brisana vsebina odstranjenega uporabnika.
Nazaj na vrh
Odsoten Poglej uporabnikov profil Pošlji zasebno sporočilo
Auslander
Član
Član



Pridružen-a: Tor 08 Mar 2005 9:53
Prispevkov: 43
Aktiv.: 0.19

PrispevekObjavljeno: Sre Okt 23, 2013 10:00 pm    Naslov sporočila:   Odgovori s citatom

Brez source controla, si že sedaj ne predstavljam dela, čeprav je meni najljubši GIT.

če pa gledam open source projekte kjer tudi več ljudi dela na enem projektu, vedno nekdo postavi neko "okostje" na katerem razvijajo napej. ponavadi imajo vsi dostop do vsega. popravke in dopolnitve nato običajno z merga avtor projekta.
Ta irativni pristop je preverjen, vendar ni primeren v profesionalnem okolju ker je dolgotrajen. poleg tega avtor ni razbremenjen saj mora pazljivo spremljati spremembam. v embedded okolju pa še toliko bolj, ker napake niso dopustne.

neke literature pa tudi nisem zasledil s praktičnim tehničnim primerom nekega projekta. vedno nekako opisno na splošno nič konkretnega. rad bi videl pristop nekega uspešno zaključenega projekta.
Nazaj na vrh
Odsoten Poglej uporabnikov profil Pošlji zasebno sporočilo
.
Neznanec
Neznanec



Pridružen-a: Pet 01 Okt 2004 1:17
Prispevkov: 1
Aktiv.: 0.00

PrispevekObjavljeno: Čet Okt 24, 2013 12:19 am    Naslov sporočila:   Odgovori s citatom

Brisana vsebina odstranjenega uporabnika.
Nazaj na vrh
Odsoten Poglej uporabnikov profil Pošlji zasebno sporočilo
Andrjuha
Član
Član



Pridružen-a: Sob 05 Okt 2013 9:49
Prispevkov: 23
Aktiv.: 0.18
Kraj: Ljubljana

PrispevekObjavljeno: Čet Okt 24, 2013 3:29 pm    Naslov sporočila:   Odgovori s citatom

Prva stvar je source control, druga stvar pa project managment sistem, npr. Redmine, trac, karkoli. Brez teh dveh ne gre. Ščasoma boste uvedli tudi stil kodiranja, ki vam najbolj ustreza in se ga držali. Dalje potrebuješ nekoga, ki projekt administrira in skrbi za pravičasno izvajanje taskov in reševanje težav - vodja projekta. Tipično rabiš še tehničnega vodjo. Le ta pregleda vsak commit v source control in manj izkušene razvijalce sproti opominja. Oboje je lahko združeno v eni osebi. S permissioni kontrole ne moreš efektivno vzpostavit, ampak je disciplina edini način. Dobra stvar je tudi vzajemni code review, to pomeni, da ima vsak razvijalec par s katerim si konec dneva pregledata kodo. S tem se poveča kvaliteta kode, uveljavlja stil kodiranja in preprečuje bluzenje. Kultura teama se gradi leta in to se ne da z danes na jutri ....
_________________
lp, Andrej
Nazaj na vrh
Odsoten Poglej uporabnikov profil Pošlji zasebno sporočilo
.
Neznanec
Neznanec



Pridružen-a: Pet 01 Okt 2004 1:17
Prispevkov: 1
Aktiv.: 0.00

PrispevekObjavljeno: Čet Okt 24, 2013 4:47 pm    Naslov sporočila:   Odgovori s citatom

Brisana vsebina odstranjenega uporabnika.
Nazaj na vrh
Odsoten Poglej uporabnikov profil Pošlji zasebno sporočilo
Auslander
Član
Član



Pridružen-a: Tor 08 Mar 2005 9:53
Prispevkov: 43
Aktiv.: 0.19

PrispevekObjavljeno: Sre Nov 06, 2013 11:54 pm    Naslov sporočila:   Odgovori s citatom

Razumem, da je vsak projekt specifičen vendar moje mnenje je da brez sistematizacije ne gre! po občutku dvomim, da lahko kdo pripelje do konca srednje težaven projekt.

project manegment, je povsem druga stvar ki me trenutno zanima, ne zanimajo me terminski plani in stroški; zanima me predvsem tehnična izvedba, kako izvesti s čim manj popravki, da bo zadeva delovala v skladu s pričakovanji. Da se komponente zlagalajo kot lego kocke, in prav tu rado se tukaj zatakne. Znan mi je primer, iz gradnje luksuzne križarke, ko je podizvajalec naredil kabine, katere pa so imele odtočne cevi na napačnih mestih....

Vem, da je na koncu človek, ki razume celoto vsaj v grobem - v celoti jo ne more; če se izrazim po gradbeniško: kadar se gradi nebotičnik je glavni projektant, ki ve kakšne bodo statične termične, obremenitve, protipotresnost itd... nikakor pa ne ve in ne more vedeti podrobnosti kot so kakšna bo mešanica betona, s kakšnim granulatom peska, s kakšno debelino železnih palic...

kultura teama, je zopet izven mojega dosega; se strinjam, da je pomemben dejavnik za uspešno izvedbo projektov. Ni mi povsem jasno, tehnični vodja naj bi pregledal vsak commit? pa saj bi že po enem tednu pristal v ustrezni ustanovi Razz in ce res nekdo pregleda vsak commit, detajlno potem pa res nima smisla, da več ljudi dela na projektu.

zanima me če vam dam kar konkreten primer, kako bi se ga lotili:
- želja je narediti regulacijo temperature bojlerja.
če razdelimo delo po osebah, ki razvijajo vzporedno:
1. oseba: zajemanje vzorcev temperaturnih in drugih senzorjev (pretoka, nivoja)
2. oseba: gradi regulacijski alguritem
3. oseba: skrbi za krmiljenje ventilov (tople, hladne vode)
4. oseba: skrbi za uporabniški vmesnik (nastavljanje parametrov, časovne intervale, temperature, branje tipk...)
5. oseba: komunikacijski protokol, za komunikacijo z ostalimi napravami.

če izpostavim enega izmed problemov, ki je povsem realen:
1. oseba sama zase, naredi zadevo, ki "deluje" tudi oseba 4. naredi svoj posel; ko združimo delo obeh pa se zatakne;
- zaradi branja tipk (če so vezane na adc), pokvari 1. osebi vzorčevalni korak zajemanja vzorcev, ali ga vsaj zmoti v določenih primerih.
- ali pa 4. oseba ne pride na vrsto v doglednem času, zaradi tega tipke prijemajo z zakasnitvijo kar je vsaj moteče.
- če bi oboje počela ena oseba, bi bila težava hitro rešena, tako pa se težava pokaže mnogo kasneje kot bi se sicer.

kako take in podobne probleme preprečiti?
pa, da nekdo po nesreči ne reverta tudi popravke druge osebe.
koliko "svobode" dati posamezniku, ali se mora omejiti z ramom, flashom, časom?
kakšna je vaša praksa?
Nazaj na vrh
Odsoten Poglej uporabnikov profil Pošlji zasebno sporočilo
GJ
Član
Član



Pridružen-a: Čet 02 Nov 2006 15:51
Prispevkov: 946
Aktiv.: 4.47
Kraj: Ljubljana

PrispevekObjavljeno: Čet Nov 07, 2013 12:40 am    Naslov sporočila:   Odgovori s citatom

Auslander je napisal/a:
Razumem, da je vsak projekt specifičen vendar moje mnenje je da brez sistematizacije ne gre! po občutku dvomim, da lahko kdo pripelje do konca srednje težaven projekt.

project manegment, je povsem druga stvar ki me trenutno zanima, ne zanimajo me terminski plani in stroški; zanima me predvsem tehnična izvedba, kako izvesti s čim manj popravki, da bo zadeva delovala v skladu s pričakovanji. Da se komponente zlagalajo kot lego kocke, in prav tu rado se tukaj zatakne. Znan mi je primer, iz gradnje luksuzne križarke, ko je podizvajalec naredil kabine, katere pa so imele odtočne cevi na napačnih mestih....

Vem, da je na koncu človek, ki razume celoto vsaj v grobem - v celoti jo ne more; če se izrazim po gradbeniško: kadar se gradi nebotičnik je glavni projektant, ki ve kakšne bodo statične termične, obremenitve, protipotresnost itd... nikakor pa ne ve in ne more vedeti podrobnosti kot so kakšna bo mešanica betona, s kakšnim granulatom peska, s kakšno debelino železnih palic...

kultura teama, je zopet izven mojega dosega; se strinjam, da je pomemben dejavnik za uspešno izvedbo projektov. Ni mi povsem jasno, tehnični vodja naj bi pregledal vsak commit? pa saj bi že po enem tednu pristal v ustrezni ustanovi Razz in ce res nekdo pregleda vsak commit, detajlno potem pa res nima smisla, da več ljudi dela na projektu.

zanima me če vam dam kar konkreten primer, kako bi se ga lotili:
- želja je narediti regulacijo temperature bojlerja.
če razdelimo delo po osebah, ki razvijajo vzporedno:
1. oseba: zajemanje vzorcev temperaturnih in drugih senzorjev (pretoka, nivoja)
2. oseba: gradi regulacijski alguritem
3. oseba: skrbi za krmiljenje ventilov (tople, hladne vode)
4. oseba: skrbi za uporabniški vmesnik (nastavljanje parametrov, časovne intervale, temperature, branje tipk...)
5. oseba: komunikacijski protokol, za komunikacijo z ostalimi napravami.

če izpostavim enega izmed problemov, ki je povsem realen:
1. oseba sama zase, naredi zadevo, ki "deluje" tudi oseba 4. naredi svoj posel; ko združimo delo obeh pa se zatakne;
- zaradi branja tipk (če so vezane na adc), pokvari 1. osebi vzorčevalni korak zajemanja vzorcev, ali ga vsaj zmoti v določenih primerih.
- ali pa 4. oseba ne pride na vrsto v doglednem času, zaradi tega tipke prijemajo z zakasnitvijo kar je vsaj moteče.
- če bi oboje počela ena oseba, bi bila težava hitro rešena, tako pa se težava pokaže mnogo kasneje kot bi se sicer.


...

Auslander je napisal/a:
kako take in podobne probleme preprečiti?


Če ne veste kaj želite si najemite si profesionalca, on bo iz vas izvlekel kaj sploh želite in ocenil, če se splača delati za vas... Cool


LP Mr. Green GJ
Nazaj na vrh
Odsoten Poglej uporabnikov profil Pošlji zasebno sporočilo
marko
Član
Član



Pridružen-a: Sre 07 Jan 2004 15:14
Prispevkov: 755
Aktiv.: 3.40

PrispevekObjavljeno: Čet Nov 07, 2013 1:14 am    Naslov sporočila:   Odgovori s citatom

Vedno potrebuješ glavnega developerja, torej nekoga, ki nadzira in izvaja glavno zanko programa. Lahko je to oseba, ki seveda razvija tudi kak drug modul.
Ta oseba vključuje posamezne module (funkcije) v to zanko in testira tudi hitrost delovanja posameznega sklopa, ter ve točno kaj mora program narediti in kaj vsaka od teh funkcij dela. Kako točno deluje posamezna funkcija, zanj ni pomembno. Pomembno je, da so v naprej definirani (najbolje, da kar na skupnem sestanku) vhodni in izhodni parametri, ter specifike samega delovanja (npr. zahtevana hitrost vračanja, na kaj vse lahko vpliva, kritične prostorske zahteve itd). Vsaj minimalne zahteve se morajo definirati pred startom projekta, takrat se tudi dodeli ljudi na projektu kaj bo kdo počel.

Treba se je dogovoriti, da se glavnega programa ne dotika nihče, ampak vse deluje preko eksternih datotek. Jaz npr. skrbim za regulacijo ventilov in imam zato svoj folder znotraj projekta npr. ventili, kjer imam svoje datoteke. Te datoteke poljubno spreminjam in testiram. Ko svoje datoteke popravljam, seveda commitam vse popravke. Za razvoj in testiranje svojega modula lahko uporabim glavno zanko programa (in je ne commitam, če jo slučajno spreminjam), ali pa (še bolje), si naredim svoj testni klic, kjer lahko na hitro testiram samo moj modul. Ta testni program seveda ne dajam v skupni repozitorij, ker drugih ne zanima in ga imam lokalno na svojem računalniku. Če gre za bolj kompleksen test in bi bila izguba programa težava (v primeru, da odpove disk), seveda vseeno daš v repozitorij, pod imenom ventili-test ali pa kaj podobnega, da se hitro vidi, da je nek test.
Vsak programer ima pri sebi lokalno popolnoma delujočo (updejtano) verzijo programa, popravlja pa samo svoje.

Veljati mora pravilo, da se nedokončanih, netestiranih stvari v projekt ne commita, ker lahko hitro uničiš delujoč projekt ostalim razvijalcem ali povzročiš druge težave. Najbolj enostavno je, da oceniš, ali morajo ostali programerji updejtat tvoje popravke ali ne. Ko nekaj commitaš, poveš ostalim, da si updejtajo projekt.

Zadeva se malo bolj zakomplicira, ko v razvoju razvijaš verzijo 2.0 tega programa ali pa kak dodaten feature, ki še ni razvit/stestiran do konca in je 2.0 še daleč do končnega produkta, ko se pojavi bug v V1.0, ki ga moraš "na hitro" popravit. Če si za potrebe 2.0 popravil že 100 ostalih datotek imaš velik problem. Zato se ob lansiranju produkta ali pa neki končani fazi, kreira svoj branch (vsak revision system to poimenuje drugače, v principu so pa vsi isti), ki naredi kopijo datotek in na katere lahko enostavno preklopiš, če moraš kaj popravit. Ko bug odpraviš, narediš nov branch 1.1 in preklopiš nazaj na glavni (development) branch. Če je bug tudi v 2.0, enostavno mergaš datoteke med dvema branchoma (1.1 in 2.0) in imaš odpravljen bug tudi v 2.0.

Je pa pomembno, da se definira politiko programiranja, kot je povedal Kroko. Imena modulov, komentarji, način poimenovanja spremenljivk, poimenovanje funkcij, ide nastavitve (npr. tab/space itd). Če ne bo na koncu totalna zmešnjava, ki je nihče ne bo več sestavil nazaj. Mene osebno zelo moti, če ljudje pišejo funkcije in spremenljivke vsakič drugače (običajno je tako, če ni neke striktne politike). Primer: ena funkcija je ad7997_init(), drugič je set_ad7997_parameters() in potem še ResetAd7997() in podobne. Jaz kar pege dobim Smile Običajno trije programerji, furajo tri različne stile. Žal pa je ego programerjev kar velik hudič v okolju, kjer jih več dela, zato mora to določit nekdo, ki ima avtoriteto in ima še toliko dodatne volje, da tja pa sem, tudi nadzira malo drugo kodo in pokomentira in doseže, da je koda konsistentna in lahko eventuelno za nekom drug prevzame del.

Še to:
Ko govorim o commitu, govorimo o kateremkoli revision sistemu in shranjevanju v ta sistem, pri updejtu pa nalaganje iz njega in merganje sprememb. To ti programi delajo samodejno in običajno ni težav.
Pri nas uporabljamo CVS, ki je sicer star kot sama zemlja, ampak se zaenkrat dobro obnese. To sem pred leti začel postopoma uvajati z veliko muko in smo sedaj končno že nekaj let uspešno na tem. Ima seveda svoje pomanjklivosti, ampak ne vidim kako bi lahko enostavno migriral 300+ projektov na kaj drugega Smile
Nazaj na vrh
Odsoten Poglej uporabnikov profil Pošlji zasebno sporočilo
Pokaži sporočila:   
Objavi novo temo   Odgovori na to temo   Printer-friendly version    www.elektronik.si Seznam forumov -> Programiranje embedded sistemov Časovni pas GMT + 2 uri, srednjeevropski - poletni čas
Stran 1 od 1

 
Pojdi na:  
Ne, ne moreš dodajati novih tem v tem forumu
Ne, ne moreš odgovarjati na teme v tem forumu
Ne, ne moreš urejati svojih prispevkov v tem forumu
Ne, ne moreš brisati svojih prispevkov v tem forumu
Ne ne moreš glasovati v anketi v tem forumu
Ne, ne moreš pripeti datotek v tem forumu
Ne, ne moreš povleči datotek v tem forumu

Uptime: 47 dni


Powered by phpBB © 2001, 2005 phpBB Group