As se sizze, as jo jo net skamje foar jo âlde koade, dan groeie jo net as programmeur - en ik bin it iens mei dizze miening. Ik begon te programmearjen foar wille mear as 40 jier lyn, en profesjoneel 30 jier lyn, dus ik haw in protte flaters. tige folle. As heechlearaar kompjûterwittenskip lear ik myn learlingen om te learen fan flaters - harres, mines en oaren. Ik tink dat it tiid is om oer myn flaters te praten om myn beskiedenens net te ferliezen. Ik hoopje dat se sille wêze nuttich foar immen.

Tredde plak - Microsoft C-kompiler

Myn skoalmaster leaude dat Romeo en Julia net as in trageedzje kinne wurde beskôge, om't de personaazjes gjin tragyske skuld hawwe - se gedragen gewoan dom, lykas teenagers moatte. Ik wie it doe net mei him iens, mar no sjoch ik yn syn miening in stikje rationaliteit, benammen yn ferbân mei programmearring.

Tsjin de tiid dat ik myn twadde jier by MIT ôfmakke, wie ik jong en sûnder ûnderfining, sawol yn it libben as yn programmearring. Yn 'e simmer haw ik ynternearre by Microsoft, op it C-kompilerteam. Earst die ik routine dingen lykas profilearringstipe, en doe waard ik fertroud mei it wurkjen oan it leukste diel fan 'e gearstaller (sa't ik tocht) - backend-optimisaasje. Benammen moast ik de x86-koade ferbetterje foar branch-útspraken.

Besletten om foar elke mooglike saak de optimale masinekoade te skriuwen, smiet ik mysels yn it swimbad. As de ferdielingstichtens fan wearden heech wie, haw ik se ynfierd oergong tabel. As se in mienskiplike divisor hiene, brûkte ik it om de tafel strakker te meitsjen (mar allinich as de divyzje koe wurde dien mei bytsje ferskowing). Doe't alle wearden machten fan twa wiene, die ik in oare optimalisaasje. As in set wearden net foldie oan myn betingsten, splitst ik it yn ferskate optimalisearjende gefallen en brûkte de al optimalisearre koade.

It wie in nachtmerje. In protte jierren letter waard my ferteld dat de programmeur dy't myn koade erfde my hate.

Les leard

As David Patterson en John Hennessy skriuwe yn Computer Architecture and Computer Systems Design, is ien fan 'e haadprinsipes fan arsjitektuer en ûntwerp om dingen oer it algemien sa rap mooglik te wurkjen.

It rapperjen fan mienskiplike gefallen sil de prestaasjes effektiver ferbetterje dan it optimalisearjen fan seldsume gefallen. Iroanysk binne gewoane gefallen faak ienfâldiger dan seldsume. Dit logyske advys giet derfan út dat jo witte hokker gefal wurdt beskôge as mienskiplik - en dit is allinnich mooglik troch in proses fan soarchfâldige testen en mjitting.

Ta myn ferdigening besocht ik út te finen hoe't branche-útspraken der yn 'e praktyk útseagen (lykas hoefolle tûken der wiene en hoe't konstanten ferdield wiene), mar yn 1988 wie dizze ynformaasje net beskikber. Ik hie lykwols gjin spesjale gefallen tafoege moatten as de hjoeddeistige kompilator gjin optimale koade koe generearje foar it keunstmjittige foarbyld dat ik kaam mei.

Ik moast in betûfte ûntwikkelder skilje en tegearre mei him tinke oer wat de gewoane gefallen wiene en se spesifyk omgean. Ik soe skriuwe minder koade, mar dat is in goede saak. Lykas Stack Overflow-oprjochter Jeff Atwood skreau, is de slimste fijân fan in programmeur de programmeur sels:

Ik wit dat jo de bêste bedoelingen hawwe, lykas wy allegearre. Wy meitsje programma's en skriuwe graach koade. Sa binne wy ​​makke. Wy tinke dat elk probleem kin wurde oplost mei duct tape, in selsmakke kruk en in knipe koade. Safolle as it pynlik is foar kodearders om it ta te jaan, is de bêste koade de koade dy't net bestiet. Elke nije line hat debuggen en stipe nedich, it moat begrepen wurde. As jo ​​​​nije koade tafoegje, moatte jo dat dwaan mei tsjinsin en wearze, om't alle oare opsjes útput binne. In protte programmeurs skriuwe tefolle koade, wêrtroch it ús fijân is.

As ik hie skreaun ienfâldiger koade dy't behannele mienskiplike gefallen, it soe west hawwe folle makliker in update as it nedich is. Ik liet in puinhoop efterlitten dêr't gjinien mei omgean woe.

Twadde plak: reklame op sosjale netwurken

Doe't ik by Google wurke oan advertinsjes op sosjale media (ûnthâld Myspace?), skreau ik sa'n ding yn C ++:

for (int i = 0; i < user->interests->length(); i++) {
  for (int j = 0; j < user->interests(i)->keywords.length(); j++) {
      keywords->add(user->interests(i)->keywords(i)) {
  }
}

Programmeurs kinne fuortendaliks de flater sjen: it lêste argumint moat j wêze, net i. Ienheidstesten lieten de flater net sjen, en myn resinsint ek net. De lansearring waard útfierd, en op in nacht gie myn koade nei de tsjinner en ferûngelokke alle kompjûters yn it datasintrum.

Der barde neat slims. Neat bruts foar elkenien, want foar de wrâldwide lansearring waard de koade hifke binnen ien datasintrum. Behalven as SRE-yngenieurs in skoft stoppe mei biljerten en in bytsje weromdraaie. De oare moarns krige ik in e-post mei in crashdump, korrizjearre de koade en tafoege ienheidtests dy't de flater fange. Sûnt ik it protokol folge - oars soe myn koade gewoan net rinne - wiene d'r gjin oare problemen.

Les leard

In protte binne der wis fan dat sa'n grutte flater perfoarst it ûntslach fan 'e skuldige kostet, mar dit is net sa: as earste meitsje alle programmeurs flaters, en twad meitsje se selden twa kear deselde flater.

Yn feite, ik haw in programmeur freon dy't wie in briljante yngenieur en waard ûntslein foar it meitsjen fan in inkele flater. Dêrnei waard hy ynhierd by Google (en gau promovearre) - hy spruts earlik oer de flater dy't hy makke yn in ynterview, en it waard net fataal beskôge.

Dat is wat fertelle oer Thomas Watson, it legindaryske haad fan IBM:

In oerheidsoarder fan sa'n miljoen dollar waard oankundige. IBM Corporation - of leaver, Thomas Watson Sr. persoanlik - woe it echt krije. Spitigernôch koe de ferkeapfertsjintwurdiger dit net dwaan en IBM ferlear it bod. De oare deis kaam dizze meiwurker yn it kantoar fan de hear Watson en lei in envelop op syn buro. De hear Watson die der net iens nei om te sjen - hy wachte op in meiwurker en wist dat it in ûntslachbrief wie.

Watson frege wat der mis gie.

De ferkeapfertsjintwurdiger spruts yn detail oer de fuortgong fan de oanbesteging. Hy neamde de makke flaters dy't foarkommen wurde koenen. Uteinlik sei er: "Menear Watson, tank foar it litte my útlizze. Ik wit hoefolle wy dizze bestelling nedich hawwe. Ik wit hoe wichtich hy wie," en makke him klear om fuort te gean.

Watson kaam by de doar nei him ta, seach him yn 'e eagen en joech de envelop werom mei de wurden: "Hoe kin ik dy litte litte? Ik haw krekt in miljoen dollar ynvestearre yn jo oplieding.

Ik haw in T-shirt dat seit: "As jo ​​echt leare fan flaters, dan bin ik al in master." Yn feite, as it giet om flaters, Ik bin in dokter fan de wittenskip.

Foarste plak: App Inventor API

Wierlik ferskriklike flaters beynfloedzje in grut oantal brûkers, wurde iepenbiere kennis, duorje in lange tiid om te korrigearjen, en wurde makke troch dyjingen dy't se net koenen hawwe makke. Myn grutste flater past by al dizze kritearia.

Hoe slimmer hoe better

ik lês essay fan Richard Gabriel oer dizze oanpak yn de jierren njoggentich as ôfstudearre studint, en ik fyn it sa leuk dat ik it oan myn studinten freegje. As jo ​​it net goed ûnthâlde, ferfarskje jo ûnthâld, it is lyts. Dit essay kontrastearret de winsk om "it goed te krijen" en de "slimmer is better" oanpak op in protte manieren, ynklusyf ienfâld.

Hoe moat it wêze: it ûntwerp moat ienfâldich wêze yn ymplemintaasje en ynterface. Ienfâld fan 'e ynterface is wichtiger as ienfâld fan ymplemintaasje.

Hoe slimmer, hoe better: it ûntwerp moat ienfâldich wêze yn ymplemintaasje en ynterface. Ienfâld fan ymplemintaasje is wichtiger dan ienfâld fan 'e ynterface.

Lit ús dat foar in minút ferjitte. Spitigernôch haw ik it in protte jierren fergetten.

App útfiner

Wylst ik by Google wurke, wie ik diel fan it team App útfiner, in drag-and-drop online ûntwikkelingsomjouwing foar aspirant Android-ûntwikkelders. It wie 2009, en wy hienen haast om de alfa-ferzje op 'e tiid frij te litten, sadat wy yn 'e simmer masterklassen hâlde koene foar learkrêften dy't it miljeu brûke koene by it lesjaan yn 'e hjerst. Ik meldde my oan om sprites te ymplementearjen, nostalgysk foar hoe't ik spultsjes op 'e TI-99/4 skreau. Foar dyjingen dy't it net witte, is in sprite in twadiminsjonaal grafysk objekt dat kin bewege en ynteraksje mei oare software-eleminten. Foarbylden fan sprites omfetsje romteskippen, asteroïden, knikkers en rackets.

Wy ymplementearre foarwerp-rjochte App Inventor yn Java, dus d'r is gewoan in boskje objekten yn. Om't ballen en sprites har heul gelyk gedrage, haw ik in abstrakte spriteklasse makke mei eigenskippen (fjilden) X, Y, Speed ​​​​(snelheid) en Heading (rjochting). Se hiene deselde metoaden foar it opspoaren fan botsingen, it stuitsjen fan 'e râne fan it skerm, ensfh.

It wichtichste ferskil tusken in bal en in sprite is wat krekt is tekene - in folle sirkel of in raster. Sûnt ik earst sprites ymplementearre, wie it logysk om de x- en y-koördinaten op te jaan fan 'e lofterboppehoeke fan wêr't de ôfbylding siet.

Sadree't de sprites wurken, Ik besletten dat ik koe útfiere bal foarwerpen mei hiel bytsje koade. It ienige probleem wie dat ik naam de ienfâldichste rûte (út it eachpunt fan de útfierer), oantsjutte de x- en y-koördinaten fan de boppeste linker hoeke fan de kontoeren framing de bal.

Yn feite wie it nedich om de x- en y-koördinaten fan it sintrum fan 'e sirkel oan te jaan, lykas leard yn elke wiskundelearboek en elke oare boarne dy't sirkels neamt.

Oars as myn flaters út it ferline, beynfloede dizze net allinich myn kollega's, mar ek miljoenen App Inventor-brûkers. In protte fan harren wiene bern of folslein nij foar programmearring. Se moasten in protte oerstallige stappen útfiere by it wurkjen oan elke applikaasje wêryn de bal oanwêzich wie. As ik myn oare flaters mei laitsjen ûnthâlde, dan makket dizze my hjoed noch swit.

Ik haw dizze bug úteinlik pas koartlyn, tsien jier letter, patched. "Patched", net "fêst", want lykas Joshua Bloch seit, API's binne ivich. Net yn steat om feroarings te meitsjen dy't besteande programma's beynfloedzje, hawwe wy it OriginAtCenter-eigendom tafoege mei de wearde falsk yn âlde programma's en wier yn alle takomstige. Brûkers kinne in logyske fraach stelle: wa hat der sels tocht om it begjinpunt earne oars as it sintrum te pleatsen. Oan wa? Oan ien programmeur dy't tsien jier lyn te lui wie om in normale API te meitsjen.

Lessen leard

As jo ​​wurkje oan API's (wat hast elke programmeur soms moat dwaan), moatte jo de bêste advys folgje dy't sketst yn 'e fideo fan Joshua Bloch "Hoe kinne jo in goede API meitsje en wêrom it sa wichtich is"of yn dizze koarte list:

• In API kin jo sawol grutte foardielen as grutte skea bringe.. In goede API skept werhelle klanten. De minne wurdt jo ivige nachtmerje.
• Iepenbiere API's, lykas diamanten, duorje foar altyd. Jou it alles: d'r sil noait mear kâns wêze om alles goed te dwaan.
• API-kontrôles moatte koart wêze - ien side mei hantekeningen en beskriuwingen fan klasse en metoade, dy't net mear as in rigel beslacht. Hjirmei kinne jo de API maklik werstrukturearje as it de earste kear net perfekt wurdt.
• Beskriuw gebrûksgefallenfoardat jo de API ymplementearje of sels wurkje oan syn spesifikaasje. Op dizze manier sille jo foarkomme dat jo in folslein net-funksjonele API ymplementearje en spesifisearje.

As ik sels in koarte synopsis mei in keunstmjittich skript skreaun hie, soe ik wierskynlik de flater identifisearre en korrizjearre hawwe. Sa net, dan soe ien fan myn kollega's it grif dwaan. Elk beslút dat fiergeande gefolgen hat, moat op syn minst in dei neitocht wurde (dit jildt net allinnich foar programmearring).

De titel fan Richard Gabriel's essay, "Worse Is Better", ferwiist nei it foardiel dat giet om earst op 'e merk te wêzen - sels mei in ûnfolslein produkt - wylst in oar in ivichheid trochbringt om it perfekte te jagen. Refleksje oer de sprite-koade besef ik dat ik net iens mear koade hoegde te skriuwen om it goed te krijen. Wat men ek sizze mei, ik hie my bot mis.

konklúzje

Programmeurs meitsje elke dei flaters, of it no is it skriuwen fan buggy-koade of net wolle besykje wat dat har feardigens en produktiviteit sil ferbetterje. Fansels kinne jo in programmeur wêze sûnder sokke serieuze flaters te meitsjen lykas ik. Mar it is ûnmooglik om in goede programmeur te wurden sûnder jo flaters te erkennen en fan har te learen.

Ik kom hieltyd learlingen tsjin dy't it gefoel fine dat se tefolle flaters meitsje en dêrom net útstutsen binne foar programmearring. Ik wit hoe faak it impostorsyndroom is yn IT. Ik hoopje dat jo de lessen sille leare dy't ik haw neamd - mar tink oan de wichtichste: elk fan ús makket flaters - beskamsum, grappich, ferskriklik. Ik sil ferrast en oerstjoer wêze as ik yn 'e takomst net genôch materiaal haw om it artikel troch te gean.

Boarne: www.habr.com