Šių metų rugsėjo 29d., tikrai netikėtai man pačiam, buvau pakviestas į Microsoft padalinio Lietuvoje rengiamus „Spaudos pusryčius“, kuriuose buvo supažindinta su kompanijos ateities planais, į šį renginis buvo pakviesti spaudos atstovai ir tinklaraštininkai. Iš tiesų aš savęs ne tik kad nelaikau profesionaliu tinklaraštininku, bet ir apskritai tinklaraštininku, esu tik žmogus, kartas nuo karto pasidalinantis savo [...]
Programuotojo darbo procesas: #3 Istorinės informacijos rinkimas
Parašė: Gintaras Slavinskas Data: Rugpjūtis 4, 2009
Prieš rašydamas trečiąjį programuotojo darbo proceso įrašą, buvau kankinamas abejonės, kad mano tikslas, išdėstyti šią pakankamai sudėtingą temą, yra pernelyg optimistiškas, kadangi kaip rašytojas esu pakankamai žalias o tema sudėtinga. Tačiau apsisprendžiau, jog reikia pabaigti, tai ką pradėjau, ir vėliau galbūt šį rašinių ciklą perrašysiu, kai matysiu, jog galiu tai padaryti geriau.
Na bet grįžkime prie programuotojo darbo proceso. Pagrindinė priežastis dėl ko yra būtina rinkti istorinę informaciją, yra pagalba planuojant ir valdant projektus ar užduotis. Istorinė informacija parodo, kam ir kiek laiko programuotojas užtrunka dirbdamas, bei sritis, kuriose yra padaroma ir ištaisoma daugiausiai defektų. Taip pat istorinė informacija parodo programuotojo darbo pokyčius, keičiantis darbo procesams. Palengvinamas darbo procesų pokyčių įvertinimas, kadangi, analizuojant duomenis, nesunku atpažinti efektyviausius bei tuo pačiu ir ne tokius naudingus programuotojo darbo proceso proceso pokyčius. Istorinė informacija, kurią reikia fiksuoti, skirstau į tris sritis:
- Informacija apie defektus, kurie buvo padaryti tiek atskiro programos kūrimo etapo metu, tiek visos programos kūrimo metu.
- Informacija apie laiką, kurį programuotojas užtruko vykdydamas įvairias programos kūrimo užduotis.
- Informacija apie sukurtų programų ar programos modulių apimtį.
Istorinės informaciją fiksuoti siūlyčiau fiksuoti tokiose formose: laiko forma, defektų forma ir projekto ataskaitos forma. Pasinaudojant šia istorine informacija, galima atlikti duomenų analizę, identifikuojant sritis, kuriose darbo rezultatai yra prasčiausi, ir vėliau optimizuoti programuotojo darbą, stengiantis išspręsti pastebėtas problemas. Duomenų analizei skirtus metodus, aprašysiu sekančiuose skyreliuose. Ypač svarbu, jog istorinė informacija būtų kruopščiai fiksuojama ir itin tiksli. Jei istorinė informacija bus fiksuojama aplaidžiai, tai šių duomenų analizė nepateiks patikimų problemų sprendimo būdų.
Istorinės informacijos fiksavimas reikalauja laiko, todėl patartina naudoti priemones, kurios palengvintų laiko, defektų ir programos dydžio fiksavimą, kadangi taip būtų sutaupomas laikas, kurį galima skirti atlikti kitiems darbams. Šiam kartui tiek, jei iškils klausimų galite drąsiai klausti.
Žymos: Defektai, Istorinė informacija, Laiko sekimas
Panašūs įrašai
- PDP: #8 Programinės įrangos kokybė
- PDP: #7 Tvarkaraščiai ir darbo progreso sekimas
- Darbo žurnalas – “patobulinta” užrašinė
Tema: PDP
Komentarai 4
2009-08-04 Data: 22:35
Man patinka, nors tai tikrai įdomus būdas viską planuoti bent jau man, nes esu pakankamai dar naujokas programavime, bet tikrai verta dėmesio.
Siūlyčiau tik tuos .doc failus padaryti galbūt į .pdf
2009-08-05 Data: 01:10
Programuotojams tiesiog būtina naudoti versijų kontrolės sistemą, kaip kad Subversion (SVN), CVS, Git, Bazaar, Mercurial ar kt. Visa istorija saugoma sulig kiekvienu nusiuntimu į versijų duombazę. Visuomet galima pažiūrėt, kada ir kas padarė kokius pakeitimus.
Jei naudoji SVN, tuomet jį galima apjungt su Trac, kuris pakeitimus atvaizduoja naršyklėje, bei papildomai turi wiki dokumentacijoms bei klaidų/užduočių valdymo sistemą.
2009-08-05 Data: 08:57
Archatai aš net neprieštarauju tau ir pritariu, jog versijų kontrolės sistema yra būtinas daiktas programuojant. Bet šis įrašas yra ne apie patį programavimo principą, versijavimą ir panašius dalykus, o apie programuotojo darbo organizavimą t.y. ši istorinė informacija yra ne programos kodas, jo pakeitimai ir panašūs dalykai, o programuotojo darbo laikas užtruktas, kuriant įvairias programas ir modulius, ir defektų kiekis, kuriuos programuotojas paliko savo kode jau po testavimo etapo. Visa šita informacija yra žaliava, kuria vėliau galima panaudoti planuojant savo darbą.
Ričardai, kai tik turėsiu daugiau laiko, konvertuosiu .doc failus į .pdf. Keista, kad man pačiam nešovė į galvą mintis, jog reikia iš karto dokumentus pateikti .pdf formatu.