Jūs peržiūrite įrašus tema PDP

Visi, iki šiol parašyti įrašai PDP tema, buvo apie tai, kaip galima planuoti ir sekti darbą, įvairiais programos kūrimo etapais.Na o šis įrašas yra žvilgsnis į kitą programuotojo darbo sritį – programinės įrangos kokybę. Nepamirštant, kad aš pats nesu kažkoks profesorius, išmanantis kiekvieną programavimo aspektą, o esu tik žmogus, norintis pasidalinti įžvalgomis ir pastabomis šia tema, galima tęsti įrašo skaitymą.

Na iš pradžių gal reikėtų paaiškinti, ką man asmeniškai reiškia programinės įrangos kokybė. Grubiai imant, programinės įrangos kokybę apibrėžčiau šiais punktais:

1. Defektų (angl. Bug) kiekiu sukurtoje programinėje įrangoje,
2. Vartotojo sąsajos patogumu ir lengvumu naudoti,
3. Galimybėmis plėsti ir vystyti sukurtą programinę įrangą,
4. Efektyvumų ir geru resursų panaudojimu (angl. perfomance),
5. Funkcionalumu.

Tokie yra, mano nuomone, pagrindiniai kokybės vertinimo kriterijai. Na visų šių kriterijų detaliau panagrinėti tikrai nepavyks, tačiau šiame ir sekančiuose įrašuose norėčiau pakalbėti apie pirmąjį punktą – Defektų kiekį programinėje įrangoje, tiksliau, būdus, kaip galima “neskausmingai” sumažinti defektų kiekį savo rašomame kode.

Daug išsiplėsti šiame ir pora sekančių įrašų nesiruošiu, tik norėčiau paminėti ir pakalbėti apie tuos kelis dalykus, kurie padeda sumažinti defektų kiekį rašomame kode.

Taigi, ruošiuosi parašyti apie porą dalykų:

• Peržiūras – defektų prevencijos būdai, projektų ir kodo peržiūros.
• Dažniausiai naudojamų funkcijų biblioteka – įvairūs įrankiai ir įvairūs kodo šablonai, programuotoje kišenėje esantys tam, kad palengvintų ir taip sunku mūsų “programerių” gyvenimą.

Kodėl manau, kad ši tema yra verta dėmesio? Na atsakymas būtų paprastas, defektai pernelyg dažnai yra laikomi programuotojo kasdienybe. Taip tame yra dalis tiesos, nes nemanau, kad atrastume žmogų, kuris sugeba rašydamas savo kodą nepadaryti nė menkiausios klaidelės ir jo programos visada veikia tinkamai. Tačiau tikrai žinau, kad yra keletas metodų “kišenėje”, kuriais pasinaudojus galima tą defektų kiekį sumažinti iki minimumo. Jei ši tema jus sudomino, tai laukite sekančių poros įrašų tema.

P.S. kaip Jūs patys galvojote, kokios yra priemonės, padedančios išvengti defektų programuojant?

Na praeitą įrašą parašiau apie darbo progreso sekimą darbo žurnale, todėl šis įrašas bus tarsi tęsinys apie tai, kaip reikia sekti ir kaip svarbu fiksuoti statistinę informaciją. Taigi, iškart nieko nelaukdamas pulsiu tiesiai prie reikalo ir pradėsiu savo įrašą apie tvarkaraščius ir darbo progreso sekimą.

Tvarkaraštis – tai smulkiai aprašyta dienotvarkė, kuri pateikia darbų sąrašą, atliekamą atitinkamomis savaitės dienomis. Tai ypač patogus įrankis sekant kelių projektų vykdymo eigą ir darbo progresą vienu metu. Tuo pačiu sutaupoma laiko, kurį reikėtų gaišti, mąstant, koks bus sekantis programos kūrimo žingsnis ir pan.. Žinoma, susidarinėjant tvarkaraštį, reikia žinoti, kiek laiko per dieną galite skirti darbui. Šią informaciją galima gauti išanalizavus istorinę informaciją. Kadangi laikas, kurį galima skirti darbui, pastoviai kinta, reikia tokias analizes atlikti periodiškai, o ne vienintelį kartą. Išskirčiau tokius tvarkaraščio sudarinėjimo etapus:

1. Sudarinėjant tvarkaraštį, iš pradžių reikia apskaičiuoti ir įvertinti, kiek išteklių (pvz: laiko, finansų ir t.t.) prireiks atlikti kiekvienam darbui.
2. Sekančiu žingsniu reikia apskaičiuoti laiką, kuris bus skiriamas darbams įvykdyti. Atlikus šiuos veiksmus, galime pradėti sudarinėti tvarkaraštį.
3. Žinodami, kiek laiko reikia kiekvienam darbui atlikti, galime apskaičiuoti laiką, kurį galime skirti visiems darbams bendrai.
4. Sekančiu žingsniu apskaičiuojame laiką, kurį galime skirti kiekvienam darbui ar projektui atskirai, kadangi vienu metu gali būti vykdomi keli darbai ar projektai. Reikia susidaryti lentelę, kurioje visa ši informacija yra pateikta.
5. Turint kiekvieno darbo trukmės įvertinimus, yra pildoma darbų vykdymo forma, įvedamas laikas, kurį planuojama skirti konkrečiai užduočiai ir įvedama bendra darbo ar projekto trukmės reikšmė.

Skiriamo laiko darbui tvarkaraščio forma.

Taigi, išskirčiau tokius žingsnius reikalingus darbo tvarkaraščiui susidaryti. Iškyla klausimas, o kas toliau? O toliau reikia sugebėti to susidaryto tvarkaraščio laikytis. Nors atrodo, jog susidaryti tokį tvarkaraštį yra ne taip ir paprastą, tačiau pagrindinis ir sudėtingiausias uždavinys yra laikytis savo susidaryto tvarkaraščio. Visas įdėtas triusas ir pastangos, kaupiant įvairaus pobūdžio informaciją, nueis veltui, jeigu Jūs nebandysite sąžiningai laikytis savo susidaryto tvarkaraščio.

Jau praeitame įraše sulaukiau komentaro – kokio velnio aš turėčiau atlikti tuos papildomus darbus? Na gerai, klausimas nebuvo toks aštrus Bet esmė ta pati, visi šie darbai nėra skirti programuotojo darbo suvaržymui, netgi atvirkščiai, visi šie žingsniai yra skirti darbo palengvinimui. Nes programuotojui ne tik netenka gaišti laiko planavimo darbams, ką ir kaip reikia atlikti, bet ir suteikia tvirtą pagrindą po kojomis įrodyti savo užsakovui arba darbdaviui, kokiems darbams ir kiek laiko reikės skirti. Todėl nespjaukite į planavimą ir nepatingėkite tam skirti pakankamai laiko.

Nors jau ne kartą rašiau apie programas, kurios padeda suplanuoti, sekti ir organizuoti savo darbus, tačiau tikrai neišsiversčiau be darbo žurnalo. Nors ir įdomiai skamba, darbo žurnalas iš tiesų yra paprastas sąsiuvinys, tačiau jis įgavo tokį “patobulintą” pavadinimą, vien dėl to, kad tai nėra paprasčiausias užrašų sąsiuvinys, o šiek tiek labiau organizuota darbo priemonė.

Nors yra daugybė programų (“OneNote”, “Evernote” ir t.t.), kurių dėka įmanoma susikurti panašią darbo priemonę elektroniniame formate, tačiau jomis nėra taip patogu naudotis, kaip popieriniu variantu. Taigi, kaip ir minėjau anksčiau, darbo žurnalas yra organizuotas t.y. suskirstytas į tokius skyrius:

• Darbo planai – šiame skyriuje “talpinu”, kaip ir sufleruoja pavadinimas, savo darbų planus. Tačiau šioje skiltyje patarčiau nesismulkinti ir netalpinti darbo planų sudarytų 1 – 3 dienų laikotarpiui, o skirtų ilgesniems laikotarpiams.
• Einamų darbų sąrašai (angl. To-Do list) – kiekviena mano darbo diena prasideda 10 minučių skirtų, susiplanuoti, kokius darbus šiandien tikiuosi atlikti, bei baigiasi pora minučių, skirtų susižymėti kokius darbus pavyko atlikti ir kokius teks perkelti į sekančia dieną. Ši sritis ir yra skirta būtent šiems darbams surašyti.
• Tolimesni darbai – ši sritis skirta, surašyti kokias užduotis reikės atlikti ateityje ir po kokių darbų šios užduotys turi būti vykdomos. Iš esmės, ši sritis yra skirta surašyti pagrindinių darbų chronologijai.
• Užrašai – žinoma, neapsieičiau be srities skirtos paprasčiausiems užrašams, skirtų skaičiavimams, mini schemoms ir šiaip visokioms mintims užsirašyti.
• Atnaujinimų informacija – na ši sritis galbūt reikalinga specifiškam mano darbo pobūdžiui, kai reikia sekti, kokie pakeitimai yra atlikti, ir ką reikės atnaujinti, “suvienodinant” programų versijas.

Kam visa to reikia? Na jei skaitėte ankstesnius mano įrašus apie programuotojo darbo procesą, tai tikriausiai supratote, jog mėgstu susiplanuoti ir sekti savo darbą, todėl šis darbo žurnalas ir yra skirtas šiam tikslui pasiekti. Dar viena priežastis yra ta, jog, kaip ir kiekvienam programuotojui, taip ir man, galvoje tenka sutalpinti didelį kiekį įvairios informacijos ir tam, kad neužmiršti kokios nesvarbios “smulkmenos”, reikia turėti vietą, kur būtų galima nesunkiai atrasti visą reikiamą informaciją. Nesiginčysiu, jog yra programuotojų, kurių “smegenų kietojo disko talpa” yra išties didelė, bet manoji tikrai tokia nėra, todėl ir naudoju darbo žurnalą, jog vėliau netektų raudonuoti prieš vadovą, teisinantis, jog šį “mažyti” darbelį netyčia pamiršau atlikti, bet tuojau pat įvykdysiu.

Programos apimties ir kūrimo trukmės įvertinimas yra bene sudėtingiausias uždavinys, su kuriuo tenka susidurti kiekvienam programuotojui. Taip pat ir man, gerai įvertinti programos apimties ir kūrimo trukmę, yra sudėtingas uždavinys. Tiesa sakant, aš pats įvertinu tik kūrimo trukmę, o šis terminas vis dar “užsilikęs” iš perskaitytų Watts S. Humphrey knygų. Nors apimties įvertinimas yra pakankamai gerai aprašytas ir neabejotinai pateiktų patikimus duomenis, bet, mano nuomone, nauda neatperka laiko, skirto atrinkti tinkamą istorinę informaciją, atlikti geriems programos apimtiems įvertinimams, ir atlikti pačius apimties įvertinimus. Todėl ir šiame įraše rašysiu apie tai, kaip aš siūlyčiau įvertinti programos kūrimo trukmę.

Taigi, pradėkime nuo pradžių, sudarinėjant planą, didžiausią problemą sudaro informacijos trūkumas, kadangi apie programą, kurią reikia sukurti, ar vykdoma užduotį, dažniausiai yra žinoma ypač mažai. Pagrindinė turima informacija yra tik programos ar užduoties reikalavimai. Įvertinti būsimos programos kūrimo trukmę, yra ypač sunku. Todėl svarbiausia kuo geriau išsianalizuoti reikalavimus ir pasinaudoti visa turima istorine informacija. Kad vertinimai būtų kuo tikslesni, iš pradžių reikia susidaryti konceptualų programos projektą, kuris turi atspindėti, programos kūrimo ir veikimo principus. Svarbiausia, jog konceptualus projektas būtų sudarytas iš tokių programos elementų, kuriuos jau yra tekę kurti arba bent jau būtų žinoma, kaip tai reikėtų padaryti.

Sekančiu žingsniu, sudarinėjant planą, yra vertinamas programos kūrimo laikas, skirtas programai sukurti. Kadangi konceptualiame projekte yra aprašyti programos elementai, tai reikia atsirinkti istorinę informaciją, kuri suteiktų duomenų apie panašių programos elementų kūrimą. Programos kūrimo trukmės vertinimas, remiantis panašių, anksčiau kurtų programų istorine informacija, yra vadinamas atitikmenimis grįstu vertinimu (angl. Proxy-based estimating – PROBE). Atitikmuo, kaip ir sufleruoja pavadinimas, yra programa ar jos elementas, kuris atlieka tokį patį arba labai panašų darbą, kaip ir programa arba jos elementas, kurį reikės sukurti. Atitikmenys, kuriais būtų galima pasinaudoti vertinant būsimos kūrimo trukmę, turi būti kuo panašesni į naujai kuriama programą/modulį. Taigi, atitikmenimis grįstas vertinimas yra sudarytas iš tokių žingsnelių.

1. Išsiaiškinami programos reikalavimai.
2. Surenkama kuo daugiau istorinės atitikmenų informacijos.
3. Sudaromas konceptualus projektas iš į atitikmenis panašių programos elementų.
4. Visiems programos elementams atrenkama pati tinkamiausia atitikmenų istorinė informacija ir, naudojantis ta informacija, įvertinama kiekvieno elemento kūrimo trukmė.
5. Paskutiniu žingsniu įvertinama bendra programos kūrimo trukmė.

Vertinimas yra įgūdis, kurį galimą tobulinti ir gerinti. Yra keletas būdų, kaip vertinimo rezultatus galima pagerinti. Pirmasis patarimas – sudarinėjant konceptualų planą, reikia išskaidyti programą į mažesnius elementus, kadangi taip sumažinama prastų vertinimų įtaka galutiniam visos programos vertinimui, nei vertinant visos programos kūrimo trukmę iš karto, neskaidant programos į mažesnius elementus. Ypač svarbu palyginti kiekvienos programos realius kūrimo trukmės rezultatus su suplanuotaisiais, kadangi vertinant gali būti padaromos tendencingos paklaidos, pavyzdžiui, vertinimų duomenys visuomet yra ~40% mažesni nei gauti realūs rezultatai. Todėl, atliekant tolimesnius vertinimus, reikia įtraukti šią paklaidą, atitinkamai sumažinant arba padidinant galutinį vertinimo rezultatą. Tačiau reikia nepamiršti pastoviai lyginti realius duomenis su suplanuotaisiais, kadangi paklaidos gali kisti. Sekantis patarimas – kuriant konceptualų projektą, atrasti optimalų programos elementų išskaidymo lygį. Svarbu, jog konceptualus projektas nebūtų nei per daug nei per mažai detalus, kadangi tai stipriai įtakoja vertinimų tikslumą ir kokybę.

Na o ar jūs vertinate savo būsimų programų kūrimo trukmę? Jei taip, tai kaip tai darote?

Na iš karto noriu visus perspėti, kad šis straipsnis yra mėgėjiškas (tikiuosi, ateityje galėsiu ir turėsiu pakankamai žinių, pasidalinti profesionaliu, rimtais straipsniais ir argumentais pagrįstu straipsniu apie planavimą) pamąstymas, apie, tai kas mano manymu yra planavimas, kokia jo paskirtis ir koks turi būti planavimo procesas. Tikiuosi sulaukti ir jūsų nuomonių, nuorodų į straipsnius apie tai kaip jūs planuojate savo darbą arba bent jau norėtumėte planuoti.

Taigi, planavimas yra viena svarbiausių, bet tuo pačiu ir daugiausiai problemų sukeliančių, programuotojo darbo sričių. Problemų sukelia tai, jog nedaugelis programuotojų žino, kas turi būti plane ir kaip jį sudaryti. Prastas planavimas arba visiškas jo nebuvimas sukelia keletą, bet rimtų problemų. Visų pirma, kas yra akivaizdu, nesusiplanavus savo darbo, neįmanoma pasakyti, kiek laiko darbas užtruks. Gana dažnai tenka matyti, jog programuotojai paprasčiausiai nenori įvertinti ir susiplanuoti savo darbo iš anksto. Neretai naudojamasi argumentais, jog programavimas yra pernelyg neprognozuojamas darbas, kuris priklauso nuo aibės aplinkybių. Tačiau sutikite, tikrai nenorėtumėte, jeigu jūsų namą statantis architektas pareikštų, jog dabar prognozuoti statybų eigos neįmanoma ir net neleistų žvilgterėti į namo brėžinius ir statybos planus. Bet grįžkime prie darbo planavimo, programuotojo darbo planus galima panaudoti:

• Kaip susitarimo pagrindas dėl darbo trukmės ir kainos,
• Kaip darbo atlikimo schema,
• Kaip struktūra parodanti, kokie resursai bus reikalingi darbui atlikti,
• Kaip standartinis įrankis įvertinti darbo būsenai,
• Kaip įrašas, nurodantis kas ir kada buvo ir bus atlikta.

Aš asmeniškai, darbo planus sudarinėju dėl poros pagrindinių priežasčių: pirma, susidarius darbo planą yra žymiai lengviau įvertinti laiko resursus, reikalingus tam planui įgyvendinti ir antra, turint darbo planą daug lengviau sekti savo darbą ir susigaudyti kiek darbo atlikta ir kiek liko. Mano nuomone, darbo plano (planavimo proceso) susidarymo žingsniai turi būti tokie:

1. Išsiaiškinti būsimos programos (užduoties) reikalavimus ir funkcionalumą, kurį reikės įgyvendinti.
2. Suskaidyti visas užduotis, kurioms atlikti reikia daugiau nei keletos dienų, į mažesnes ir atskirai įvertinti darbo apimtį ir laiką, reikalingą kiekvienai iš šių užduočių atlikti. Aš pats stengiuosi laikytis tokių principų, jog kiekvienos užduoties trukmė turėti būtų nemažesnė nei 2 valandos ir nedidesnė nei 16 (2 darbo dienos) valandų.
3. Atliekant kūrimo trukmės ir apimties įvertinimus, naudotis panašaus pobūdžio darbų istorine informacija.
4. Dokumentuoti visus įvertinimus, kad vėliau juos būtų galima palyginti su realia informacija.
5. Keičiantis kuriamos programos reikalavimams ir funkcionalumui, tuo pačiu pakeisti ir darbo planą.

Prieš sėdant planuoti, patarčiau susidaryti ir projekto – užduoties koncepcinį planą. Konceptualus planas turi abstrakčiai apibrėžti programos veikimo principus, pagrindinius elementus ir jų funkcionalumą. Šio konceptualaus plano pagalba daug lengviau susiplanuoti savo darbą ir įvertinti visus faktorius. Paskutinis dalykas, kurį norėčiau paminėti, jog dirbant neretai kinta reikalavimai užduočiai ar darbas vykdomas ne pagal planą, todėl reikėtų nepamiršti po visų pasikeitimų modifikuoti ir darbo planą, kad ir toliau būtų galima juo naudotis.

Na o kokiais principais jūs planuojate savo darbą ir ar išvis tai darote?

Bene svarbiausia, mano nuomone, programuotojo darbo dalis yra sugebėti tinkamai suskirstyti ir įvertinti – išmatuoti atliktą darbą. Jei yra prastai išmatuojamas atliktas darbas, tai beveik neįmanoma gerai suplanuoti ir įvertinti savo būsimųjų darbų trukmę ir reikalingus resursus. Na o kas nutinka, kai yra nesilaikoma grafiko (turiu galvoje vėlavimą), tai gali papasakoti kiekvienas programuotojas. Kenčia ir kokybė ir reputacija, neprikausomai nuo to, kokios kvalifikacijos bebūtų specialistas. Todėl ypač svarbu sugebėti tinkamai įvertinti – išmatuoti savo atliekamus darbus.

Yra keletas būdų, kaip galima įvertinti savo atliekamą darbą, patys artimiausi man, yra du būdai:

• Matuoti savo darbą pagal parašytą kodo eilučių kiekį ir laiką,
• Matuoti savo darbą pagal įgyvendintus funkcinius taškus ir laiką.

Taigi, pirmuoju atveju tektų pasirašyti programą, kurį skaičiuotų parašyto programinio kodo eilutes, nes “rankiniu” būdų skaičiuoti programos kodo eilutes būtų pernelyg sunku ir beprasmiška, kadangi būtų neišvengiama klaidų ir užtrunkama daug laiko. Kad tokia programa pateiktų patikimus rezultatus, pats programuotojo rašomas turėtų būti pastovus ir vienodas t.y. įvairios programos kodo struktūros turi būti vienodas. Kitaip tariant, reikia naudotis ankstesnėje temoje aptartu kodavimo standartu. Vėlgi, dėrėtų nepamiršti, jog parašyto programos kodo eilutės gali ne tik didėti, bet ir mažėti, pvz.: optimizuojant parašytą programos kodą, neretai tenka ištrinti dalį parašyto ir jį pakeisti efektyvesniu. Tokią programą siulyčiau rašyti laikantis tokių principų:

• Programa turi skaičiuoti ir skirstyti programos kodą, suskirsčius jį į: naujai parašytą, modifikuotą ir ištrintą. Beabejo tektų pasirašyti ir kažkokį programos kodo versijavimo mechanizmą, kuris būtų panaudojamas vertinant einamuoju metu parašytą kodą su anksčiau parašytu.
• Ši programa turi turėti funckija, kuri skirstytų programos kodą pagal kategorijas ir sudėtingumą. Pvz.: kategorijos atitikmuo būtų programos kodas skirtas atvaizduoti vienos ar kelių duomenų bazės lentelių duomenis viename sąraše, o sudėtingumo atitikmuo (mažas, vidutinis ir didelis) būtų tas duomenų bazės lentelių ir laukų kiekis, kurį reikia atvaizduoti.
• Trečias ir paskutinis principas, kuriuo reikia vadovautis rašant programą skaičiuojančia programinio kodo eilutes, yra tas, jog ši programa turėtų atsižvelgti į programinio kodo dydžio ir laiko skirto tam kodui parašyti tendenciją kisti. Kadangi vystantis technologijom keičiasi ir darbo principai, todėl, šios programos pateikiami, duomenys turėti atitikti šių dienų realijas. Manau ne vienas .NET srityje dirbantis programuotojas galėtų pritarti, jog programavimas gana žymiai pasikeitė atsiradus linq.

Prisipažinsiu, šio metodo kol kas pačiam praktiškai išbandyti taip ir neteko, bet kai sugebėsiu pats sudėti į vieną programą tuos skaičiavimo principus, kuriuos ką tik aptariau, būtinai su jumis pasidalinsiu įspūdžiais ir rezultatais. Galėtų iškilti klausimas kodėl tada aš apie šį metodą išvis kalbu? Atsakymas paprastas, jei parašytą programa sugeba tinkamai įvertinti parašyto programos kodo eilučių kiekį ir laiką skirtą tam kodui parašyti, žymiai pagerėja ir supaprastėja ir pagerėja planavimas ir būsimųjų programų dydžio ir laiko resursų įvertinimas. Didelė dalis darbo yra automatizuojama, ko negalima padaryti antruoju metodu, kurį aš pats ir naudoju.

Darbo vertinimas pagal funkcinius taškus ir laiką yra pakankamai paprastas. Iš pradžių reikėtų savo darbą susiskirstyti (kaip ir pirmuoju atveju) į kategorijas. Tokių kategorijų pavyzdžiai galėtų būti: duomenų bazės projektavimas, specifikacijos rašymas, programos, atvaizduojančios duomenų bazės duomenis sąraše, rašymas ir pan.  Kaip ir pirmuoju atveju, kategorijų duomenis reikia susiskirstyti pagal darbo sudėtingumą: mažas, vidutinis ir didelis. Tačiau šiuo atveju vienintelis atlikto darbo matas būtų laikas. Toks matavimo būdas turi vieną didelį privalumą prieš pirmąjį, galima išmatuoti įvairaus tipo darbus, ne vien programavimo. Tačiau tokiu matavimo būdų naudojantis gauti duomenys ne visada suteiks patikimus duomenis, todėl planavimo rezultatų paklaida neretai bus didesnė.

Aš pats galvoju, jog pats efektyviausias būdas būtų naudoti šiuos abu metodus iškart, pirmąjį – programavimui, o kitus su programavimu nesusijusiems darbams.

Tai štai būtų tokie mano pasiūlymai – pamąstymai, kaip galima įvertinti savo atliktą darbą. Žinau, šiame įraše išdėsčiau tik pačius principus, kokie mano manymu yra reikalingi atliekant darbo įvertinimą, na bet mano tikslas ir nėra parašyti vadovėlio. Na o kaip jūs matuojate savo atliktą darbą ir ar išvis tai darote? Lauksiu nuomonių komentaruose.

Taip jau sutapo, jog prieš rašydamas šį įrašą, praktiškai galėjau išbandyti ir pajusti savo susidaryto kodavimo standarto naudą. Nors apie kodavimo standartą daug kalbėti ir nėra ko, tačiau naudotis kodavimo standartu yra būtina, todėl šis įrašas ir atrado savo vietą rašinių cikle. Taigi, kas per įrankis yra kodavimo standartas. Na gal paprasčiau bus jį apibūdinti, aprašant naudą, kurią šis įrankis suteikia, taigi programos, kurios parašytos naudojantis kodavimo standartu, yra lengvai skaitomos, programos kodas būna pastovus, vienodos struktūros ir skaičiuotinas. Na, tiesa, skaičiuotinas kodas turi būti tik tada, kai jus vertinate programų apimtį, pagal parašytų kodo eilučių kiekį, nors aš pats pastaruoju metu linkstu link to, jog programos apimtį reikėtų vertinti per funkcinius taškus, vėlesniuose įrašuose aptarsiu, kokie tai apimties vertinimo būdai ir kokie abiejų vertinimo metodų pliusai ir minusai. Na o dabar grįžkime prie to, kas turėtų sudaryti kodavimo standartą:

• Programos antraštės struktūra ir jos turinys – na šis elementas dažniausiai reikalingas, darbuojantis programuotojų komandoje, kai antraštėje įrašomas programos autorius ir pagrindinės programos funkcijos, tam kad programuotojų komandos nariai žinotų, į ką kreiptis iškilus klausimams.
• Programos naudojimo instrukcijos – šis kodavimo standarto elementas gali būti naudojamas tuo atveju, jei jūs dažnai savo rašomą programos kodą pakartotinai naudojate kitose programose. Tuo atveju šis aprašas turėti nurodyti, kokios yra programos pakartotinio naudojimo instrukcijos.
• Kintamųjų aprašymo instrukcijos ir pavyzdžiai – turint vienodus kintamųjų aprašymus yra žymiai paprasčiau ir lengviau išlaikyti vienodą programos kodo struktūrą ir “išvaizdą”.
• Komentarų rašymas ir išskyrimo pavyzdžiai – na šių aprašų paskirtis yra tokia pati, kaip ir kintamųjų aprašymo.
• Įtraukų naudojimo instrukcijos ir pavyzdžiai – būtina apsirašyti geras įtraukų naudojimo taisykles (atitraukimų per tab’us), kadangi chaotiškai naudojamos įtraukos kodą gali padaryti ypač sunkiai skaitomu.
• Loginių, ciklo, procedūrų ir funkcijų aprašymo instrukcijos ir pavyzdžiai – vėlgi šios kodavimo srities aprašų paskirtis tokia pati kaip ir kintamųjų aprašymo.

Taigi, iš šių elementų sudarytas kodavimo standartas tikrai palengvins tiek patį programavimą, tiek programos kodo skaitymą. Patikėkit manim, kalbu iš asmeninės patirties.

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.

Kaip pastebėjote, po gana sėkmingo mano asmeninio tinklaraščio starto, kai per savaitę buvo parašyta keletas įrašų, stojo visiškas štilis ir beveik visą mėnesį šiame tinklaraštyje dienos šviesos neišvydo nė vienas įrašas, dėl nenumatytų aplinkybių. Na bet štilis baigiasi ir grįžtu su naujais įrašais. Pirmasis bus apie bazinį darbo procesą, linkiu smagaus skaitymo.

Taigi, pradėsiu nuo sąvokos bazinis darbo procesas išaiškinimo. Bazinis darbo procesas – tai etapų, žingsnelių seka reikalinga darbui atlikti. Šiuo atveju – programai sukurti. Na patį savo rašinių ciklą pradedu nuo bazinio darbo proceso, nes pats, prieš pradėdamas skaityti ir nagrinėtis literatūrą apie asmeninį programos kūrimo procesą, nenaudojau jokio darbo proceso – iškart, gavęs užduotį, pradėdavau programuoti, net nesusimąstydamas, kokią įtaką rezultatams turėjo padrikas darbas. Darbo proceso turėjimas ir naudojimas suteikia:

• Duomenų apie programuotojo vykdomą darbą, jo rezultatus ir sritis, kurių darbą reikėtų pagerinti.
• Gaires programos kūrimo plano susidarymui, nes tam, kad būtų galimą sudaryti planą, reikia žinoti, kaip atlieki darbą.
• Informacijos, kaip reikėtų koordinuoti darbą, dirbant programuotojų komandoje.
• Organizuotumo, kai nėra švaistoma laiko, galvojant, ką reikėtų daryti toliau, atlikus vienokią ar kitokią užduotį.

Programuotojo darbo procesas turėtų būti sudarytas iš tokių etapų: planavimas, projektavimas, kodavimas, kompiliavimas, testavimas ir aptarimas. Na planavimo metu yra susidaromas užduoties, programuotojo atveju programos kūrimo, vykdymo planas. Projektavimo, kodavimo, kompiliavimo ir testavimo etapų kūrimo metu ir sukuriama pati programa. Aptarimo etapo metu yra vertinami suplanuoti rezultatai su realiaisiais. Na šio įrašo pavadinime neveltui yra įrašytas žodis bazinis, kadangi noriu pateikti tokį programuotojo darbo procesą, kurį siūlyčiau naudoti visiems, kurie bandys pasinaudoti mano išdėstytomis mintimis ir žiniomis. Jis bus tas pats pradinis programuotojo darbo procesas, kuris vėliau bus papildomas ir sudėtingės, įtraukiant vis daugiau užduočių. Taigi, aš siūlyčiau naudoti tokį bazinį programuotojo darbo procesą:

1. Planavimas:
   1. Programos kūrimo plano sudarymas.
   2. Įvertinama programos kūrimo trukmė ir kuriamos programos apimtis.
   3. Istorinės informacijos fiksavimas (Darbo trukmės, defektų).
2. Projektavimas:
   1. Programos ar užduoties detalaus projekto sudarymas. Šio etapo metu pagal specifikacija aprašomos programos dalys, atliekamos funkcijos ir veiksmai, bei kaip tos funkcijos sąveikaus tarpusavyje.
   2. Istorinės informacijos fiksavimas (Darbo trukmės, defektų).
3. Kodo rašymas:
   1. Programos kodo rašymas.
   2. Istorinės informacijos fiksavimas (Darbo trukmės, defektų, kodo eilučių).
4. Kompiliavimas:
   1. Kompiliavimas, defektų pašalinimas.
   2. Istorinės informacijos fiksavimas (Darbo trukmės, defektų).
5. Testavimas:
   1. Testų vykdymas, defektų pašalinimas.
   2. Istorinės informacijos fiksavimas (Darbo trukmės, defektų).
6. Programos aptarimas – šio etapo metu programuotojas dar kartą peržiūri savo sukurtą programą ir patikrina, ar atitinka reikalavimus, palygina, ar viskas padaryta taip, kaip buvo aprašyta plane. Taip pat yra sudaromos atitinkamos suvestines apie įvykdytą projektą ar sukurtą programą.

Iš esmės, šis programuotojo darbo procesas, neturėtų labai skirtis, nuo kiekvieno programuotojo darbo proceso. Vienintelė nauja užduotis, kurią manau vykdo nedidelė dalis programuotojų, yra istorinės informacijos fiksavimas. Kaip ir kokią istorinę informaciją reikia fiksuoti, aptarsiu sekančiose rašinių dalyse. Viliuosi, jog šis įrašas jums suteiks naujų minčių ir idėjų, kaip galima organizuoti ir sekti savo darbą.

Ilgai galvojau, kaip reikėtų pristatyti savo pirmąjį (tikiuosi ne vienintelį) rašinių (įrašų) ciklą tema “Programuotojo darbo procesas”, visgi šio rašinių ciklo rašymas yra viena pagrindinių priežasčių, dėl ko aš pradėjau rašyti tinklaraštį, ir noriu iš pradžių pasidalinti mintimis, kas mane paskatino tai padaryti. Taigi, studijuodamas Vilniaus universitete, tiek kursinį tiek baigiamąjį darbą rašiau tema – “Asmeninis programos kūrimo procesas”. Šio darbo rašymas buvo viena naudingiausių patirčių per visą studijavimo laikotarpį universitete. Asmeninis programų kūrimo procesas (angl. Personal Software Process) yra disciplina, kuri parodo, kaip reikėtų dirbti programuojant, kokius įrankius ir priemones naudoti ir kaip įvertinti ir pagerinti savo darbą ir rezultatus. Kadangi programavimas yra mistinis procesas, kurio rezultatus, manau su manimi sutiks didžioji dalis programuotojų, dažnai yra ypač sunku vertinti. Todėl ir noriu pasidalinti įgytomis žiniomis ir patirtimi, kurios tikiuosi padės tiek darbe tiek gyvenime.

Paklausite, kodėl programuotojo darbo procesas? Priežastis paprasta – mintis ir žinias, kurias ruošiuosi išdėstyti, galima pritaikyti ne vien kuriant programas o ir įvairiose, su programuotojo darbu susijusiose, srityse. Ar verta šį rašinių ciklą skaityti žmonėms nesispecializuojantiems programavime? Galbūt, iš tiesų šis rašinių ciklas yra skirtas būtent programuotojams, tačiau kai kurių skyrelių medžiagą galimą pritaikyti įvairiose srityse, pvz.: planavime, darbo organizavime ir pan.. Ko aš tikiuosi, rašydamas šį rašinių ciklą? Pasidalinti žiniomis ir užmegzti diskusijas, kuriose kiekvienas iš mūsų arba sutiktų su mano siūlomais metodais arba paprieštarautų, argumentuodamas ir pateikdamas savo versiją.

Na toliau danties užkalbinėti nesiruošiu ir norėčiau pereiti prie esmės. Programuotojo darbo procesą ruošiuosi išdėstyti tokia eile/struktūra:

1. Bazinis darbo procesas
2. Istorinės informacijos rinkimas
   1. Kodavimo standartas
   2. Programos apimties matavimas
3. Planavimas
   1. Programos apimties ir kūrimo trukmės įvertinimas
   2. Tvarkaraščiai ir darbo progreso sekimas
4. Programinės įrangos kokybė
   1. Peržiūros
   2. Dažniausiai naudojamų funkcijų biblioteka

Rašinių ciklas bus rašomas tokia tvarka, kokią čia ir matote, tikiuosi, jog pavyks parašyti bent po vieną įrašą per savaitę ir 2-3 mėnesių bėgyje pilnai pristatyti mano įsivaizduojamą programuotojo darbo procesą.

Dar norėčiau trumpai paminėti literatūros šaltinius, kurių medžiaga kartais remsiuosi. Tokių yra du: Introduction to the personal software process ir PSP – A Self-improvement Process for Software Engineers. Abi šios knygos ir yra apie asmeninį programos kūrimo procesą. Žinoma, mano rašinių ciklas nebus paprasčiausia, šiose knygose išdėstytų, minčių kopija, o bus aprašyta programuotojo darbo metodika, kurią susidariau, nagrinėdamas minėtą literatūrą ir taikydamas įgytas žinias praktikoje.

Viliuosi, kad visos šio rašinių ciklo metu išdėstytos žinios, padės organizuojant savo darbą, bei tikiuosi sulaukti jūsų atsakymų ir diskusijų šia tema.