Optimizimi i kodit për performancën njerëzore

Kur e shikojmë kodin nga këndvështrimi i shkencës njohëse dhe dizajnit të ndërfaqes, shohim se shpesh ka një shkëputje midis mënyrës se si shkruhet kodi dhe mënyrës se si njerëzit përpunojnë informacionin. Nga kjo perspektivë, programuesi është përdoruesi përfundimtar - ai me aftësi të kufizuara përpunimi - dhe ai ndryshon mënyrën se si ne shikojmë dhe shkruajmë kodin.

Si të krijojmë një përvojë intuitive për inxhinierin e softuerit, duke ndihmuar në rritjen e xhiros dhe reduktimin e gabimeve?

Gjuhët e programimit, në një masë të madhe, nuk janë vetëm për kompjuterë; ato janë gjithashtu për njerëzit që i përdorin ato. Në fund të fundit, nëse do të shkruanim kodin për kompjuterët, thjesht do të komunikonim në një dhe zero. Kodi na ndihmon të organizojmë mendimet tona, t'i shprehim ato qartë dhe t'i ndajmë me përpiluesin tonë dhe me të tjerët.

Shkenca konjitive na tregon se një përqindje e madhe e gabimeve të kodimit janë rezultat i "ngarkesës së lartë njohëse", organizimit të dobët dhe komunikimit joefektiv. Për më tepër, është e qartë se programuesi është zakonisht burimi i këtyre gabimeve të kodimit. Në zhvillimin e softuerit, ne mund të optimizojmë për shpejtësinë llogaritëse, fleksibilitetin dhe ripërdorimin, ose stabilitetin e programit; megjithatë pak theks është vënë në optimizimin e performancës njerëzore. Duke i vënë një theks më të madh këtij elementi, mund të jetë e mundur të arrihen përfitime të konsiderueshme në lehtësinë e përdorimit, shpejtësinë e zbatimit, ripërdorimin e kodit dhe një reduktim të përgjithshëm të gabimeve.

Psikologjia inxhinierike - O e madhe për trurin e njeriut

Kur një raketë ose anije kozmike është gati të përplaset me një objekt tjetër, një sirenë me zë të lartë aktivizohet, duke ndryshuar ekuipazhin e anijes kozmike të vdekjes së tyre të afërt. Të paktën, kjo është ajo që mësojmë nga shikimi i filmave. Por në të vërtetë, shpjegojnë studiuesit e NASA-s, një zhurmë e madhe ka të ngjarë të rezultojë në katastrofë dhe vdekje. Një zhurmë e madhe prodhon një përgjigje befasuese, e cila mund të rezultojë në një vonesë prej tre sekondash përpara se truri të jetë në gjendje të përpunojë informacionin. Në të kundërt, një tingull i butë dhe qetësues paralajmëron pilotin dhe ekuipazhin se anija është gati të rrëzohet, duke u dhënë kështu atyre kohë për të reaguar. - Shkencëtari njohës, Dr. Robert Cooper

Shkencëtarët kanë arritur të dinë shumë për mënyrën se si funksionon truri dhe si të optimizojnë performancën njerëzore. Në NASA Ames, shkencëtarët në fushën e Psikologjisë Inxhinierike eksplorojnë aftësitë dhe kufizimet e trurit të njeriut. Pse? Sepse është e keqe kur rrëzon një anije kozmike shumë miliardë dollarëshe.

Në psikologjinë inxhinierike (një degë e shkencës njohëse), ne fillojmë me supozimin se truri është një kompjuter. Kur shikojmë një programues nga ky këndvështrim, nuk është ndryshe nga shikimi i një kompjuteri me aftësi të kufizuar përpunimi dhe RAM. Truri i njeriut përbëhet nga njësi të ndryshme të përpunimit dhe ne shohim ndërrimin e shumë detyrave, ndërlidhjes me shumë fije dhe kujtesës; si dhe hyrjet e përdoruesve, thirrjet në rrjet, thirrjet e ndërlidhura dhe problemet e bashkërendimit/sinkronizimit.

Si programues, ne e kuptojmë se sa komplekse dhe të prirur për gabime mund të jenë këto sisteme; dhe që futja e të dhënave duhet të jetë në një format me të cilin sistemi mund të punojë dhe të kuptojë. Kështu, ne mund të pyesim, “Nëse truri i njeriut është një kompjuter, atëherë si ta optimizojmë këtë kompjuter për besueshmërinë, qëndrueshmërinë e programit ose performancën? Si ta maksimizojmë xhiron dhe të minimizojmë gabimin?”

Për shembull, kur truri i njeriut nuk ka burime të mjaftueshme për të kryer një detyrë, është si të përpiqesh të lundrosh në internet në një iPhone I. Kjo do të thotë, detyrat me ngarkesë të lartë njohëse mund të mbitaksojnë burimet e kufizuara të sistemit, duke rezultuar në përpunim ose gabimet e kujtesës. Një shembull i një detyre me ngarkesë të lartë njohëse është shtimi i faturës suaj ushqimore në kokën tuaj. Shtimi i dy numrave është i lehtë, por shtimi i pesëdhjetë artikujve ushqimorë nuk është shumë argëtues.

Në shkencën kompjuterike, ne matim rregullisht se sa kohë i duhet një kompjuteri për të kryer një proces llogaritës, duke përdorur një shënim matematikor të quajtur «"Big O."" Duket si një hap tjetër i natyrshëm për të pyetur se sa zgjat ai. i duhet trurit të njeriut për të kryer një detyrë dhe sa stres u jep burimeve të sistemit - "ngarkesa njohëse". Më pëlqen ta quaj këtë "O i madh" për trurin e njeriut.

Për ta ilustruar këtë në terma laikë, le të shohim dy metodat e mëposhtme. Sa kohë duhet për të skanuar metodën e parë dhe për të gjetur rreshtin e parë të kodit? Sa kohë duhet për të identifikuar ndryshimin midis dy metodave tona?

Si rregull i përgjithshëm, sa më shumë që përdoruesi pritet të përpunojë, të mbajë mend ose të dijë, aq më e madhe është ngarkesa njohëse, aq më i ulët është xhiroja dhe aq më i madh është probabiliteti i gabimit.

Shkencëtarët njohës kanë kryer studime të shumta duke shqyrtuar korrelacionin midis gjërave të tilla si "formatimi dhe pozicioni i tekstit" dhe "koha e përvetësimit të objektivit", duke parë gjithçka nga kampionimi vizual dhe zbulimi i sinjalit tepërpunimi kognitiv strategjitë. Për shembull, nëse do të kërkonim një shkronjë në një fushë me shkronja të tjera, truri do të përdorë një "progresion linear kërkimi", duke kontrolluar një shkronjë pas tjetrës derisa të gjendet e sakta.

Për një programues kompjuteri, kjo analizë duket befasuese e njohur (është identike me atë të një kërkimi bazë përmes një grupi elementësh të pazgjedhur). Në këtë mënyrë, ne shohim se si shkencëtarët njohës janë në gjendje të analizojnë performancën njohëse ashtu si programuesit analizojnë performancën e softuerit.

Ne dimë shumë për mënyrën se si truri përpunon informacionin. Kjo është përdorur mirë në dizajnimin e sistemeve të kontrollit të trafikut ajror, ekraneve të kabinës së kabinës dhe ekraneve të drejtimit në avionët luftarakë. Prandaj, ne mund të pyesim, “Nëse i qasemi kodimit nga një këndvështrim njohës, si do të ndryshonte mënyra se si ne shkruanim kodin dhe sa i ndryshëm do të ishte kodi ynë?”

Sfidat moderne të programimit takohen me proceset e lashta të trurit

Një sfidë e kodit: Ajo që filloi si një proces i thjeshtë që çdo fëmijë mund të shpjegonte u shndërrua në një program konfuz me pika të shumta hyrjeje, logjikë komplekse të gjendjes, pa sekuencë ngjarjesh të përcaktuara qartë, bllok të ndërlidhur dhe thirrje delegate. Kjo do të thotë, ndërsa programi u rrit në madhësi dhe kompleksitet, mbajtja e gjurmëve se kush po bën çfarë dhe çfarë ndodh më pas u bë shumë sfiduese. Ajo mbingarkoi "kujtesën e punës" të studentit. Njerëzit kanë kapacitet të kufizuar njohës. - një vëzhgim nga koha ime duke punuar në një Mobile Makers (një kamp nisjeje për iOS)

Mungesa e organizimit dhe logjikës së qartë brenda shumë aplikacioneve softuerike sugjeron se ka një shkëputje midis mënyrës se si shkruhet kodi dhe mënyrës se si njerëzit përpunojnë informacionin. Kjo nuk është vetëm një çështje e komunikimit të dobët. Gjuhët moderne të programimit zëvendësuan komandat goto me unaza, dhe programimi i orientuar nga objekti e këmbeu shpejtësinë me organizimin, duke u mundësuar inxhinierëve të softuerit të ndërtonin programe me shkallë dhe kompleksitet tronditës. Megjithatë, tendencat moderne në zhvillimin e celularëve – duke përfshirë thirrjet asinkrone dhe përvojën e drejtuar nga përdoruesit – kanë minuar pjesën më të madhe të organizimit dhe fluksit të kontrollit të gjuhëve moderne të strukturuara. Në veçanti, mund të vërejmë se:

· Hyrja e përdoruesit fillon sekuenca të ndryshme, duke na dhënë një rrjetë merimangash të gjendjeve dhe ngjarjeve, në të cilat duhet të nxirret logjika gjithëpërfshirëse.

· Proceset e thjeshta lineare (për shembull, duke shtuar njoftime në aplikacionin tuaj) ndahen në një seri komplekse thirrjesh delegate të ndarë, ndërsa presim që të ndodhin ngjarje të ndryshme.

· Kodi shpesh ndahet në objekte dhe blloqe të cilat nuk janë të lidhura ngushtë, por mbajnë një rrjet varësish logjike, duke i bërë ato të vështira për t'u kuptuar dhe përdorur.

· Thirrjet e bllokuara të ndërlidhura, që shihen shpesh në telefonatat në rrjet ose animacionet, janë të vështira për t'u lexuar; ata shpërfillin shtrirjen e duhur; dhe shkelin parimin e përgjegjësisë së vetme (duke e zbatuar atë në metoda, si dhe në klasa). Çdo metodë duhet të ketë një përgjegjësi të vetme dhe ajo duhet të tregohet qartë në emrin e metodave.

Në fakt, nëse do t'i kërkonim një profesori të anglishtes - një ekspert në komunikimin me shkrim - të vlerësonte një projekt iOS, ai ka të ngjarë të komentonte, “Ju lutemi rishkruani. Mungon përmbledhja dhe përfundimi. Vështirë për t'u ndjekur. Mungojnë logjika dhe tranzicionet. Përdorimi jo standard i anglishtes. Ka nevojë për paragrafimin e duhur. Asnjë organizim i qartë.” Kështu, duke sjellë një sërë pyetjesh interesante në lidhje me modelet e projektimit, strukturën bazë logjike të një aplikacioni dhe gjuhët e programimit të dizajnit.

Një herë shkrova një lojë me zare me shumë lojtarë si një lak me një komandë pritjeje, në mënyrë që të ilustroj se sa e thjeshtë dhe e qartë mund të thuhet logjika e programimit.

Në të kundërt, kur isha mësues dhe ua caktova këtë sfidë studentëve, kodi i tyre ishte shpesh i vështirë për t'u ndjekur ose krejtësisht i pakuptueshëm. Zemra e problemit dukej se ishte koncepti i asinkronitetit; ne duhet të presim për diçka - qoftë kjo një telefonatë në rrjet apo një shtypje e butonit - përpara se të vazhdojmë. Kjo mund të bëjë kërdi me kodin e strukturuar mirë.

Pyetjet që dua të parashtroj janë,

· “A është ajo që shohim këtu një përshtatje e nevojshme me kërkesat e një rrjeti kompjuterik dhe përvojën e drejtuar nga përdoruesit, apo është thjesht një kod i keq?”

· "A është kjo thjesht një çështje e standardeve të dobëta të dokumentacionit dhe komunikimit në mbarë industrinë?"

Së paku, është e rëndësishme të përfshihen artefakte bazë që shpjegojnë organizimin logjik. Dokumentacioni, vetëm një shpjegim i shpejtë, foto ose skicë, duhet të tërhiqet zvarrë dhe të hidhet në vetë projektin - jo të vendoset në një vend ku askush nuk do ta shohë kurrë atë. Kjo është ajo që Agile Development është mbi të gjitha.

Në afat të gjatë mund të jetë e nevojshme të strukturojmë dhe organizojmë kodin tonë në mënyra të reja. Kjo është pjesë e një procesi natyror evolucionar. Për shembull, programimi i orientuar nga objekti tregtoi performancën e kompjuterit për përdorshmërinë dhe Ruby tregtoi sigurinë e tipit për një ndërfaqe më intuitive.

Vendosja e gjërave në praktikë

Në një studim të kryer në NASA, tetë ekuipazhe ajrore simuluan fluturimin në Aeroportin Ndërkombëtar të Los Anxhelosit me leximet e instrumenteve të tyre të fluturimit të projektuara drejtpërdrejt në xhamin e përparmë përpara tyre. Në një gjyq, ata u përballën papritmas me një avion të ulur në pistë, një situatë që kërkon një xhiro. Vetëm dy pilotë e vunë re avionin dhe fluturuan në rrotull, ndërsa gjashtë do të ishin përplasur me aeroplanin. "Ata po e tërheqin vëmendjen e tyre në ekranin ballor në kurriz të shikimit nga dritarja," thotë Jordan. "Këto janë çështje mjaft të rëndësishme." - Financimi i kërkimit për faktorin njerëzor Psikologji: Profesor Kevin Jordan fiton 73 milion dollarë Grant Kërkimor të NASA-sSJSU ScholarWorks, 2012, Together, Nr. 2

Në karrierën time të mëparshme si mësues matematike dhe filozofie si në Rusi ashtu edhe në Kinë, mësova shumë rreth xhiros dhe gabimeve. Si e maksimizoni xhiron? Si e minimizoni gabimin? Si e menaxhoni ngarkesën njohëse përmes komunikimit efektiv, organizimit, sekuencës dhe ritmit, në mënyrë që edhe studentët me vështirësi të mund të zotërojnë llogaritjen?

Kur shikoj një pjesë të kodit të softuerit, pyes veten: "Sa nga ish-studentët e mi do ta kuptonin këtë kod në leximin e parë?" Sa do të kishin pyetje? Sa prej tyre do të ngatërroheshin se si të zbatonin saktë një klasë ose metodë?

Një strategji për reduktimin e ngarkesës njohëse është ndarja e gjërave në komponentë më të vegjël. Si rregull, nëse duhet të punoni "vërtet shumë" për të kuptuar një pjesë komplekse të kodit, atëherë duhet të pyesim nëse ka një mënyrë për të zvogëluar kompleksitetin. Një cikli i mbivendosur për, për shembull, mund të rishkruhet si një cikli "for", i cili bën thirrje për një metodë ndihmëse që përmban ciklin e dytë.

Një strategji tjetër për reduktimin e ngarkesës njohëse është përdorimi i metodave të qarta, të paqarta dhe emrave të variablave, duke ndjekur rregullat e pranuara të gramatikës angleze. Kur gjërat thuhen qartë dhe thjesht, ato janë të lehta për t'u mbajtur mend dhe për t'u ndjekur.

Shkrimi i një kodi të mirë dhe vetë-dokumentues është shumë si shkrimi i një eseje kolegji, dhe fillon me bazat. “Çdo metodë është një paragraf. Emri i çdo metode është një fjali temë. Përdorni përdorimin e duhur të fjalëve, jo zhargon. Ndani blloqet e gjata të plotësimit ose kodin e mbivendosur në metodat e tyre - domethënë, përdorni paragrafët dhe ndarjet në mënyrë që të ndani idetë në copa dhe të theksoni pikat e spikatura. Sigurohuni që struktura logjike themelore të jetë e qartë. Mos harroni të shtoni komente për të ofruar kontekst të mjaftueshëm që lexuesi të kuptojë saktësisht se çfarë bën, çfarë nuk bën, për çfarë shërben dhe si ta përdorë atë.” Kodi ka të bëjë me komunikimin, është ai. për të kujtuar se kush është audienca jonë.

Në mënyrë analoge, ne mund t'i shohim modelet e projektimit si struktura organizative që nxisin përdorimin dhe konsumin njerëzor.Në zhvillimin e softuerit, ne përdorim modele dizajni për të menaxhuar kompleksitetin dhe për të promovuar fleksibilitetin dhe ripërdorimin. (OO, MVC, delegimi, fabrikat, parimet e dizajnit SOLID, etj.) Por menaxhimi i kompleksitetit është shpesh vetëm një mënyrë tjetër për të thënë reduktimin e ngarkesës njohëse. Ne duam të promovojmë fleksibilitet dhe të mbajmë kodin DRY sepse mund të dëshirojmë të bëjmë rishikime një ditë. Sidoqoftë, nuk duhet të kërkojmë të eliminojmë ngarkesën njohëse, sepse shumë detyra kërkojnë sofistikim. Në vend të kësaj, ne duhet të përpiqemi të shmangim kompleksitetin e panevojshëm që mund të rezultojë në gabim, dhe të përdorim modele të projektimit për të ndërtuar ndërfaqe intuitive me të cilat truri mund të punojë dhe kuptojë lehtësisht.

Ndërtimi i anijeve raketore

Mund të mësojmë shumë rreth asaj se si të optimizojmë performancën njerëzore, por ndoshta duhet të fillojmë duke u përpjekur të shkruajmë kod të bukur, ose të paktën kod të mirë, vetëdokumentues. Në standardet e tij të kodimit, Laboratori Jet Propulsion i NASA-s shpjegon se:

Rrjedha më e thjeshtë e kontrollit përkthehet në aftësi më të forta për analizat njerëzore dhe ato të bazuara në vegla dhe shpesh rezulton në përmirësim të qartësisë së kodit. Kodi kritik i misionit nuk duhet të jetë vetëm në mënyrë të diskutueshme, por i parëndësishëm. …kodi duhet të shkruhet që të jetë lehtësisht i kuptueshëm nga çdo zhvillues kompetent, pa kërkuar përpjekje të konsiderueshme për të rindërtuar proceset e mendimit dhe supozimet e zhvilluesit origjinal. — Standardi i kodimit institucional JPL për gjuhën e programimit C

Ndërsa ne nuk po ndërtojmë anije raketash, Psikologjia Inxhinierike është një temë e denjë studimi, duke na dhënë njohuri të rëndësishme se si të optimizojmë performancën njerëzore. Kur vlerësojmë kodin për sa i përket përvojës dhe njohjes së përdoruesit, ai fillon të ndryshojë mënyrën se si shkruajmë kodin. "Sa gabime do të prisnit të gjenit nëse do të kishit njëqind përdorues dhe sa do të ishte kostoja për sa i përket orëve të punës?" Është nëpërmjet organizimit efektiv, reduktimit të ngarkesës njohëse dhe komunikimit të qartë të të dhënave dhe strukturave organizative që ne mund të maksimizojmë xhiros dhe të minimizojmë gabimet, duke promovuar lehtësinë e përdorimit, shpejtësinë e zbatimit dhe ripërdorimin e kodit.

Mychilo Cline është një zhvillues iOS në CapitalOne dhe ka një diplomë të diplomuar në Ndërveprimin Njerëz-Kompjuter / Teknologji dhe Shoqëri, duke u fokusuar në: Faktorët Njerëzor. Metodologjitë e Kërkimit, Modelet e Ndërveprimit Njerëzor dhe Kërkesat e Përdoruesit Fundor. Social-Inxhinieria në komunitetet online. Modelet antropologjike dhe historike në adoptimin e teknologjive të reja.

Për më shumë mbi API-të, burimin e hapur, ngjarjet e komunitetit dhe kulturën e zhvilluesve në Capital One, vizitoni DevExchange, portalin tonë të zhvilluesve me një ndalesë. https://developer.capitalone.com/