Artikulu hau itzulpen bat da . Baina bere aurretik aurkezpen txiki bat. Nola sortzen dira zonbiak? Bakoitzak lagun edo lankide bat bere mailara eraman nahi duen egoera batean sartu zen, baina ez du funtzionatzen. Eta ez da zurekin baino harekin βez du funtzionatzenβ: eskalaren alde batean soldata normala, zereginak eta abar, eta bestean, pentsatu beharra. Pentsatzea desatsegina eta mingarria da. Azkar amore ematen du eta kodea idazten jarraitzen du garuna batere piztu gabe. Imajinatzen duzu zenbat ahalegin behar den ikasitako ezintasunaren oztopoa gainditzeko, eta ez duzu egiten. Horrela sortzen dira zonbiak, antza, senda daitezkeenak, baina badirudi inork ez duela egingo.
Hori ikusi nuenean (bai, testu liburuetako kamarada bera) eta ez du txostenik egiten, galdera-erantzun saioa baizik, kontu handiz ibili nintzen. Badaezpada, Leslie zientzialari ospetsua da, konputazio banatuan oinarrizko lanen egilea, eta LaTeX - "Lamport TeX" hitzeko La hizkiekin ere ezagutu dezakezu. Bigarren faktore kezkagarria bere eskakizuna da: etortzen den orok (erabat doan) bere txosten pare bat entzun behar ditu aldez aurretik, gutxienez galdera bat egin eta gero etorri. Lamport-ek bertan emititzen zuena ikustea erabaki nuen, eta bikaina da! Hain zuzen, gauza hori da, zonbiak sendatzeko lotura-pilula magikoa. Ohartarazten dizut: testutik, metodologia super-malguen zaleak eta idatzitakoa probatzea gustuko ez dutenak nabarmen erre daitezke.
Habrokat ondoren, hain zuzen ere, mintegiaren itzulpena hasten da. Gozatu irakurtzen!
Zeregin egiten duzun edozein dela ere, beti hiru urrats egin behar dituzu:
- erabaki zein helburu lortu nahi duzun;
- erabaki nola lortuko duzun zure helburua;
- etorri zure helburura.
Hau programazioan ere aplikatzen da. Kodea idazten dugunean, honako hauek egin behar ditugu:
- programak zer egin behar duen erabaki;
- bere zeregina nola bete behar duen zehaztea;
- idatzi dagokion kodea.
Azken urratsa, noski, oso garrantzitsua da, baina gaur ez dut horretaz hitz egingo. Horren ordez, lehenengo biak eztabaidatuko ditugu. Programatzaile bakoitzak lan egiten hasi aurretik egiten ditu. Ez zara idazten eseri nabigatzaile bat edo datu-base bat idazten ari zaren erabaki ezean. Helburuaren ideia jakin bat egon behar da. Eta behin betiko pentsatzen duzu programak zer egingo duen zehazki, eta ez idatzi nolabait kodea nolabait arakatzaile bihurtuko den itxaropenarekin.
Nola gertatzen da zehazki kode-pentsamendu hau? Zenbat ahalegin egin behar dugu honetan? Guztia konpontzen ari garen arazoaren konplexutasunaren araberakoa da. Demagun akatsekiko tolerantzia duen sistema banatu bat idatzi nahi dugula. Kasu honetan, gauzak ondo pentsatu beharko genituzke kodean eseri aurretik. Zer gertatzen da aldagai oso bat 1ean handitu behar badugu? Lehen begiratuan, hemen dena hutsala da, eta ez da pentsatu behar, baina gero gogoratzen dugu gainezka egin daitekeela. Horregatik, arazo bat sinplea ala konplexua den ulertzeko ere, lehenik pentsatu behar duzu.
Aldez aurretik arazoari irtenbide posibleei buruz pentsatzen baduzu, akatsak saihestu ditzakezu. Baina horrek zure pentsamendua argia izatea eskatzen du. Hori lortzeko, zure pentsamenduak idatzi behar dituzu. Asko gustatzen zait Dick Guindonen aipua: "Idazten duzunean, naturak erakusten dizu zein nahasia den zure pentsamendua". Idazten ez baduzu, pentsatzen ari zarela bakarrik pentsatzen duzu. Eta zure pentsamenduak zehaztapen moduan idatzi behar dituzu.
Zehaztapenek funtzio asko betetzen dituzte, batez ere proiektu handietan. Baina horietako bati buruz bakarrik hitz egingo dut: argi pentsatzen laguntzen digute. Argi pentsatzea oso garrantzitsua eta nahiko zaila da, beraz, hemen edozein laguntza behar dugu. Zein hizkuntzatan idatzi behar ditugu zehaztapenak? Oro har, hau da beti programatzaileentzako lehen galdera: zein hizkuntzatan idatziko dugun. Ez dago erantzun zuzen inor: konpontzen ari garen arazoak askotarikoak dira. Batzuentzat, TLA+ nik garatu dudan zehaztapen-lengoaia da. Beste batzuentzat, erosoagoa da txinera erabiltzea. Dena egoeraren araberakoa da.
Garrantzitsuagoa da beste galdera bat: nola lortu pentsamendu argiagoa? Erantzuna: Zientzialariek bezala pentsatu behar dugu. Azken 500 urteotan frogatu den pentsamolde bat da. Zientzian, errealitatearen eredu matematikoak eraikitzen ditugu. Astronomia izan zen agian lehen zientzia hitzaren zentzu hertsian. Astronomian erabiltzen den eredu matematikoan, zeruko gorputzak masa, posizioa eta momentua duten puntu gisa agertzen dira, nahiz eta errealitatean oso objektu konplexuak diren mendiak eta ozeanoak, mareak eta mareak dituztenak. Eredu hau, beste edozein bezala, zenbait arazo konpontzeko sortu zen. Teleskopioa nora zuzendu behar den zehazteko oso ona da planeta bat aurkitu behar baduzu. Baina planeta honetako eguraldia aurreikusi nahi baduzu, eredu honek ez du funtzionatuko.
Matematikak ereduaren propietateak zehazteko aukera ematen digu. Eta zientziak erakusten du nola erlazionatzen diren propietate horiek errealitatearekin. Hitz egin dezagun gure zientziaz, informatikaz. Lan egiten dugun errealitatea mota askotako sistema informatikoak dira: prozesadoreak, joko kontsolak, ordenagailuak, programak exekutatzeko, etab. Programa bat ordenagailuan exekutatzen ari naizela hitz egingo dut, baina, oro har, ondorio guzti hauek edozein sistema informatikori dagozkio. Gure zientzian, hainbat eredu erabiltzen ditugu: Turing makina, partzialki ordenatutako gertaera multzoak eta beste asko.
Zer da programa bat? Hau independentean kontuan har daitekeen edozein kodea da. Demagun arakatzaile bat idatzi behar dugula. Hiru zeregin egiten ditugu: erabiltzailearen programaren ikuspegia diseinatzen dugu, ondoren programaren goi-mailako diagrama idazten dugu eta azkenik kodea idazten dugu. Kodea idaztean, testu formateatu bat idatzi behar dugula konturatzen gara. Hemen berriro hiru arazo konpondu behar ditugu: zehaztu zer testu itzuliko duen tresna honek; hautatu formateatzeko algoritmo bat; kodea idatzi. Zeregin honek bere azpiataza du: zuzen txertatu marratxo bat hitzetan. Azpizeregin hau hiru urratsetan ere ebazten dugu; ikus dezakezun bezala, maila askotan errepikatzen dira.
Azter dezagun zehatzago lehen urratsa: programak zein arazo konpontzen duen. Hemen, gehienetan programa bat sarrera batzuk hartzen eta irteera batzuk sortzen dituen funtzio gisa modelatzen dugu. Matematikan, funtzio bat bikote multzo ordenatu gisa deskribatu ohi da. Adibidez, zenbaki naturalen koadratze-funtzioa {<0,0>, <1,1>, <2,4>, <3,9>, β¦} multzo gisa deskribatzen da. Funtzio horren domeinua bikote bakoitzaren lehen elementuen multzoa da, hau da, zenbaki naturalak. Funtzio bat definitzeko, bere esparrua eta formula zehaztu behar ditugu.
Baina matematikan funtzioak ez dira programazio lengoaietako funtzioak bezalakoak. Matematika askoz errazagoa da. Adibide konplexuetarako astirik ez dudanez, har dezagun soil bat: C-ko funtzio bat edo bi zenbaki osoren zatitzaile komun handiena itzultzen duen Java-ko metodo estatiko bat. Metodo honen zehaztapenean, idatziko dugu: kalkulatzen GCD(M,N) argudioetarako M ΠΈ NNon GCD(M,N) - bere domeinua zenbaki osoen multzoa den funtzio bat, eta itzulera balioaz zatigarria den zenbaki osorik handiena da. M ΠΈ N. Nola erlazionatzen da eredu hau errealitatearekin? Ereduak zenbaki osoekin funtzionatzen du, C edo Javan, berriz, 32 bitekoa dugu int. Eredu honek algoritmoa zuzena den erabakitzeko aukera ematen digu GCD, baina ez ditu gainezka akatsak saihestuko. Horrek eredu konplexuagoa beharko luke, denborarik ez dagoen horretarako.
Hitz egin dezagun funtzio batek eredu gisa dituen mugei buruz. Programa batzuek (adibidez, sistema eragileak) ez dute balio jakin bat itzultzen argumentu jakin batzuentzat, etengabe exekutatu daitezke. Gainera, eredu gisa funtzioa ez da ondo egokitzen bigarren urratserako: arazoa nola konpondu planifikatzea. Sailkapen azkarrak eta burbuila ordenak funtzio bera kalkulatzen dute, baina algoritmo guztiz desberdinak dira. Hori dela eta, programaren helburua nola lortzen den deskribatzeko, beste eredu bat erabiltzen dut, deitu dezagun portaera eredu estandarra. Bertan dagoen programa jokabide onargarri guztien multzo gisa irudikatzen da, eta horietako bakoitza, aldi berean, egoera-segida bat da, eta egoera aldagaiei balioak esleitzea da.
Ikus dezagun Euklides algoritmoaren bigarren urratsa nolakoa litzatekeen. Kalkulatu behar dugu GCD(M, N). Hasieratzen dugu M gisa xEta N gisa y, ondoren, behin eta berriz, aldagai hauetatik txikiena kendu handiagoari berdindu arte. Adibidez, bada M = 12Eta N = 18, portaera hau deskriba dezakegu:
[x = 12, y = 18] β [x = 12, y = 6] β [x = 6, y = 6]
Eta baldin badago M = 0 ΠΈ N = 0? Zero zenbaki guztiekin zatigarria da, beraz, kasu honetan ez dago zatitzailerik handiena. Egoera honetan, lehen urratsera itzuli eta galdetu behar dugu: benetan GCD kalkulatu behar al dugu zenbaki ez positiboetarako? Hau beharrezkoa ez bada, orduan zehaztapena aldatu besterik ez duzu behar.
Hemen digresio txiki bat egin beharko genuke produktibitateari buruz. Askotan egunean idatzitako kode lerro kopuruan neurtzen da. Baina zure lana askoz ere erabilgarriagoa da lerro kopuru jakin bat kentzen baduzu, akatsetarako leku gutxiago duzulako. Eta kodea kentzeko modurik errazena lehen urratsa da. Guztiz posible da inplementatzen saiatzen ari zaren kanpai eta txistu guztiak behar ez izatea. Programa bat sinplifikatzeko eta denbora aurrezteko modurik azkarrena egin behar ez diren gauzak ez egitea da. Bigarren urratsa denbora aurrezteko bigarren potentziala da. Produktibitatea idatzitako lerroen arabera neurtzen baduzu, zeregin bat nola bete pentsatzeak eragingo zaitu gutxiago produktiboa, arazo bera kode gutxiagorekin konpondu dezakezulako. Hemen ezin dut estatistika zehatzik eman, ez baitut idatzi ez ditudan lerro kopurua zenbatu ahal izateko zehaztapenean denbora eman dudalako, hau da, lehen eta bigarren urratsetan. Eta esperimentua hemen ere ezin da ezarri, esperimentuan ez baitugu lehen urratsa egiteko eskubiderik, zeregina aurrez zehaztuta dago.
Erraza da zehaztapen informaletan zailtasun asko alde batera uztea. Ez dago ezer zaila funtzioen zehaztapen zorrotzak idazteko, ez dut hau eztabaidatuko. Horren ordez, jokabide estandarentzako zehaztapen sendoak idazteari buruz hitz egingo dugu. Bada teorema bat segurtasun propietatea erabiliz edozein portaera multzo deskriba daitekeela dioena (segurtasuna) eta bizirauteko propietateak (bizitasuna). Segurtasunak esan nahi du ez dela ezer txarrik gertatuko, programak ez du erantzun okerrik emango. Biziraugarritasunak esan nahi du lehenago edo beranduago zerbait ona gertatuko dela, hau da, programak erantzun zuzena emango duela lehenago edo beranduago. Oro har, segurtasuna adierazle garrantzitsuagoa da, akatsak gehienetan hemen gertatzen dira. Horregatik, denbora aurrezteko, ez dut biziraupenari buruz hitz egingo, nahiz eta, jakina, garrantzitsua den.
Segurtasuna lortzen dugu, lehenik, hasierako egoera posibleen multzoa aginduz. Eta bigarrena, estatu bakoitzeko hurrengo estatu posible guztiekin harremanak. Joka dezagun zientzialari bezala eta definitu gaitezen egoerak matematikoki. Hasierako egoeren multzoa formula baten bidez deskribatzen da, adibidez, Euklides algoritmoaren kasuan: (x = M) β§ (y = N). Balio jakin batzuetarako M ΠΈ N hasierako egoera bakarra dago. Hurrengo egoerarekin erlazioa hurrengo egoeraren aldagaiak lehen batekin idazten diren eta uneko egoeraren aldagaiak lehen gabe idazten diren formula baten bidez deskribatzen da. Euklidesen algoritmoaren kasuan, bi formularen disjuntzioaz arituko gara, horietako batean x balio handiena da, eta bigarrenean - y:
Lehenengo kasuan, y-ren balio berria y-ren aurreko balioaren berdina da, eta x-ren balio berria lortzen dugu aldagai txikiagoari aldagai handiari kenduz. Bigarren kasuan, alderantziz egiten dugu.
Itzul gaitezen Euklidesen algoritmora. Demagun berriro hori M = 12, N = 18. Honek hasierako egoera bakarra definitzen du, (x = 12) β§ (y = 18). Ondoren, balio horiek goiko formulan konektatzen ditugu eta lortuko dugu:
Hona hemen irtenbide posible bakarra: x' = 18 - 12 β§ y' = 12eta portaera lortzen dugu: [x = 12, y = 18]. Era berean, gure portaeraren egoera guztiak deskriba ditzakegu: [x = 12, y = 18] β [x = 12, y = 6] β [x = 6, y = 6].
Azken egoeran [x = 6, y = 6] adierazpenaren bi zatiak faltsuak izango dira, beraz, ez du hurrengo egoerarik. Beraz, bigarren urratsaren zehaztapen osoa dugu; ikus dezakezun bezala, matematika nahiko arrunta da, ingeniari eta zientzialarietan bezala, eta ez arraroa, informatikan bezala.
Bi formula hauek denborazko logikaren formula batean konbina daitezke. Dotorea eta azaltzeko erraza da, baina orain ez dago denborarik. Baliteke denborazko logika behar izatea bizitasun jabetzarako soilik, ez da beharrezkoa segurtasunerako. Ez zait denborazko logika gisa gustatzen, ez da nahiko matematika arrunta, baina bizitasunaren kasuan ezinbesteko gaitz bat da.
Euklidesen algoritmoan, balio bakoitzeko x ΠΈ y balio bereziak dituzte x' ΠΈ y', hurrengo egoerarekin erlazioa egia bihurtzen dutenak. Beste era batera esanda, Euklidesen algoritmoa determinista da. Algoritmo ez-determinista bat modelatzeko, uneko egoerak etorkizuneko egoera posible anitz izan behar ditu, eta lehengai gabeko aldagai-balio bakoitzak lehendatutako aldagai-balio anitz izan behar ditu, hurrengo egoerarekin erlazioa egiazkoa izan dadin. Hau egiteko erraza da, baina orain ez dut adibiderik jarriko.
Lan tresna bat egiteko, matematika formala behar duzu. Nola egin zehaztapena formala? Horretarako, hizkuntza formal bat behar dugu, adibidez, . Euklides algoritmoaren zehaztapenak honela izango luke hizkuntza honetan:
Triangelu bat duen berdintasun-ikurrak esan nahi du zeinuaren ezkerrean dagoen balioa zeinuaren eskuineko balioaren berdina dela definitzen dela. Funtsean, zehaztapena definizio bat da, gure kasuan bi definizio. TLA+-ko zehaztapenari, deklarazioak eta sintaxi batzuk gehitu behar dituzu, goiko diapositiban bezala. ASCII-n honela geratuko litzateke:
Ikusten duzun bezala, ezer konplikatua. TLA+-ren zehaztapena probatu daiteke, hau da, eredu txiki batean jokabide posible guztiak saihestu. Gure kasuan, eredu hau balio jakin batzuk izango dira M ΠΈ N. Hau egiaztapen metodo oso eraginkor eta sinplea da, guztiz automatikoa dena. Egia-froga formalak idaztea eta mekanikoki egiaztatzea ere posible da, baina honek denbora asko behar du, beraz, ia inork ez du hori egiten.
TLA+-ren desabantaila nagusia matematika dela da, eta programatzaile eta informatikariek matematikari beldurra diote. Lehen begiratuan, txantxa bat dirudi honek, baina, zoritxarrez, seriotasun osoz esan nahi dut. Nire lankideak kontatzen ari zen nola saiatu zen TLA+ hainbat garatzaileri azaltzen. Formulak pantailan agertu orduko, berehala kristalezko begi bihurtu ziren. Beraz, TLA+ek beldurra ematen bazaitu, erabil dezakezu , jostailuen programazio lengoaia moduko bat da. PlusCal-en adierazpen bat edozein TLA+ adierazpen izan daiteke, hau da, oro har, edozein adierazpen matematiko. Horrez gain, PlusCal-ek algoritmo ez-deterministetarako sintaxia du. PlusCal-ek edozein TLA+ adierazpen idatz dezakeenez, PlusCal-ek benetako programazio-lengoaia baino askoz adierazgarriagoa da. Ondoren, PlusCal erraz irakur daitekeen TLA+ zehaztapen batean biltzen da. Horrek ez du esan nahi, noski, PlusCal zehaztapen konplexua TLA +-n sinple bihurtuko denik - haien arteko korrespondentzia agerikoa da, ez da konplexutasun gehigarririk izango. Azkenik, zehaztapen hau TLA+ tresnen bidez egiaztatu daiteke. Oro har, PlusCal-ek matematika-fobia gainditzen lagun dezake eta erraz ulertzen da programatzaile eta informatikarientzat ere. Iraganean, algoritmoak argitaratu nituen denbora batez (10 urte inguru).
Agian norbaitek TLA + eta PlusCal matematikak direla oposizioa egingo du, eta matematikak asmatutako adibideetan bakarrik funtzionatzen du. Praktikan, motak, prozedurak, objektuak eta abar dituen benetako hizkuntza behar duzu. Hau gaizki dago. Hona hemen Amazon-en lan egiten zuen Chris Newcombek idazten duena: βTLA+ erabili dugu hamar proiektu handitan, eta, kasu bakoitzean, hura erabiltzeak garapenean diferentzia nabarmena izan du, akats arriskutsuak harrapatzeko gai izan garelako ekoizpenean hasi aurretik, eta behar genuen ikuspegia eta konfiantza eman zigulako. egin errendimenduaren optimizazio oldarkorrak programaren egiari eragin gabe". Askotan entzun dezakezu metodo formalak erabiltzean kode eraginkorra lortzen dugula; praktikan, dena guztiz kontrakoa da. Horrez gain, iritzia dago kudeatzaileak ezin direla sinetsi metodo formalen beharraz, programatzaileak haien erabilgarritasunaz sinetsita egon arren. Eta Newcombek idazten du: "Kudeatzaileak orain gogor egiten ari dira TLA +-rako zehaztapenak idazteko eta horretarako denbora esleitzeko bereziki". Beraz, kudeatzaileek TLA+ funtzionatzen ari dela ikusten dutenean, pozik onartzen dute. Chris Newcombek hau idatzi zuen duela sei hilabete inguru (2014ko urrian), baina orain, nik dakidala, TLA+ 14 proiektutan erabiltzen da, ez 10. Beste adibide bat XBox 360-ren diseinuan dago. Bekadun bat etorri zen Charles Thacker-era eta memoria sistemarako zehaztapenak idatzi zituen. Zehaztapen honi esker, bestela oharkabean pasako zen akats bat aurkitu zen, eta horregatik XBox 360 bakoitza lau ordu erabili ondoren huts egingo zuen. IBMko ingeniariek baieztatu zuten haien probek ez zutela akats hau aurkituko.
TLA +-ri buruz gehiago irakur dezakezu Interneten, baina orain hitz egin dezagun zehaztapen informalei buruz. Oso gutxitan idatzi behar dugu zatitzaile komun txikiena eta antzekoak kalkulatzen dituzten programak. Askoz maizago idazten ditugu TLA+-rako idatzi nuen inprimagailu polita tresna bezalako programak. Prozesatu errazenaren ondoren, TLA + kodea honela izango litzateke:
Baina goiko adibidean, erabiltzaileak ziurrenik konjuntzioa eta berdintasun zeinuak lerrokatzea nahi zuen. Beraz, formatu zuzena itxura gehiago izango luke:
Ikus ezazu beste adibide bat:
Hemen, aitzitik, iturburuan berdintasunaren, batuketaren eta biderketaren zeinuen lerrokadura ausazkoa zen, beraz, prozesaketa errazena nahikoa da. Oro har, ez dago formatu zuzenaren definizio matematiko zehatzik, "zuzena" kasu honetan "erabiltzaileak nahi duena" esan nahi duelako, eta hori ezin da matematikoki zehaztu.
Badirudi egiaren definiziorik ez badugu, zehaztapenak ez duela ezertarako balio. Baina ez da. Programa batek zer egin behar duen ez dakigulako ez du esan nahi nola funtzionatzen duen pentsatu behar ez dugunik; aitzitik, are gehiago ahalegindu behar dugu horretan. Zehaztapena bereziki garrantzitsua da hemen. Ezinezkoa da inprimaketa egituraturako programa optimoa zehaztea, baina horrek ez du esan nahi ez dugunik hartu behar, eta kodea kontzientzia-korronte gisa idaztea ez da ona. Azkenean, definizioekin sei arauren zehaztapena idatzi nuen iruzkin moduan java fitxategi batean. Hona hemen arauetako baten adibide bat: a left-comment token is LeftComment aligned with its covering token. Arau hau ingeles matematikoan idatzita dago, esango dugu: LeftComment aligned, left-comment ΠΈ covering token - definizioak dituzten terminoak. Horrela deskribatzen dute matematikariek matematika: terminoen definizioak idazten dituzte eta, horietan oinarrituta, arauak. Zehaztapen horren abantaila da sei arau 850 kode-lerro baino askoz errazagoak direla ulertzen eta arazteko. Esan behar dut arau hauek idaztea ez dela erraza izan, denbora dezente behar izan dela horiek arazketa egiteko. Batez ere, horretarako, kode bat idatzi nuen, zein arau erabili zen adierazten zuen. Sei arau hauek hainbat adibidetan probatu ditudalako, ez ditut 850 kode-lerro arazteko beharrik izan, eta akatsak nahiko errazak izan dira aurkitzea. Javak tresna bikainak ditu horretarako. Kodea idatzi berri izan banu, askoz ere luzeagoa izango zen, eta formatua kalitate eskasagoa izango zen.
Zergatik ezin izan da zehaztapen formalik erabili? Alde batetik, exekuzio zuzenak ez du garrantzi handiegia hemen. Egiturazko inprimaketak inori ez diezaiotela gustatuko litzaidake, beraz, ez nuen egoera bitxi guztietan ondo funtzionatzea. Are garrantzitsuagoa da tresna egokirik ez nuela. TLA+ ereduaren egiaztatzaileak ez du ezertarako balio hemen, beraz, eskuz idatzi beharko nituzke adibideak.
Goiko zehaztapenak zehaztapen guztien ezaugarri komunak ditu. Kodea baino maila altuagoa da. Edozein hizkuntzatan ezarri daiteke. Edozein tresna edo metodo alferrikakoa da idazteko. Ez da programazio ikastarorik lagunduko zehaztapen hau idazten. Eta ez dago zehaztapen hau alferrikako bihur daitekeen tresnarik, baldin eta, noski, TLA+-n inprimatze egituratutako programak idazteko bereziki hizkuntza bat idazten ari bazara. Azkenik, zehaztapen honek ez du ezer esaten zehazki nola idatziko dugun kodeari buruz, kode honek zer egiten duen adierazten du soilik. Zehaztapena idazten dugu kodean pentsatzen hasi aurretik arazoa pentsatzen laguntzeko.
Baina zehaztapen honek beste zehaztapenetatik bereizten dituen ezaugarriak ere baditu. Beste zehaztapenen % 95 nabarmen laburragoak eta sinpleagoak dira:
Gainera, zehaztapen hau arau multzo bat da. Oro har, zehaztapen eskasaren seinale da. Arau multzo baten ondorioak ulertzea nahiko zaila da, horregatik denbora asko eman behar izan nuen horiek arazketan. Hala ere, kasu honetan, ezin izan dut bide hoberik aurkitu.
Etengabe exekutatzen diren programei buruz hitz batzuk esatea merezi du. Oro har, paraleloan lan egiten dute, adibidez, sistema eragileak edo sistema banatuak. Oso jende gutxik ulertzen ditu mentalki edo paperean, eta ni ez naiz horietako bat, nahiz eta behin egin ahal izan nuen. Hori dela eta, gure lana egiaztatuko duten tresnak behar ditugu, adibidez, TLA + edo PlusCal.
Zergatik zen beharrezkoa zehaztapen bat idaztea, baldin eta dagoeneko banekien kodeak zer egin behar zuen zehazki? Izan ere, banekiela uste nuen. Horrez gain, zehaztapen batekin, kanpoko batek jada ez du kodean sartu behar zehazki zer egiten duen ulertzeko. Arau bat daukat: ez da arau orokorrik egon behar. Arau honetan salbuespen bat dago, noski, jarraitzen dudan arau orokor bakarra da: kodeak egiten duenaren zehaztapenak jendeari kodea erabiltzean jakin behar duen guztia esan beharko luke.
Beraz, zer jakin behar dute programatzaileek pentsatzeari buruz? Hasteko, denek bezala: idazten ez baduzu, pentsatzen ari zarela besterik ez zaizu iruditzen. Gainera, kodetu aurretik pentsatu behar duzu, hau da, kodetu aurretik idatzi behar duzu. Zehaztapena kodetzen hasi aurretik idazten duguna da. Edonork erabil edo alda dezakeen edozein kodetarako zehaztapen bat behar da. Eta "norbait" hori izan daiteke kodearen egilea bera idatzi zenetik hilabetera. Zehaztapen bat behar da programa eta sistema handietarako, klaseetarako, metodoetarako eta, batzuetan, metodo bakar baten atal konplexuetarako ere. Zer idatzi behar da zehazki kodeari buruz? Zer egiten duen deskribatu behar duzu, hau da, kode hau erabiltzen duen edozein pertsonarentzat zer izan daitekeen erabilgarria. Batzuetan, kodeak bere helburua nola betetzen duen zehaztea ere beharrezkoa izan daiteke. Algoritmoetan metodo honetatik pasatu bagara, orduan algoritmo deitzen diogu. Zerbait bereziagoa eta berriagoa bada, goi-mailako diseinua deitzen diogu. Hemen ez dago ezberdintasun formalik: biak programa baten eredu abstraktu bat dira.
Zehazki nola idatzi behar duzu kodearen zehaztapena? Gauza nagusia: kodea bera baino maila bat altuagoa izan behar du. Egoerak eta jokabideak deskribatu behar ditu. Zereginak eskatzen duen bezain zorrotza izan behar du. Zeregin bat nola inplementatu behar den jakiteko zehaztapen bat idazten ari bazara, pseudokodean edo PlusCal-ekin idatz dezakezu. Zehaztapen formaletan zehaztapenak idazten ikasi behar duzu. Honek beharrezko trebetasunak emango dizkizu, informalekin ere lagunduko dizutenak. Nola ikasten duzu zehaztapen formalak idazten? Programatzen ikasi genuenean, programak idatzi eta gero arazketa egiten genuen. Hemen ere berdina da: idatzi zehaztapenak, egiaztatu modelo egiaztatzailearekin eta konpondu akatsak. Baliteke TLA+ ez izatea zehaztapen formal baterako hizkuntzarik onena, eta baliteke beste hizkuntza bat zure behar zehatzetarako hobea izatea. TLA+-ren abantaila matematika pentsamendu oso ondo irakasten duela da.
Nola lotu zehaztapena eta kodea? Kontzeptu matematikoak eta haien ezarpena lotzen dituzten iruzkinen laguntzaz. Grafikoekin lan egiten baduzu, programa mailan nodoen eta esteken matrizeak izango dituzu. Hori dela eta, programazio-egitura hauek grafikoa nola inplementatzen duten idatzi behar duzu.
Kontuan izan behar da aurreko hauetako bat ere ez dela aplikatzen kodea idazteko benetako prozesuari. Kodea idaztean, hau da, hirugarren urratsa egiten duzunean, programan pentsatu eta pentsatu ere egin behar duzu. Azpizeregin bat konplexua edo begi-bistakoa ez bada, horretarako zehaztapen bat idatzi behar duzu. Baina ez naiz hemen kodeari buruz hitz egiten. Edozein programazio-lengoaia erabil dezakezu, edozein metodologia, ez da haiei buruz. Gainera, aurrekoetako batek ere ez du kentzen kodea probatu eta arazketa egin beharra. Eredu abstraktua behar bezala idatzita badago ere, inplementazioan akatsak egon daitezke.
Zehaztapenak idaztea kodetze prozesuan urrats gehigarria da. Horri esker, akats asko atzeman daitezke ahalegin gutxiagorekin - Amazon-eko programatzaileen esperientziatik dakigu hori. Zehaztapenekin, programen kalitatea handiagoa da. Orduan, zergatik joaten gara hainbestetan haiek gabe? Idaztea zaila delako. Eta idaztea zaila da, horretarako pentsatu behar baita, eta pentsatzea ere zaila da. Beti da errazagoa iruditzen zaizuna itxuratzea. Hemen korrika egin dezakezun analogia bat marraz dezakezu: zenbat eta gutxiago korrika egin, orduan eta motelago. Muskuluak entrenatu eta idazketa landu behar dituzu. Praktika behar.
Baliteke zehaztapena okerra izatea. Baliteke akats bat nonbait egin izana, eskakizunak aldatu izana edo hobekuntza bat egin behar izatea. Edonork erabiltzen duen edozein kodea aldatu behar da, beraz, lehenago edo beranduago, zehaztapena ez da programarekin bat etorriko. Egokiena, kasu honetan, zehaztapen berri bat idatzi eta kodea guztiz berridatzi behar duzu. Ondo dakigu inork ez duela horrelakorik egiten. Praktikan, kodea adabakitzen dugu eta ziurrenik zehaztapena eguneratzen dugu. Hori lehenago edo beranduago gertatuko bada, zergatik idatzi zehaztapenak? Lehenik eta behin, zure kodea editatuko duen pertsonarentzat, zehaztapeneko hitz gehigarri bakoitzak urrezko balioa izango du, eta baliteke pertsona hori zu izan. Askotan errieta egiten diot neure buruari nire kodea editatzen ari naizenean zehaztapen nahikorik ez jasotzeagatik. Eta kodea baino zehaztapen gehiago idazten ditut. Beraz, kodea editatzen duzunean, zehaztapena beti eguneratu behar da. Bigarrenik, berrikuspen bakoitzean, kodea okerrera egiten da, gero eta zailagoa da irakurtzea eta mantentzea. Hau entropia handitzea da. Baina zehaztapen batekin hasten ez bazara, idazten duzun lerro bakoitza edizio bat izango da, eta kodea zaila izango da eta irakurtzeko zaila izango da hasieratik.
Esan bezala , planaren bidez ez zen borrokarik irabazi, eta planik gabe ez zen borrokarik irabazi. Eta gauza bat edo bi zekien guduei buruz. Badago iritzia zehaztapenak idaztea denbora galtzea dela. Batzuetan hori egia da, eta zeregina hain da sinplea, ezen ez dagoela ezer pentsatu behar. Baina beti gogoratu behar duzu zehaztapenak ez idazteko esaten dizutenean, ez pentsatzeko esaten dizula. Eta aldi bakoitzean pentsatu beharko zenuke. Zereginean pentsatzeak ez du bermatzen akatsik egingo ez duzunik. Dakigunez, inork ez zuen makila magikoa asmatu, eta programatzea lan zaila da. Baina arazoan pentsatzen ez baduzu, akatsak egingo dituzula ziurtatuta dago.
TLA + eta PlusCal-i buruz gehiago irakur dezakezu webgune berezi batean, bertara joan zaitezke nire hasierako orrialdetik . Hori da niretzat guztia, eskerrik asko zure arretagatik.
Kontuan izan hau itzulpen bat dela. Iruzkinak idazten dituzunean, gogoratu egileak ez dituela irakurriko. Egilearekin benetan hitz egin nahi baduzu, 2019ko uztailaren 11tik 12ra San Petersburgon ospatuko den Hydra 2019 konferentzian egongo da. Sarrerak eros daitezke .
Iturria: www.habr.com