Džoelio testas: 12 žingsnių link geresnio kodo
From The Joel on Software Translation Project
Džoelio testas: 12 žingsnių link geresnio kodo
Autorius: Džoelis Spolskis (Joel Spolsky)
2000m. rugpjūčio 9d., trečiadienis.
Ar esate kada girdėję apie SEMA? Tai tokia ezoteriška sistema, skirta išmatuoti programuotojų komandos gerumui. Ne, pala! Nežiūrėkite tos nuorodos! Jau vien sistemos perpratimui ten prireiktų kokių šešių metų. Taigi, sugalvojau savo paties visiškai neatsakingą, nerūpestingai sukurptą testą programuotojų komandos įvertinimui. Šauniausia jo savybė yra ta, kad teužtrunka apie tris minutes. Visą tą sutaupytą laiką galite skirti studijoms medicinos universitete.
Džoelio testas
- Ar naudojate versijavimo sistemą (source control)?
- Ar galite viską sukompiliuoti vienu žingsniu? (...build in one step)
- Ar darote kasdieninius kompiliavimus? (daily builds)?
- Ar turite klaidų duomenų bazę?
- Ar ištaisote defektus prieš rašydami naują kodą?
- Ar turite nepasenusį grafiką?
- Ar turite specifikaciją?
- Ar programuotojams sudarytos ramios darbo sąlygos?
- Ar naudojate geriausią programinę įrangą, kokią galima gauti už pinigus?
- Ar turite testuotojus?
- Ar nauji kandidatai pokalbyje dėl darbo rašo kodą?
- Ar atliekate koridorinį naudojamumo testą?
Geroji Džoelio testo pusė yra ta, kad lengva gauti taip/ne atsakymą. Nebūtina matuoti kodo-eilučių-per-dieną skaičiaus ar klaidų-kiekio-vienai-funkcijai-vidurkio. Duokite savo komandai vieną tašką už kiekvieną „Taip“ atsakymą. Džoelio testo trūkumas yra toks: verčiau jau nenaudokite jo norėdami nustatyti, ar Jūsų atominės elektrinės programinė įranga yra saugi.
12 taškų yra tobula, 11 yra toleruotina, bet 10 ar mažiau – ir Jūs turite rimtų problemų. Tiesa yra ta, kad dauguma programinės įrangos įmonių dirba su 2 – 3 taškais, ir joms reikia rimtos pagalbos, kadangi tokios įmonės kaip Microsoft nuolat dirba su dvylika.
Žinoma, tai nėra vieninteliai faktoriai, lemiantys sėkmę ar žlugimą: konkrečiau, jei jūsų didi programuotojų komanda dirba prie produkto, kurio niekam nereikia, ką gi, dėl to žmonėms nepradės jo reikėti. Kita vertus, galima įsivaizduoti „gunslinger'ių“ komandą, kuri nedaro nieko iš šio sąrašo ir vis tiek sugeba pagaminti neįtikėtiną programinę įrangą, pakeisiančią pasaulį. Tačiau, kitoms aplinkybėms esant vienodoms, jei šiuos 12 dalykų darysite teisingai, turėsite disciplinuotą komandą, visada gebančia laiku pabaigti darbus.
Ar naudojate versijavimo kontrolės sistemą?
Man teko naudoti komercines versijavimo kontrolės sistemas, taip pat teko naudoti CVS, kuri yra nemokama, ir galiu pasakyti, CVS yra pakankamai gera. Bet jei nenaudojate jokios versijavimo sistemos, Jums teks gerokai pavargti bandant suorganizuoti komandinį programuotojų darbą. Jie neturės jokio būdo sužinoti, ką padarė kiti žmonės. Klaidos negalės būti lengvai ir greitai atmestos. Kita gera versijavimo kontrolės sistemų savybė yra ta, kad pats kodas yra tikrinamas kiekvieno programuotojo kietajame diske – niekada negirdėjau apie šią sistemą naudojantį projektą, kuriame būtų dingusi bent viena kodo eilutė.
Ar galite viską sukompiliuoti vienu žingsniu?
Turiu omenyje: kiek žingsnių užima padaryti parduodamą programą pakeitus kodą? Geros programuotojų komandos turi vieną skriptą, kuris padaro pilną patikrinimą nuo nulio, perkompiliuoja kiekvieną kodo eilutę, sukuria EXE failus, visoms reikalingoms versijų, kalbų ir #ifdef kombinacijoms, sukuria įdiegimo paketą ir galiausiai sukuria galutinę media – CD ROM maketą, interneto puslapį parsisiuntimui ar panašiai.
Jei procesas užtrunka daugiau, nei vieną žingsnį, jis labai neatsparus klaidoms. O kai priartėjate prie darbo pabaigos, geriau turėti kuo greitesnį būdą ištaisyti „paskutinei“ klaidai, padaryti galutinius EXE ir taip toliau. Jei kodo sukompiliavimui, įdiegimo paruošimui ir t.t. prireikia 20 žingsnių, galiausiai pradės važiuoti stogas ir imsite daryti kvailas klaidas.
Vien dėl šios priežasties paskutinė įmonė, kurioje dirbau, nuo „WISE“ perėjo prie „InstallShield“: mums reikėjo, kad įdiegimo procesas galėtų vykti iš skripto, automatiškai, per naktį, naudodamas NT grafiką, o WISE negalėjo veikti pagal automatinį grafiką, tad mes jį ir išmetėme. (Po šio straipsnio malonūs žmonės iš WISE mane užtikrino, kad naujausioji jų versija palaiko automatinį veikimą pagal grafiką).
Ar darote kasdieninius kompiliavimus?
Naudojant kodo versijavimo sistemas, kartais vienas programuotojas atsitiktinai įdeda kažką, dėl ko nebeveikia viskas. Pavyzdžiui, įdeda nuorodą į naują kodo failą, kuris jo paties kompiuteryje puikiai kompiliuojasi, tačiau į versijavimo sistemos repozitorijų pamiršta įdėti patį failą. Taigi, programuotojas užrakina kompiuterį ir keliauja namo, atsipūtęs ir laimingas. Tačiau visi kiti dirbti nebegali, todėl taip pat turi eiti namo, tik nelaimingi.
Sugadinti programą yra taip blogai (ir taip dažna), kad labai padeda daryti kasdieninius pilnus kompiliavimus, siekiant užtikrinti, jog tokie dalykai nepraeis nepastebėti. Didelėse komandose, geras būdas užtikrinti kad tokios klaidos bus taisomos tuoj pat, yra kasdieninį kompiliavimą daryti apie pietus. Visi iki to laiko sudeda į repozitorijų kiek galima daugiau pakeitimų. Kai grįžta po pietų, kompiliavimas yra pabaigtas. Jei veikia – puiku! Visi pasiima naujausią kodo versiją ir grįžta prie darbo. Jei kompiliavimas nepavyko, taisomos klaidos, tačiau visi tuo metu gali dirbti toliau su ankstesne, veikiančia kodo versija.
Excel komandoje mes turėjome taisyklę, kad kas sugadina programą, kaip „bausmę“ atlikinėja kasdieninius kompiliavimus tol, kol sugadina kažkas kitas. Tai buvo gera motyvacija nesugadinti kompiliavimo ir geras būdas keistis atsakomybe už šį procesą.
Daugiau apie kasdieninius kompiliavimus skaitykite kitame mano straipsnyje – Daily Builds are Your Friend.
Ar turite defektų duomenų bazę?
Man nerūpi Jūsų pasiteisinimai. Jei gaminate programinę įrangą, net vieno žmogaus komandoje, be organizuotos duomenų bazės su visomis kodo klaidomis Jūs pardavinėsite žemos kokybės programas. Daugybė programuotojų mano, kad defektų sąrašą gali laikyti tiesiog galvose. Nesąmonė. Aš negaliu prisiminti daugiau dviejų – trijų defektų vienu metu, o kitą rytą, arba skubėjimo įkarštyje prieš pat programos užbaigimą, jie yra užmirštami. Yra absoliučiai būtina registruoti defektus formaliai.
Defektų duomenų bazės gali būti sudėtingos ar paprastos. Minimali naudinga duomenų bazė privalo įtraukti šiuos dalykus:
- Pilną procesą defekto atkartojimui
- Tikėtiną elgesį
- Stebimą (klaidingą) elgesį
- Kam priskirtas taisymo darbas
- Ar jau pataisyta, ar dar ne
Jei defektų registravimo programų sudėtingumas yra vienintelis jus atbaidantis dalykas, tiesiog pasidarykite paprastą 5 stulpelių lentelę su šiais svarbiausiais laukais ir pradėkite ją naudoti.
Daugiau apie defektų registravimą skaitykite Painless Bug Tracking.
Ar ištaisote defektus prieš rašydami naują kodą?
Pati pirmoji „Microsoft Word for Windows“ versija buvo laikoma mirusiu projektu. Jis truko amžinai. Nuolat neveikdavo. Visa komanda dirbo absurdiškus viršvalandžius, projektas būdavo uždelsiamas vėl, ir vėl, ir vėl, o stresas buvo neįtikėtinas. Kai tas prakeiktas dalykas pagaliau buvo pabaigtas, vėluojant kelis metus, Microsoft nusiuntė visą komandą atostogų į Kankuną ir susėdo rimtam tyrimui.
Štai ką jie atrado: projekto vadovai taip primygtinai reikalavo laikytis „grafikų“, kad programuotojai paprasčiausiai skubiai prabėgdavo programavimo procesu, rašydami ekstremaliai blogą kodą, kadangi klaidų taisymo dalis nebuvo įtraukta į formalius grafikus. Nebuvo jokio mėginimo ir jokio suinteresuotumo stengtis mažinti klaidų skaičių. Visiškai priešingai. Vienas programuotojas, turėjęs parašyti funkciją teksto eilutės aukščio apskaičiavimui, tiesiog parašė „return 12;“ ir laukė, kol ateis pranešimai kad jo funkcija skaičiuoja ne visada teisingai. Visas grafikas buvo tiesiog būsimų klaidų sąrašas. Post-mortem, tai buvo apibūdinta kaip „begalinių defektų metodologija“.
Problemos sprendimui Microsoft universaliai priėmė „nulio defektų metodologiją“. Daug programuotojų juokėsi, nes atrodė tarsi vadovybė bandytų klaidų skaičių iki nulio sumažinti tiesioginiu įsaku. Iš tiesų, „nulis defektų“ reiškia, kad bet kuriuo metu aukščiausias prioritetas teikiamas klaidų eliminavimui, prieš rašant tolimesnį kodą. Štai kodėl.
Apskritai, kuo ilgiau lauksi prieš taisydamas defektą, tuo brangiau taisymas kainuos – tiek laiko, tiek pinigų prasme.
Pavyzdžiui, kai padarote rašybos ar sintaksės klaidą, kurią kompiliatorius randa, ją ištaisyti labai paprasta.
Kai kode yra defektas, pastebimas pirmą kartą paleidus, jį sutvarkyti galima labai staigiai, kadangi kodas mintyse yra dar šviežias.
Jei randate defektą kode, kurį parašėte prieš kelias dienas, surasti priežastį užtruks laiko, bet iš naujo perskaitę parašytą kodą, viską prisiminsite ir klaidą ištaisysite pakankamai greitai.
Bet jei pastebite defektą kode, parašytame prieš kelis mėnesius, greičiausiai tuo metu jau būsite apie jį pamiršę viską, ir sutvarkyti bus daug sunkiau. Tačiau kai bandysite taisyti kažkieno kito kodą, o tas kitas tuo metu bus Aruboje atostogose, defekto taisymas bus kaip mokslas: turėsite viską daryti lėtai, metodiškai ir skrupulingai, ir niekada nebus aišku kiek tai gali užtrukti.
O jei rasite defektą kode, kuris jau parduotas, jo sutvarkymas kainuos labai daug.
Čia viena priežastis, kodėl defektus reikia taisyti iš karto: kadangi tai užima mažiau laiko. Yra ir kita, susijusi su tuo, kad žymiai lengviau prognozuoti kiek užtruks naujo kodo rašymas, nei kiek užtruks defektų taisymas. Pavyzdžiui, jei paklausčiau Jūsų, kiek užimtų parašyti kodą sąrašo rikiavimui, galėtumėte atsakyti pakankamai tiksliai. Bet jei paklausčiau, kiek užtruks pataisyti tą defektą, dėl kurio Jūsų kodas neveikia kai kompiuteryje yra instaliuotas Internet Explorer 5.5, Jums negalėtumėte net spėti, kadangi neturite supratimo, kas tai per defektas. Jo taisymas gali užtrukti kelias minutes, o gali ir dvi savaites.
Visa tai reiškia, kad jei turite grafiką su daugybę dar nepataisytų defektų, grafikas nepatikimas. Bet jei pataisėtė visus žinomus defektus ir liko tik rašyti tolimesnį kodą, grafikas bus daugybę kartų tikslesnis.
Kitas svarbus dalykas, kad nuolat taisant klaidas galima žymiai greičiau atsakyti į konkurentų veiksmus. Tai galima traktuoti kaip produkto laikymą paruoštu pardavimui visą laiką. Tuomet jei konkurentas su savo programa pristatys naują nerealią galimybę, padedančią perimti Jūsų klientus, Jūs tą pačia galimybę galėsite įdiegti išsyk, nelaukdami kol bus pataisytas milžiniškas skaičius susikaupusių defektų.
Ar turite nepasenusį grafiką?
Jei jūsų kodas yra apskritai svarbus verslui, egzistuoja daugybė priežasčių, kodėl svarbu žinoti, per kiek laiko jis bus parašytas. Programuotojai yra pastebimai irzlūs, kalbai pasisukus apie grafikus. „Tai bus pabaigta, kai pabaigsime“, šaukia jie verslo žmonėms.
Nelaimei, tai neveikia. Yra per daug planavimo sprendimų, kuriuos verslininkai turi priimti gerokai prieš kodo pabaigimą: demonstracinės versijos, prezentacijos, reklama ir t.t. Ir vienintelis būdas tai padaryti yra turėti grafiką bei jį atnaujinti.
Kitas ypač svarbus aspektas yra tas, kad grafikas priverčia apsispresti, kurias programos savybes reikės daryti, o tada priverčia atrinkti mažiausiai svarbias ir jas išmesti, vietoje to, kad pasinerti į „scope creep“: kuomet projekto savybės ir paskirtis keičiasi nebekontroliuojamai, vis prigalvojant naujų išmonių.
Laikyti grafikus nebūtinai yra sunku. Perskaitykite mano straipsnį „Painless Software Schedules“, aprašantį paprastus būdus ruošti puikius grafikus.
Ar turite specifikaciją?
Specifikacijos yra kaip siūlas dantims valyti: visi sutinka, kad tai geras dalykas, bet niekas nenaudoja.
Nesu tikras, kodėl taip yra, galbūt todėl, kad dauguma programuotojų nekenčia dokumentų rašymo. Rezultate, kai komandą sudaro vien programuotojai, problemos sprendimą jie mieliau išreiškia tiesiai kodu, o ne dokumentuose. Jie mieliau iškart eina prie programavimo, prieš tai nerašydami jokios specifikacijos.
Aptikę problemas projektavimo stadijoje, galite jas lengvai sutvarkyti tiesiog pataisydami pora teksto eilučių. Kai kodas jau yra parašytas, problemų tvarkymas atsieina dramatiškai daugiau, tiek emocine prasme (žmonės nemėgsta trinti kodo), tiek ir laiko prasme, todėl net atsiranda nenoras apskritai tvarkyti problemas. Programinė įranga, kuriama be specifikacijos, dažniausiai būna prastai suprojektuota, o darbai atsilieka nuo grafiko. Atrodo, panašią problemą turėjo Netscape, kur pirmosios keturios versijos išaugo į tokią maišatį, jog vadovybė kvailai nusprendė išmesti kodą ir pradėti nuo pradžių. O tada padarė vėl tą pačią klaidą su Mozilla, sukurdami monstrą, ištrūkusį iš kontrolės. Jiems užėmė kelis metus vien prieiti iki alfa stadijos.
Mano mėgstamiausia teorija yra tokia: ši problema gali būti išspresta, nusiunčiant programuotojus į intensyvius rašymo kursus. Kitas sprendimas būtų samdyti gudrius programuotojų vadovus, kurie rašytų specifikacijas. Bet kuriuo atveju, reikėtų įtvirtinti paprastą taisyklę: „jokio programavimo be specifikacijos“.
Daugiau apie specifikacijas galite paskaityti mano 4 dalių serijoje.
Ar programuotojai turi ramias darbo sąlygas?
Egzistuoja plačiai dokumentuota nauda protinio darbo produktyvumui, gaunama suteikiant erdvę, ramybę ir privatumą. Klasikinė programinės įrangos darbo vadovavimo knyga „Peopleware“ išsamiai tai aprašo.
Problema yra čia. Visi žinome, kad protiniai darbuotojai geriausiai dirbą pasinėrę į tam tikrą režimą („flow“), dar žinomą, kaip „zona“, kai jie yra pilnai susikoncentravę į savo darbą ir visiškai atsiriboję nuo aplinkos. Dėl absoliučios koncentracijos jie praranda net laiko pojūtį ir sukuria didžius dalykus. Būtent tokiu metu ir padaromas beveik visas jų produktyvus darbas. Rašytojai, programuotojai, mokslininkai ir net krepšinio žaidėjai jums papasakos apie „buvimą zonoje“.
Tačiau „patekti į zoną“ nelengva. Pabandžius išmatuoti paaiškėja, kad vidutiniškai užima apie 15 minučių kol pradedama dirbti maksimaliu pajėgumu. Kartais, jei esate pavargęs ar tą dieną jau atlikęs daug kūrybinio darbo, tiesiog neįmanoma „patekti į zoną“ ir likusią darbo dieną praleidi darydamas smulkius nereikšmingus darbus, naršydamas internetą, žaisdamas Tetrį.
Kita problema – kad būti išmuštam iš „zonos“ yra labai lengva. Triukšmas, telefonų skambučiai, ėjimas pietauti, važiavimas 5 minutes iki Starbucks kavos ir trukdantys bendradarbiai – ypač trukdantys bendradarbiai – visa tai išmuša iš „zonos“. Jei bendradarbis užduoda Jums klausimą, sutrukdydamas vienai minutei, bet tai išmuša Jus iš įsijautimo ir prireikia pusvalandžio vėl pradėti dirbti pajėgiai, yra rimtų problemų su bendru produktyvumu. Jei esate triukšmingoje turgaus aplinkoje, kaip tos kurias mėgsta kurti kofeinu persisotinę „dotcom'ai“, su marketingo darbuotojais, rėkiančiais į savo telefonus šalia programuotojų, produktyvumas kris, nes programuotojai bus nuolat trukdomi ir niekada nepapuls į „zoną“.
Programuotojams tai ypač sunku. Produktyvumas priklauso nuo gebėjimo vienu metu atmintyje žongliruoti gausybe smulkių detalių. Bet koks sutrukdymas, ir tos detalės gali išsibarstyti. Atnaujinus darbą, nebepavyksta jų prisiminti (pavyzdžiui, vietinių kintamųjų pavadinimai arba kur ketinai pritaikyti tą paieškos algoritmą) ir tenka iš naujo ieškoti tų dalykų, kas visada labai sustabdo darbą ir reikia daug laiko, kol vėl įsivažiuojama.
Štai paprasta algebra. Sakykime (kaip rodo duomenys) kad sutrukdę programuotoją vos vienai minutei, mes realiai sunaikiname 15 minučių produktyvumo. Šiam pavyzdžiui, paimkime du programuotojus, Džefą ir Matą, atviruose kambariukuose šalia viens kito standartinėje Dilberto veršienos penėjimo fermoje. Matas negali prisiminti Unicode versijos, kurią naudoja strcpy funkcija. Jis galėtų pasižiūrėti pats, kas užtruktų 30 sekundžių, arba paklausti Džefo, kas užtrunka 15 sekundžių. Kadangi jis sėdi visai šalia Džefo, jis pasiklausia. Džefas atitraukiamas nuo darbo ir praranda 15 minučių produktyvumo – kad sutaupyti Matui 15 sekundžių.
Dabar perkelkime juos į skirtingus ofisus su sienomis ir durimis. Kai Matas nebeprisimena funkcijos pavadinimo, jis gali pasižiūrėti pats, kas vis dar užima 30 sekundžių, arba gali paklausti Džefo, kas užima 45 sekundes ir reikalauja atsistoti (nelengva užduotis, turint omenyje vidutinio programuotojo fizinę formą!). Taigi, jis pasižiūri pats. Matas prarado 30 sekundžių produktyvumo, bet sutaupė 15 minučių Džefui. Aha!
Ar naudojate geriausią įrangą, kokią galima gauti už pinigus?
Kodo rašymas kompiliuojama kalba yra vienas iš paskutiniųjų dalykų, kurie dar negali būti atliekami žaibiškai kiekviename namų kompiuteryje. Jei Jūsų kompiliavimo procesas užima daugiau, nei kelias sekundes, naujausios ir geriausios tam skirtos programinės įrangos įsigijimas sutaupys laiko. Net jei kompiliavimas teužima 15 sekundžių, tuo metu programuotojai nuobodžiaus ir eis skaityti The Onion, kuris tuomet juos įtrauks valandoms ir nužudys produktyvumą.
GUI kodo redagavimas su vieno monitoriaus sistema yra sunkus arba neįmanomas. Jei rašote GUI kodą, du monitoriai darbą labai palengvins.
Daugumai programuotojų anksčiau ar vėliau prireikia dirbti su bitmaps ikonoms ar įrankių juostoms, ir dažniausiai jie neturi tam gero redaktoriaus. Bandymas naudoti Microsoft Paint yra anekdotas, tačiau tai tenka daryti daugumai programuotojų.
Paskutinėje darbovietėje sistemų administratorius nuolat man siųsdavo nusiskundimus, kad naudoju daugiau, nei ...dėmesio... 220 megabaitų serverio kietojo disko vietos. Aš atkreipiau jam dėmesį, kad turint omenyje šiuolaikines kietųjų diskų kainas, išlaidos šiai sunaudojamai vietai yra gerokai žemesnės, nei mano naudojamam tualetiniam popieriui. Praleisti nors dešimt minučių valant savo katalogus būtų nedovanotinas produktyvumo švaistymas.
Aukščiausio lygio programinės įrangos komandos nekankina savo programuotojų. Net mažiausi nepatogumai, sukeliami prastų programavimo priemonių kaupiasi, daro programuotojus piktus ir nepatenkintus. O piktas programuotojas yra neproduktyvus programuotojas.
Be viso to... programuotojai yra lengvai paperkami, duodant jiems šauniausius, naujausius įrankius. Tai yra žymiai pigesnis būdas išlaikyti juos darbovietėje, nei aukštų atlyginimų mokėjimas!
Ar turite testuotojus?
Jei komanda neturi atskirų testuotojų, bent vieno kiekvieniems dviems – trims programuotojams, Jūs arba parduodate nekokybiškas programas, arba švaistote pinigus, nes 100 dolerių už valandą apmokami programuotojai daro darbą, kurį galėtų atlikti 30 dolerių už valandą apmokamas testuotojas. Šykštavimas testuotojų srityje yra tokia akivaizdžiai klaidinga ekonomika, kad man sunku patikėti jog yra to nesuprantančių.
Paskaitykite Top Five (Wrong) Reasons You Don't Have Testers, atskirą mano straipsnį šia tema.
Ar nauji kandidatai pokalbyje dėl darbo rašo kodą?
Ar samdytumėte iliuzionistą net nepaprašę parodyti savo triukų? Žinoma, ne.
Ar samdytumėte virėją savo vestuvėms net neparagavę jo maisto? Abejoju. (Nebent tai yra Teta Margė, ir ji nekęstų Jūsų amžinai, jei neleistumėte paruošti jos „garsiojo“ pjaustytų kepenų pyrago).
Ir visgi, kiekvieną dieną, programuotojai yra samdomi tik dėl jų įspūdingo CV ar todėl, kad vadovui patiko su jais paplepėti. Arba jiems užduodami banalūs klausimai („koks skirtumas tarp CreateDialog() ir DialogBox()?“), kuriuos galima atsakyti pažiūrėjus į dokumentaciją. Niekam neturėtų rūpėti, ar jie sugeba įsiminti tūkstančius elementarių faktų apie programavimą, rūpėti turėtų, ar jie sugeba rašyti kodą. Arba, dar blogiau, jiems užduodami „AHA!“ klausimai: labai lengvi žinant atsakymą, nežinant atsakyti beveik neįmanoma .
Prašau, nustokit taip elgtis. Darykite pokalbiuose ką norite, bet paprašykite kandidato parašyti šiek tiek kodo. (Daugiau patarimų skaitykite Guerrilla Guide to Interviewing).
Ar atliekate koridorinį naudojamumo testą?
Koridorinis naudojamumo testas („hallway usability test“) yra kai stveriate pirmą pasitaikiusį koridoriumi praeinantį žmogų ir priverčiate jį išbandyti tą ką tik parašytą kodą. Atlikę tai su penkiais žmonėmis, sužinosite 95% visko, ką įmanoma sužinoti apie naudojamumo problemas savo kode.
Geras vartotojo sąsajos dizainas nėra taip sunku, kaip galvojate, ir jis yra ypač svarbus norint, kad klientai mylėtų ir pirktų jūsų produktą. Galite paskaityti mano trumpą internetinę knygą apie GUI (grafinė naudotojo sąsaja).
Bet pats svarbiausias dalykas yra tai, kad parodę savo programą keliems žmonėms, (penki ar šeši yra pakankamai) greitai atrasite, kur yra didžiausios problemos. Jakob Nielsen's straipsnis paaiškina, kodėl. Net jei visai neturite gerų naudotojo sąsajos įgūdžių, Jūsų UI veiks žymiai, žymiai geriau darant koridorinius naudojamumo testus.
Keturi Džoelio testo naudojimo būdai
- Įvertinkite savo programinės įrangos organizaciją ir pasakykite man rezultatą, kad galėčiau paliežuvauti.
- Jei esate programuotojų komandos vadovas, naudokite kaip kontrolinį sąrašą siekdami užtikrinti, kad Jūsų komanda dirba kaip galima geriau. Kai pradėsite surinkti 12 taškų, galėsite palikti programuotojus vienus ir visą laiką skirti užtikrinimui, kad verslininkai prie jų nelįstų.
- Jei bandote apsispresti, ar verta kažkur įsidarbinti programuotoju, paklauskite savo potencialaus darbdavio, koks jų įmonės rezultatas pagal šį testą. Jei jis per mažas, įsitikinkite, kad turėsite autoritetą sutvarkyti šioms problemoms. Kitu atveju nuolat būsite susierzinęs ir neproduktyvus.
- Jei esate investitorius, besistengiantis nustatyti programuotojų komandos vertę, ar jei esate programinės įrangos kompanija ir svarstote susijungimą su kita, šis testas gali suteikti įvertinimą „iš akies“.
