Praeitą savaitę radau įdomų Dan North internetinį video pranešimą iš konferencijos QCon. Persiuntus jį Adform architektams ir Scrum meistrams gavau labai gerų atsiliepimų, kurių vienas buvo „Afigena prezentacija” :D. Taigi, dalinuosi šia nuoroda ir su jumis: http://www.infoq.com/presentations/Simplicity-Architect.
Visos prezentacijos esmė yra paprasta: žmonės linkę ieškoti ir kurti sudėtingus sprendimus, kur daugelyje vietų reikėtų daryti atvirkščiai: kurti kuo paprastesnius sprendimus. Tai ypač taikytina programinės įrangos architektūros sričiai, kur mes sugebame sukurti LABAI sudėtingus sprendimus, nors klientui reikia kažko labai paprasto.
Technologijų „sudėtingėjimo” istorija
Pristatymą Dan pradeda linksma istorija kaip architektai „uždegė šviesą tunelio gale” ir kaip naujos technologijos, vardai, modeliai vystėsi. Tam, kad padaryti elementarią užduotį kartais mes iš inercijos griebiamės šių naujų „vardų” vietoj to, kad pagalvotume ar tikrai šioje vietoje mums to reikia J. Pažiūrėkite patys, tikrai nusišypsosite.
Mes užprogramuoti kurti sudėtingus sprendimus
Toliau Dan kalba jog mes esame tiesiog užprogramuoti kurti sudėtingus sprendimus. Taip veikia mūsų smegenys. Dėl to, mes turėtume nustoti tai neigti, pripažinti jog esame „sudėtingoholikai” ir ieškoti būdų kaip save tikrinti ir keistis. Štai keletas jų.
Kiekvieną kartą kai užstringame prie kokios nors problemos reikėtų nusistatyti laiko tarpą, kurį mes paskirsime šios problemos sprendimui. Tai neleidžia „nukeliauti į lankas” ieškant sudėtingų sprendimų kurių dažniausiai nereikia, o leidžia mums koncentruotis ties mažiausiu ir paprasčiausiu sprendimu, kuris išsprendžia problemą.
Nuolat klausk savęs: „kodėl aš tai darau?”, kad pagautum save pakliuvus į „sudėtingumo spąstus”, t.y. kai norėdamas išspręsti problemą sugalvoji, jog dar reiktų išspręsti kitą problemą. Pradedi spręsti ją ir pamatai, kad reikia išspręsti dar, dar kitą ir t.t. Paklausus savęs, kodėl aš sprendžiu jau ne tą problemą, kaip galiu grįžti prie pirmosios problemos ir išspręsti ją, mes sutaupytume labai daug laiko.
Na ir paskutinis siūlymas: susirasti kolegą arba vonios ančiuką ;) Kai mes mąstome vieni, mes kartais labai lengvai užstringame ties kokia nors užduotimi. Kiek kartų jums nutiko taip: netekęs kantrybės pasikvieti kolegą, pradedi jam aiškinti kas tau nesigauna ir po antro sakinio pasakai: „a, supratau kur problema, nesirūpink, viską pats sutvarkysiu”. Taip yra todėl, jog kai mes ką nors garsiai aiškiname, dirba visai kitos mūsų smegenų dalys. Bet mes negalime su kiekviena maža problema trukdyti kolegų. Tam ir reikia turėti vonios ančiuką šalia. Jei kažkur užstringi, pabandyk problemą paaiškinti pirma ančiukui. Jis tikrai išklausys. O naudingiausia, jog aiškindamas jam, labai dažnai suprasi kaip išspręsti problemą! Pats asmeniškai ančiuko šalia savo kompiuterio neturiu, bet kad kartais garsiai pagalvoju kai kur nors užstingu, tai tikrai.
Spręsti teisingą problemą
Naudodami metodus aprašytus aukščiau mes galime pristabdyti save kurti per daug sudėtingus sprendimus. Tačiau pasirodo mes gan dažnai sprendžiame net ne tą problemą! Pavyzdžiui kalbėdami apie Agile architektūrą dažnai girdžiu, kad reikia kurti lanksčią (flexible), pernaudojamą (reusable) architektūrą. Bet tai veda prie kartais labai sudėtingų sprendimų. Tai ko iš tikrųjų reikia, yra kurti architektūrą kuri yra lengvai keičiama. Agile bendruomenė patikėjo, jog tiksliai numatyti šiandien labai greitai besikeičiančio verslo reikalavimų negalime. Todėl kiekvienos iteracijos metu stengiamės pagaminti pabaigtą produkto dalį. Mes žinome, jog funkcionalumas keisis, todėl architektūra turi būti kuo paprastesnė, ir leidžianti kuo lengviau tuos pokyčius įgyvendinti, nesugriaunant to kas jau sukurta. Taigi pagrindinė mintis kuri turėtų mus lydėti yra: maksimizuoti darbą, kurio nereikia atlikti. Kitais žodžiais tariant, su kuo mažiau darbo ir kuo paprastesniu sprendimu mes galėsime patenkinti kiekvieno produkto prieaugio (increment) reikalavimus, tuo daugiau išlošime. Tiek sutaupant laiko dabar, tiek išvengiant bereikalingo darbo su sudėtinga architektūra ateityje.
Asmeninė patirtis
Man asmeniškai tenka daug bendrauti su Scrum meistrais, architektais, programuotojais, kuriems šios mintys iš pradžių atrodo labai radikalios. „Kaip tai nekurti šito bendro taisyklių valdymo modelio??!! Taip, mes turime tik vieną taisyklę dabar, bet JEIGU ateityje bus jų daugiau?! Žinai kiek laiko tada užtruks jas pridėti!!!” – girdėjau aš ne vieną kartą. Problema ta, kad labai dažnai tas „jeigu” neįvyksta ir mes iššvaistome savo laiką kurdami sudėtingą sprendimą. Dar daugiau, mes išvaistome daug daugiau laiko vėliau jį palaikydami (maintanance). Šiuo pavyzdiniu atveju, produktas gyvena ilgai su ta viena taisykle. Taigi testuojant ar kažką papildomo šalia kuriant, palaikant sistemą tereikia žiūrėti į šį paprastą sprendimą, bet ne į „nerealų, sudėtingą, visoms taisyklėms tinkantį valdymo modelį”. O jeigu mums kada nors vėliau tektų įgyvendinti antrąją taisyklę, tik tada mes perrašome (refactor) šią kodo dalį taip, kad ji lengvai palaikytų daugiau taisyklių. Taigi bendro palaikymo (sudėtingesnio sprendimo) darbus atidedame tam momentui kai jų tikrai reikia. Svarbiausia nepasiduoti pagundai „prilipdyti kaip nors” antrąją taisyklę prie pirmosios, o tvarkingai perrašyti (refactor) šią kodo dalį. T.y. pakeisti architektūrinį sprendimą tada kai reikia jį keisti, o ne tada kai galvojame jog kažkada gali jo prireikti.
Kokios jūsų mintys? Gal kas nors turite daugiau pavyzdžių kaip paprastesnio sprendimo panaudojimas jums palengvino gyvenimą? Ar architektai visada galvoja apie paprasčiausią sprendimą problemai? Galbūt nesutinkate jog jie apie tai turėtų galvoti?