Rekomendācijas programmētāju kvalifikācijas darbiem

Šajā nedēļā piedalījos Latvijas Universitātes Datorikas fakultātes programmētāju kvalifikācijas darbu vērtēšanas komisijā – gan recenzēju daudzus darbus, gan arī klausījos un vērtēju klātienē vēl vairāk darbus. Kā jau katru gadu man nepatika vairākas tendences, kas bija sastopamas daudzos darbos, tādēļ gribēju šeit izkratīt sirdi un padalīties ar rekomendācijām, kā vajadzētu labāk rakstīt šos darbus, lai saņemtu labu vērtējumu no manis kā potenciālā vērtētāja🙂

Strādājošs, kvalitatīvs un uzturams programmatūras kods ir primārais mērķis

Kā vienu no pirmajām lietām gribēju uzsvērt šo Agile principu, jo programmēšanas kvalifikācijas darbos galvenais mērķis ir parādīt, ka autors spēj radīt kvalitatīvu programmatūru. Tādēļ:

  • Strukturējiet programmatūru saprotamos funkcionālajos moduļos.
  • Sadaliet katru moduli nelielās funkcijās vai metodēs – nekādā ziņā viena funkcija vai metode nedrīkst būt pa daudzām lappusēm. Jo tās būs īsākas un saprotamākas, jo labāk.
  • Komentāros rakstiet, kāpēc jūs kaut ko dariet, nevis vēlreiz atkārtojiet to, kas redzams kodā.
  • Sadaliet biznesa loģiku un attēlošanas loģiku dažādos moduļos (sliktākie piemēri bija, kad vienā failā ir gan PHP, gan SQL, gan HTML, gan Javascript kods sajaukts vienā lielā putrā).
  • DRY (Don’t Repeat Yourself) princips – ja kāds kods bieži tiek ar copy-paste dublēts, tad tas nozīmēt, ka šo loģiku vajag izdalīt kādā kopējā funkcijā vai metodē, lai izvairītos no koda dublēšanas.

Vienkārša, saprotama un vajadzīga dokumentācija

Daudzos darbos sliktu kodu centās kompensēt ar lieliem dokumentācijas blāķiem, kas manā vērtējumā darbu var tikai pasliktināt.

  • Labāk dokumentāciju rakstiet īsāku un saprotamāku, nevis garu un nesaprotamu.
  • Izvairieties no triviālu lietu skaidrošanas un liekvārdības, bet neaizmirstiet paskaidrot lietas, kas ir specifiskas jūsu darbam.
  • Arī dokumentācijai ir jābūt DRY – nekopējiet vienus un tos pašus aprakstus uz dažādām dokumentācijas vietām.
  • Nemāniet lasītāju, ka vispirms uzrakstījāt visu prasību specifikāciju dokumentu, pēc tam projektējuma aprakstu un tikai tad kodējāt. Ūdenskrituma metode nav vienīgā pieeja – tā ir novecojusi un mūsdienās parasti nepiemērota pieeja. Droši izmantojiet un aprakstiet iteratīvās / inkrementālās / spējās izstrādes pieejas, ja tas ir patiesais veids, kā esat veidojuši savu darbu.

Testējiet ar kodu nevis ar dokumentāciju

Daudziem liekas, ka labākais veids, kā pārliecināt lasītāju, ka viņi ir dikti labi testējuši, ir saproducēt lielu testēšanas dokumentāciju. Bet, manuprāt, liela un sarežģīta testēšanas dokumentācija apliecina tikai to, ka šie testi netika bieži izpildīti.

  • Ļoti rekomendēju apgūt jūsu izvēlētās programmēšanas valodas atbilstošo automatīzēto vienībtestēšanas ietvaru. Automatizēti un regulāri izpildīti vienībtesti vienmēr būs labāki nekā gari un manuāli izpildāmi testi.
  • Primāri testējiet jūsu darba svarīgāko un potenciāli riskantāko funkcionalitāti, nevis rakstiet daudzus vienkāršus (piemēram, lauku obligātuma pārbaudes) testus.

Drošība

  • “Paroļu šifrēšana” nav vienīgā drošības problēma un/vai prasība.
  • Ja jūsu programmā ir dažādi lietotāji ar dažādām tiesībām, tad pieejas tiesības ir vienas no primārajām drošības prasībām, kas arī ir jātestē.
  • Pirms veidojiet “web” bāzētu sistēmu, iepazīstieties ar biežākajām drošības problēmām “web” bāzētajās sistēmās – sāciet ar SQL injekcijas problēmām.

Konfigurāciju pārvaldība

  • Mūsdienās veikt programmatūras koda pārvaldību tikai ar failu rezerves kopēšanas palīdzību profesionālam programmētājam vairs nebūtu pieļaujams.
  • Apgūstiet un lietojiet atbilstošus versiju kontroles rīkus, piemēram, Subversion, Git vai citus. Versiju kontroles rīki ir vieni no programmētāju pamatrīkiem.

Darbietilpības novērtēšana

  • Darbietilpības novērtēšana ir paredzēta, lai prognozētu potenciālo darbietilpību pirms jūs esat sākuši programmēt sistēmu. Darbietilpības novērtēšana nav paredzēta, lai pamatotu komisijai, ka jūs tiešām esat veltījuši 3 mēnešus darba izstrādei.
  • Neizmantojiet sarežģītas COCOMO novērtēšanas metodes, ja jums nav skaidrs, ko tās prognozē un ja jums rezultāti sanāk pavisam savādāki nekā faktiski patērētais darbs. Un netaisnojieties ar to, ka “COCOMO paredzēts lieliem projektiem” – lielie projekti nav nekas tāds briesmīgs, kuros pēkšņi visas vienkāršās lietas ir jātaisa piecreiz sarežģītāk.
  • Ja jūs izmantojat iteratīvo / spējo (Agile) pieeju pieeju, tad izmantojiet atbilstošas spējās novērtēšanas tehnikas.

Ceru, ka šīs manas rekomendācijas studenti nākamreiz “uzgooglēs” un ņems tās vērā kvalifikācijas darba izstrādē🙂

16 Responses to Rekomendācijas programmētāju kvalifikācijas darbiem

  1. Pēteris says:

    Ļoti sakarīgi ieteikumi. Žēl, ka tādi ir vajadzīgi, — ka nav jau iedīdīti lekcijās.

  2. Aleksey says:

    Vai nu studenti spej izveidot strādājošo UN kvalitatīvo UN un uzturamo programmatūras kodu? =)))))))))

  3. Mārtiņš K says:

    Auotrs droši var norādīt saiti uz šo blogu studentiem, jo citādi cerība, ka kurss to izlasīs, ir minimāla. Būsim reāli, laicīgi darbu izstrādāt sāk tikai maza studentu daļa, kur nu vēl plānot laicīgi, un tad kad beidzot ir sākts, tad tiek ķerts un grābts kas pagadās, lai tik kaut kā pa naktīm uzspētu uzrakstīt kaut ko ko nodot. Protams, ir arī patīkami izņēmumi. Parasti arī šie izņēmumi veido ļoti labus un interesantus risinājumus.

  4. Jānis says:

    “Darbietilpības novērtēšana ir paredzēta, lai prognozētu potenciālo darbietilpību pirms jūs esat sākuši programmēt sistēmu. Darbietilpības novērtēšana nav paredzēta, lai pamatotu komisijai, ka jūs tiešām esat veltījuši 3 mēnešus darba izstrādei.”

    Tiešām ne pretēji? Jāņem taču vērā, ka industrijā darbietilpību novērtē “balstoties uz pieredzi”. Kā tad citādi komisijai pierādīt, ka darbam veltīti 3 mēneši?

  5. Tur jau tā lieta, ka industrijā darbietilpību jaunam projektam novērtē uz iepriekšējo projektu pieredzes, vai arī izmantojot citu pieredzi, ja pašam tādas vēl nav. Šī tādēļ ir viena no praksēm, kas topošajiem programmētājiem būtu jāapgūst – kā novērtēt darbietilpību _pirms_ kaut kas tiek sākts programmēt.

    Komisijā sēž pietiekoši inteliģenti cilvēki, lai viņi tāpat spētu novērtēt, vai ir ieguldīts pietiekošs darba apjoms. Viņus neizdosies apmānīt ar gudrām formulām, kas pateiks, ka tūkstots rindiņu programmu vajadzēja rakstīt 3 mēnešus🙂

    • nekoderis says:

      tas viss monologs ir versts tiiri uz to, kaa pachakareet studentu – jo tadas ‘hu**as’ veido tikai cilveki, kuriem nav ko dariit un kuru dzives moto ir ‘kodee un apraksti’, pec tam to visu megjina uzspiest citiem (jaw)

      • it says:

        Tādi cilvēki, kā tu līdzcilvēkos vispirms saskata ļauno un tikai pēc tam labo. Tev noteikti nav viegli.

  6. Filips says:

    Par to darbietilpības novērtēšanu LU programmētāju kvalifikācijas darbos tiešām ir nesaprašanās.

    Patiesībā no studentiem netiek prasīts veikt darbietilpības prognozi pirms darbu uzsākšanas (kaut gan tas nav aizliegts un noteikti padarītu darbu tikai interesantāku).
    Kas tiek prasīts ir – pamatot/parādīt, ka darba apjoms atbilst prasītajam (3 cilvēkmēneši).
    Kā to izdarīt ir interesants un atvērts jautājums. Diemžēl studentiem atmiņā ir palicis tikai COCOMO…

  7. Zane says:

    Filip, ir vēl skumjāk…. COCOMO viņi norakstījuši no iepriekšējā gada darbiem, nevis atceras no lekcijām🙂
    Uz tikšanos nākamā gada komisijā! Un jauku vasaru visiem.

  8. Mārtiņš says:

    Hmm, 3 mēnešu jau var ņemties vien ar to, lai piekalibrētu COCOMO II constantes konkrētā kvalifikācijas darba vajadzībām.🙂

  9. Dainis says:

    Kvalifikācijas darbu prasībās ir skaidri pateikts, ka darbā ar populārām metodēm ir jāparāda, ka darba apjoms tiešām sasniedz (pārsniedz) trīs cilvēkmēnešus. Protams, ka studentiem arī tiek izskaidrotas atšķirības starp darbietilpības novērtēšanu pirms projekta izstrādes. Bet kurš tad to atceras un mēģina darbā pielietot. Par šo darbietilpības novērtēšanu vēl vajadzēs padiskutēt pirms attiecīgo lekciju gatavošanas.

  10. asdf says:

    Lielisks rakts, noderēs priekšdienās :))

  11. Lunis says:

    Students, un darbietilpības novērtēšana. Šī laikam ir ņirgāšanās par studentiem. Students visticamāk taisa savu līdz šim nopietnāko darbu, un tādeļ tur NEVAR pirms paša darba būt nekāds novērtējums, jo nav taču pieredzes. A mācīties no citu pierdzes ar nevar jo tie citi iespējams ir profesionāļi ar pilnīgi citu jaudu. Un vēl ja jau kāds ir ko tik ļoti līdzīgu tavam darbam darījis, ka varētu izmantot viņa pieredzi vērtējumā, tad visticamāk, tev būs kaut kas ļoti tuvs plaģiātam.

    Kāpēc gan profesionālis arī nevarētu vienkārsi kopet failus. Kapēc ir tie aizspriedumu par CVS, SVN, GIT utt. ? Ja tus trāda viens, tad parasta kopesana ir pilnīgi OK. Tā pat ir drošāka par tiem automātiskajiem rīkiem, jo neticu ka studentam būs pietiekami drošs storage “disaster recovery” iespēju. A kopēt visu source repositoriju manuali ta pati kopesana vien ir.

  12. Uvis says:

    Man ir jautājums ja piemēram ja vel nav tikai kvalifikācijas prakse vel citi priekšmeti un kā var uzrakstīt kvalitatīvu mājas lapu ja kas bieži jau sanāk php un hml kopā un tos ir ļoti gruti atdalīt jo ir jau savstarpēji saistīti…

  13. Žēl, ka lekcijās šo nestāstīja…

Komentēt

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Mainīt )

Twitter picture

You are commenting using your Twitter account. Log Out / Mainīt )

Facebook photo

You are commenting using your Facebook account. Log Out / Mainīt )

Google+ photo

You are commenting using your Google+ account. Log Out / Mainīt )

Connecting to %s

%d bloggers like this: