Forum » Programiranje » Kakšni so predpogoji, preden začnete pisati programsko kodo?
Kakšni so predpogoji, preden začnete pisati programsko kodo?
shadeX ::
Kakšnih "tehnik" se vi poslužujete preden začnete pisat kodo v IDE? Si naredite vizualno presentacijo objektov in njihovih povezav(UML)? Spišete samo psuedo kodo? Kaj drugega?
Kakšni koraki so obvezni (če sploh), v podjetju v katerem delate preden začnete delati na projektu?
Pisanje kode mi načeloma ne dela problemov, ampak opažam da imam malo izkušenj na "software designu" in to področje bi rad izboljšal. Vedno ko razmišljam in rešujem problem se mi zgodi, da je to bolj problem dizajna kot pa dejansko tehnični problem.
Prosim za nasvete, hvala.
Kakšni koraki so obvezni (če sploh), v podjetju v katerem delate preden začnete delati na projektu?
Pisanje kode mi načeloma ne dela problemov, ampak opažam da imam malo izkušenj na "software designu" in to področje bi rad izboljšal. Vedno ko razmišljam in rešujem problem se mi zgodi, da je to bolj problem dizajna kot pa dejansko tehnični problem.
Prosim za nasvete, hvala.
Mohimm ::
Odvisno od zadeve
- dobro definiran problem in podana dokumentacija -> pretipkaš dokumentacijo v poljubni programski jezik, oziroma tisto kar je najbolj primerno
- definiran problem in normalni roki -> prebrskati kako se rešuje take probleme, +- rešitev, se odločiti za eno in implementirati (nakam si zapišeš tudi zakaj si se odločiš za to rešitev, da lahko pobrskaš nazaj)
- nedefiniran problem ali pa bi zadeva morala delati prejšnji teden -> odpreš ide in tipkaš, debugiraš ko je stvar že deployana :)
Po mojih izkušnjah me tepe to (razen pri prvi opciji), težko definiram teste in pretestiram delovanje... In ponavadi potem sledi večkratni refactoring...
- dobro definiran problem in podana dokumentacija -> pretipkaš dokumentacijo v poljubni programski jezik, oziroma tisto kar je najbolj primerno
- definiran problem in normalni roki -> prebrskati kako se rešuje take probleme, +- rešitev, se odločiti za eno in implementirati (nakam si zapišeš tudi zakaj si se odločiš za to rešitev, da lahko pobrskaš nazaj)
- nedefiniran problem ali pa bi zadeva morala delati prejšnji teden -> odpreš ide in tipkaš, debugiraš ko je stvar že deployana :)
Po mojih izkušnjah me tepe to (razen pri prvi opciji), težko definiram teste in pretestiram delovanje... In ponavadi potem sledi večkratni refactoring...
Zgodovina sprememb…
- spremenil: Mohimm ()
Stari89 ::
V naši ekipi na projektu imamo človeka, ki zbira bizniz potrebe in želje iz različnih koncev (ponavadi so to drugi oddelki v podjetju, saj gre za interni projekt) in jih prevede v tehnične zahteve oz. naloge. Naloge nato na sestankih predstavi ekipi, ki jih nato skupaj predebatiramo. To gre precej v detajle, velikokrat se debatira pred tablo in piše zapiske. Ko se zadeve lotim, ponavadi ni več odprtih vprašanj. Če mi vseeno kje zagusti, imam vedno na voljo nekoga v ekipi za pomoč.
Torej nekaj takega: 1. Zbira zahtev, 2. debate na sestankih, 3. implementacija.
Glede izboljšanja znanja pa menim, da je fajn stremet k temu, da imaš na projektu vedno zraven dobrega mentorja. Sem že menjal šiht iz tega razloga, saj se mi je zdelo, da sem v slepi ulici in da se na tisti firmi ne bom več nič naučil.
Naslednja dobra (in skoraj nujna) praksa so obvezni code reviewi. Preden se pri nas merga nazaj v razvojni branch, morata task pogledat in odobrit vsaj dva člana ekipe. Na ta način se ne le izogneš raznim bugom, ampak se načuš bolje programirat, uporabljat boljše vzorce, etc. Pa vedno je dober občutek (ko reviewaš kodo od drugih), ko najdeš kako napakico pri svojemu mentorju! :P
Trenutno debatiramo tudi o pair programmingu, torej dva za računalnikom - en razmišlja, drugi piše. Baje ni švoh.
Se pa še vedno spomnim nočnih mor iz prejšnjih podjetij, ko je bila tehnična zahteva za dvotedenski task napisana v eni vrstici. Ping-ponganje do groba. Iz takih firm samo bejž.
Torej nekaj takega: 1. Zbira zahtev, 2. debate na sestankih, 3. implementacija.
Glede izboljšanja znanja pa menim, da je fajn stremet k temu, da imaš na projektu vedno zraven dobrega mentorja. Sem že menjal šiht iz tega razloga, saj se mi je zdelo, da sem v slepi ulici in da se na tisti firmi ne bom več nič naučil.
Naslednja dobra (in skoraj nujna) praksa so obvezni code reviewi. Preden se pri nas merga nazaj v razvojni branch, morata task pogledat in odobrit vsaj dva člana ekipe. Na ta način se ne le izogneš raznim bugom, ampak se načuš bolje programirat, uporabljat boljše vzorce, etc. Pa vedno je dober občutek (ko reviewaš kodo od drugih), ko najdeš kako napakico pri svojemu mentorju! :P
Trenutno debatiramo tudi o pair programmingu, torej dva za računalnikom - en razmišlja, drugi piše. Baje ni švoh.
Se pa še vedno spomnim nočnih mor iz prejšnjih podjetij, ko je bila tehnična zahteva za dvotedenski task napisana v eni vrstici. Ping-ponganje do groba. Iz takih firm samo bejž.
Raptor F16 ::
Jaz sicer ne pišem ravno tako obsežne kode, da bi potreboval posebno načrtovanje.
Ampak, če se mi le da, si naredim splošno ERD analizo, da dobim nek vizualni načrt. Kasneje to razdelim na bloke in vsak blok še bolj razčlenim, če se mi zdi potrebno.
Večinoma itak kucam "na pamet".
Ampak, če se mi le da, si naredim splošno ERD analizo, da dobim nek vizualni načrt. Kasneje to razdelim na bloke in vsak blok še bolj razčlenim, če se mi zdi potrebno.
Večinoma itak kucam "na pamet".
Leva ... Leva ... leva desna ena dva
Zgodovina sprememb…
- spremenil: Raptor F16 ()
Vredno ogleda ...
Tema | Ogledi | Zadnje sporočilo | |
---|---|---|---|
Tema | Ogledi | Zadnje sporočilo | |
» | Ali so v Sloveniji sploh še kakšni developerji? (strani: 1 2 3 4 5 6 )Oddelek: Problemi človeštva | 63277 (32874) | LeQuack |
» | Googlova raziskava: oddaljene ekipe enako učinkovite in nagrajeneOddelek: Novice / Ostalo | 7222 (5445) | Tear_DR0P |
» | Delo programerjaOddelek: Loža | 4617 (3782) | Jure14 |
» | Medosebni odnosi v IT podjetjih & roki & nadure (strani: 1 2 )Oddelek: Loža | 18821 (15105) | Tody |
» | Za programerje, ki so zaposleni v podjetjuOddelek: Programiranje | 5886 (4417) | WarpedGone |