Sėdėdamas ir žiūrėdamas eilinę prezentaciją apie Javascript ir accessibility YDN teatre prisiminiau mintį: programuotojai nemėgsta usability, nes reikia rašyti daug if‘ų. Užsimąsčiau apie tai, kad programuotojo darbas susideda iš labai daug balansavimo.

Taigi, tam, kad sukurti pakankamai patogų interfeisą, reikia rašyti daug kodo eilučių. Tai natūraliai turi įtakos veikimo greičiui. Tam, kad sistema veiktų greitai, kartais tenka aukoti funkcionalumą, o kartais tenka rašyti visiškai nesuprantamą galvosūkį keistų simbolių, kurių net patyrę programuotojai nesupranta. Tam, kad kodas būtų lengvai skaitomas ir nekeltų daug problemų, kai reikia jį tvarkyti, tenka aukoti kitus dalykus, pvz. tą patį accessibility. Kad padaryti kažką arčiau tobulumo, tenka sugaišti begalybę laiko ir pinigų, ir tada atsiranda problema su tais, kas užsakinėja muziką.

Žiūrint prezentacijas, įvairūs specialistai vis kartoja savo srities mantras – “daryk taip ar anaip, ir sutaupyk trečdalį sekundės siuntimo laiko”, “agile procesas sako, kad nereikia per daug laiko skirti planavimui”, “user centered procesas sako, kad reikia skirti pakankamai laiko vartotojų tyrimams ir pasiruošimui”. Dar anądien ir pats norėjau parašyti blog’ą apie tai, kaip paprasta naudojant naujus HTML5 atributus ir elementarias “geriausias praktikas” suprogramuoti patvirtinimo dialogą, kuris veikia visose situacijose, įdedant “vos keletą eilučių daugiau” kodo (gal ir parašysiu kada kai bus gera nuotaika).

Atmetus seną gerą taisyklę, kad iš “gerai”, “pigiai” ir “greitai” galima pasirinkti tik du, aš savo kasdieniame darbe, kodą rašau remdamasis maždaug tokiais principais:

0. Kodo grožis – žr. paskutinį punktą šiame sąraše.
1. Produkto patogumas – aš linkęs paaukoti labai daug kitų dalykų tam, kad galutinis rezultatas patenkintų galutinį vartotoją – ar tai būtų klientas, ar kitas programuotojas naudojantis mano API.
2. Minimalizmas – jeigu kažko galima nedaryti – aš padarysiu viską, kad to nedaryti. Šitas principas iš esmės paaiškina du žemiau esančius punktus. Papildoma taisyklė – blogas programuotojas tas, kuris nėra tinginys.
3. Palaikymo kaina – iš esmės susiveda į tai, kad reikia rašyti mažiau kodo ir reikia jį organizuoti kuo mažesniais, suprantamais gabaliukais. Visa tai galutiniam rezultate reiškia a) mažiau šansų vabaliukams b) lengviau suvokti. Be abejo, sutrauktas ir minimalizuotas kodas nereiškia, kad jis yra lengviau suprantamas ar palaikomas (čia ypač tinka kalbant apie tokius dalykus kaip visa Perl kalba, regex arba LINQ) – šis principas yra iš esmės narciziškas ir remiasi į tai, kad atėjęs kitas žmogus nesugadins veikiančio dalyko.
4. Sukūrimo kaina / produktyvumas – šis punktas yra skiriamoji linija – dėl visko, kas yra aukščiau jo, aš linkęs aukotis ir sėdėti viršvalandžius. O kalbant apie tai, kas yra žemiau jo, tai tikėtinas variantas yra, kad aš paliksiu @todo žymeles.
5. Standartai, best practices ir “teisingumas” – šis principas anksčiau būdavo gerokai aukščiau šiame sąraše – turbūt dėl to dabar dėl tokių dalykų nebereikia jaudintis, nes jie ateina natūraliai. Tiesiog, įvertindamas kitus faktorius mieliau pasirinksiu paprastumą vietoj devynaukščio objektinio dizaino pattern‘o. “Teisingumas” šiuo požiūriu reiškia puritoniškumą ir naivų idealo siekimą, o ne tiesiog “veikiantį kodą”.
6. Accessibility – iš dalies čia truputį gėda. Iš kitos pusės, lygiai kaip ir su standartais ir “teisingumu” – tiesiog esu įpratęs padaryti tam tikrą kiekį šito darbo automatiškai ir nesistengdamas, o daugiau papildomų pastangų tam nededu, nes jos daugiau kainuoja, negu duoda naudos.
7. Plečiamumas – praktiškai niekada nededu papildomų pastangų vien tam, kad patenkinti vidinį spirgėjimą “o jeigu netyčia prireiktų padaryti XYZ” – net jeigu ateityje nepavyksta padaryti chirurgiškai tikslaus, vienos kodo eilutės dydžio, įpjovimo tam, kad sukurti papildomų funkcijų, susumavus vistiek išeina tiesiog pigiau refactorinti ar net perrašyti.
8. Veikimo greitis – čia nekalbu apie varotojo suvokimą/įsivaizdavimą apie interfeisą – daugiau apie realius CPU/atminties resursus. Manau, kad geriausia yra žinoti tobulintinus dalykus, tačiau pasitenkinti tiesiog “gerais programavimo įpročiais” tol, kol nereikia to tvarkyti. O kai prisireikia tvarkyti – visų pirma gerai pamatuoti!
9. Kodo grožis – paminėjau šitą dalyką pirmu numeriu, tačiau labai retai darau taip, kad kodas atrodytų “gražus”. Grožis yra subjektyvus, o patenkinus visus aukščiau esančius reikalavimus, kodas pats savaime atrodo gražus.

Dabar kai jau surašiau juodu ant balto klaviatūra į ekraną, viskas atrodo taip akivaizdu… Ką praleidau? Kokia jūsų prioritetų tvarka?