Kaip sakoma, jei nesigėdi savo seno kodo, vadinasi, tu neaugi kaip programuotojas – ir aš sutinku su šia nuomone. Programuoti savo malonumui pradėjau daugiau nei prieš 40 metų, o profesionaliai – prieš 30 metų, todėl turiu daug klaidų. daug. Kaip informatikos profesorius mokau savo studentus mokytis iš klaidų – jų, mano ir kitų. Manau, laikas pakalbėti apie savo klaidas, kad neprarasčiau kuklumo. Tikiuosi jie kam nors pravers.

Trečia vieta – Microsoft C kompiliatorius

Mano mokyklos mokytoja manė, kad Romeo ir Džuljetos negalima laikyti tragedija, nes veikėjai neturi tragiškos kaltės – jie tiesiog elgėsi kvailai, kaip ir priklauso paaugliams. Tada aš su juo nesutikau, bet dabar jo nuomonėje matau racionalumo grūdelį, ypač susijusią su programavimu.

Tuo metu, kai baigiau antrus metus MIT, buvau jaunas ir nepatyręs tiek gyvenime, tiek programavimo srityje. Vasarą stažavau Microsoft kompiliatorių komandoje C. Iš pradžių užsiėmiau įprastiniais dalykais, pavyzdžiui, profiliavimo palaikymu, o paskui man buvo patikėta dirbti su įdomiausia kompiliatoriaus dalimi (kaip ir maniau) – backend optimizavimu. Visų pirma, aš turėjau patobulinti x86 kodą filialų teiginiams.

Nusprendęs kiekvienam galimam atvejui parašyti optimalų mašinos kodą, stačia galva mečiau baseiną. Jei reikšmių pasiskirstymo tankis buvo didelis, aš jas įvedžiau perėjimo lentelė. Jei jie turėjo bendrą daliklį, aš jį naudojau, kad stalas būtų griežtesnis (bet tik tuo atveju, jei padalijimas gali būti atliktas naudojant bitų poslinkis). Kai visos reikšmės buvo dviejų laipsniai, atlikau dar vieną optimizavimą. Jei reikšmių rinkinys neatitiko mano sąlygų, suskaidžiau jį į kelis optimizuojamus atvejus ir panaudojau jau optimizuotą kodą.

Tai buvo košmaras. Po daugelio metų man buvo pasakyta, kad programuotojas, paveldėjęs mano kodą, manęs nekentė.

Pamoka išmokta

Kaip rašo Davidas Pattersonas ir Johnas Hennessy knygoje „Computer Architecture and Computer Systems Design“, vienas iš pagrindinių architektūros ir projektavimo principų yra užtikrinti, kad viskas veiktų kuo greičiau.

Įprastų atvejų paspartinimas pagerins našumą veiksmingiau nei optimizavus retus atvejus. Ironiška, bet įprasti atvejai dažnai yra paprastesni nei reti. Šis logiškas patarimas daro prielaidą, kad žinote, kuris atvejis laikomas dažnu – ir tai įmanoma tik kruopščiai tikrinant ir matuojant.

Gindamasis bandžiau išsiaiškinti, kaip šakų teiginiai atrodo praktiškai (pavyzdžiui, kiek buvo šakų ir kaip pasiskirstė konstantos), tačiau 1988 m. šios informacijos nebuvo. Tačiau neturėčiau pridėti specialių atvejų, kai dabartinis kompiliatorius negalėjo sugeneruoti optimalaus kodo dirbtiniam pavyzdžiui, kurį sugalvojau.

Reikėjo paskambinti patyrusiam kūrėjui ir kartu su juo pagalvoti, kokie yra dažni atvejai, ir konkrečiai juos spręsti. Rašyčiau mažiau kodo, bet tai gerai. Kaip rašė „Stack Overflow“ įkūrėjas Jeffas Atwoodas, didžiausias programuotojo priešas yra pats programuotojas:

Žinau, kad tu, kaip ir mes visi, turi geriausių ketinimų. Kuriame programas ir mėgstame rašyti kodą. Taip esame sukurti. Manome, kad bet kokią problemą galima išspręsti naudojant lipnią juostą, savadarbį ramentą ir žiupsnelį kodo. Kad ir kaip skaudu programuotojams tai pripažinti, geriausias kodas yra kodas, kurio nėra. Kiekvienai naujai eilutei reikia derinimo ir palaikymo, ją reikia suprasti. Kai pridedate naują kodą, turėtumėte tai daryti su nenoru ir pasibjaurėjimu, nes visos kitos galimybės buvo išnaudotos. Daugelis programuotojų rašo per daug kodo, todėl tai tampa mūsų priešu.

Jei būčiau parašęs paprastesnį kodą, apimantį įprastus atvejus, prireikus jį būtų buvę daug lengviau atnaujinti. Palikau netvarką, kurios niekas nenorėjo spręsti.

Antra vieta: reklama socialiniuose tinkluose

Kai dirbau „Google“ reklamuodamas socialinius tinklus (pamenate „Myspace“?), C++ kalboje parašiau maždaug taip:

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)) {
  }
}

Programuotojai gali iš karto pamatyti klaidą: paskutinis argumentas turi būti j, o ne i. Vieneto bandymas klaidos neatskleidė, taip pat mano apžvalgininkas. Paleidimas buvo atliktas, ir vieną naktį mano kodas pateko į serverį ir sudužo visi duomenų centro kompiuteriai.

Nieko blogo neatsitiko. Niekam niekas nesugedo, nes prieš pasaulinį paleidimą kodas buvo išbandytas viename duomenų centre. Nebent SRE inžinieriai kurį laiką nustojo žaisti biliardą ir šiek tiek atsitraukė. Kitą rytą gavau el. laišką su avarijos išvadu, ištaisiau kodą ir pridėjau vieneto testus, kurie aptiktų klaidą. Kadangi laikiausi protokolo – kitaip mano kodas paprasčiausiai nepavyktų paleisti – jokių kitų problemų nekilo.

Pamoka išmokta

Daugelis įsitikinę, kad tokia didelė klaida neabejotinai kainuos kaltininko atleidimą, tačiau taip nėra: pirma, visi programuotojai klysta, antra, retai daro tą pačią klaidą du kartus.

Tiesą sakant, turiu draugą programuotoją, kuris buvo puikus inžinierius ir buvo atleistas už vieną klaidą. Po to jis buvo pasamdytas „Google“ (ir netrukus paaukštintas) – jis nuoširdžiai kalbėjo apie klaidą, kurią padarė interviu, ir tai nebuvo laikoma lemtinga.

Štai ką pasakyk apie Thomasą Watsoną, legendinį IBM vadovą:

Buvo paskelbtas apie milijono dolerių vertės vyriausybės užsakymas. IBM korporacija – tiksliau Thomas Watsonas vyresnysis asmeniškai – labai norėjo jį gauti. Deja, pardavimo atstovas negalėjo to padaryti ir IBM pralaimėjo pasiūlymą. Kitą dieną šis darbuotojas atėjo į J. Watson kabinetą ir padėjo voką ant jo stalo. J. Watsonas net nesivargino į tai pažiūrėti – laukė darbuotojo ir žinojo, kad tai atsistatydinimo laiškas.

Watsonas paklausė, kas nutiko.

Prekybos atstovas išsamiai pasakojo apie konkurso eigą. Jis įvardijo padarytas klaidas, kurių buvo galima išvengti. Galiausiai jis pasakė: „Ponas Vatsonai, ačiū, kad leidote man paaiškinti. Žinau, kiek mums reikėjo šio užsakymo. Žinau, koks jis buvo svarbus“, ir susiruošė išvykti.

Vatsonas priėjo prie jo prie durų, pažvelgė jam į akis ir grąžino voką su žodžiais: „Kaip aš galiu tave paleisti? Aš ką tik investavau milijoną dolerių į tavo mokslą.

Turiu marškinėlius su užrašu: „Jei tikrai mokaisi iš klaidų, aš jau esu meistras“. Tiesą sakant, kalbant apie klaidas, esu mokslų daktaras.

Pirma vieta: App Inventor API

Tikrai baisios klaidos paveikia daugybę vartotojų, jos tampa viešai žinomos, ilgai ištaisomos ir daromos tų, kurie negalėjo jų padaryti. Mano didžiausia klaida atitinka visus šiuos kriterijus.

Kuo blogiau, tuo geriau

Aš skaitau Richardo Gabrielio esė apie šį požiūrį devintajame dešimtmetyje, būdamas magistrantūros studentas, ir man jis taip patinka, kad klausiu savo studentų. Jei blogai atsimeni, atnaujink atmintį, ji maža. Šis rašinys daugeliu atžvilgių, įskaitant paprastumą, priešpastato norą „susitvarkyti teisingai“ ir „blogiau, tuo geriau“ metodą.

Kaip tai turėtų būti: dizainas turi būti paprastas įgyvendinant ir sąsajoje. Sąsajos paprastumas yra svarbesnis nei įgyvendinimo paprastumas.

Kuo blogiau, tuo geriau: dizainas turi būti paprastas įgyvendinant ir sąsajoje. Diegimo paprastumas yra svarbesnis nei sąsajos paprastumas.

Pamirškime apie tai minutei. Deja, daugelį metų apie tai pamiršau.

Programų išradėjas

Dirbdamas „Google“ buvau komandos narys Programų išradėjas, vilkite ir numeskite internetinę kūrimo aplinką trokštantiems Android kūrėjams. Buvo 2009 m., skubėjome laiku išleisti alfa versiją, kad vasarą galėtume surengti meistriškumo kursus mokytojams, kurie galėtų naudotis aplinka dėstydami rudenį. Pasisiūliau įdiegti sprites, nostalgiją, kaip rašiau žaidimus TI-99/4. Tiems, kurie nežino, sprite yra dvimatis grafinis objektas, galintis judėti ir sąveikauti su kitais programinės įrangos elementais. Spraitų pavyzdžiai yra erdvėlaiviai, asteroidai, rutuliukai ir raketės.

„Java“ įdiegėme į objektus orientuotą „App Inventor“, todėl joje yra tik daugybė objektų. Kadangi rutuliai ir spritai elgiasi labai panašiai, sukūriau abstrakčią sprite klasę su savybėmis (laukais) X, Y, Greitis (greitis) ir Antraštė (kryptis). Jie turėjo tuos pačius metodus, kaip aptikti susidūrimus, atšokti nuo ekrano krašto ir pan.

Pagrindinis skirtumas tarp kamuoliuko ir sprito yra tai, kas tiksliai nupiešta – užpildytas apskritimas ar rastras. Kadangi pirmiausia įdiegiau sprites, buvo logiška nurodyti viršutinio kairiojo kampo, kuriame buvo vaizdas, x ir y koordinates.

Kai spraitai pradėjo veikti, nusprendžiau, kad galiu įgyvendinti rutulinius objektus su labai mažu kodu. Vienintelė bėda buvo ta, kad važiavau paprasčiausiu maršrutu (diegėjo požiūriu), nurodydamas kamuoliuką įrėminančio kontūro viršutinio kairiojo kampo x ir y koordinates.

Tiesą sakant, reikėjo nurodyti apskritimo centro x ir y koordinates, kaip mokoma bet kuriame matematikos vadovėlyje ir bet kuriame kitame šaltinyje, kuriame minimi apskritimai.

Kitaip nei mano ankstesnės klaidos, ši paveikė ne tik mano kolegas, bet ir milijonus App Inventor vartotojų. Daugelis jų buvo vaikai arba visiškai naujokai programuojant. Dirbdami su kiekviena programa, kurioje buvo kamuolys, jie turėjo atlikti daug nereikalingų veiksmų. Jei su juoku prisimenu kitas savo klaidas, tai ši mane prakaituoja ir šiandien.

Pagaliau ištaisiau šią klaidą tik neseniai, po dešimties metų. „Pataisyta“, o ne „pataisyta“, nes, kaip sako Joshua Blochas, API yra amžinos. Negalėdami atlikti pakeitimų, kurie turėtų įtakos esamoms programoms, pridėjome ypatybę „OriginAtCenter“, kurios vertė „false“ senose programose ir „true“ visose būsimose programose. Vartotojai gali užduoti logišką klausimą: kas net sugalvojo pradžios tašką pastatyti kur nors kitur, o ne centre. Kam? Vienam programuotojui, kuris prieš dešimt metų tingėjo sukurti normalią API.

Išmoktos pamokos

Dirbdami su API (ką kartais turi daryti beveik kiekvienas programuotojas), turėtumėte vadovautis geriausiais patarimais, pateiktais Joshua Blocho vaizdo įraše.Kaip sukurti gerą API ir kodėl tai taip svarbuarba šiame trumpame sąraše:

• API gali atnešti tiek daug naudos, tiek žalos.. Gera API sukuria pakartotinius klientus. Blogasis tampa tavo amžinu košmaru.
• Viešosios API, kaip ir deimantai, trunka amžinai. Atiduokite viską: niekada nebus kitos galimybės viską padaryti teisingai.
• API kontūrai turėtų būti trumpi — vienas puslapis su klasių ir metodų parašais ir aprašymais, užimantis ne daugiau kaip eilutę. Tai leis lengvai pertvarkyti API, jei ji nepasirodytų tobula pirmą kartą.
• Apibūdinkite naudojimo atvejusprieš diegiant API ar net dirbant su jos specifikacija. Taip išvengsite visiškai neveikiančios API diegimo ir nurodymo.

Jei būčiau parašęs nors trumpą konspektą dirbtiniu scenarijumi, greičiausiai būčiau nustatęs klaidą ir ją ištaisęs. Jei ne, tai vienas iš mano kolegų tikrai tai padarytų. Apie bet kokį sprendimą, turintį toli siekiančių pasekmių, reikia pagalvoti bent dieną (tai galioja ne tik programavimui).

Ričardo Gabrielio esė pavadinimas „Blogesnis yra geresnis“ nurodo pranašumą, kuris suteikiamas pirmam į rinką – net ir su netobulu produktu – tuo tarpu kai kas nors kitas praleidžia visą amžinybę ieškodamas tobulo. Galvodamas apie sprite kodą suprantu, kad man net nereikėjo rašyti daugiau kodo, kad jį suprasčiau. Kad ir ką sakytų, aš labai klydau.

išvada

Programuotojai kiekvieną dieną daro klaidų, nesvarbu, ar tai rašo klaidingą kodą, ar nenori išbandyti kažko, kas pagerintų jų įgūdžius ir produktyvumą. Žinoma, jūs galite būti programuotoju nedarydami tokių rimtų klaidų, kaip aš. Tačiau neįmanoma tapti geru programuotoju, nepripažįstant savo klaidų ir iš jų nepasimokius.

Nuolat susiduriu su studentais, kurie jaučiasi darantys per daug klaidų ir todėl nėra pasirengę programuoti. Žinau, koks paplitęs apsimetėlių sindromas IT srityje. Tikiuosi, kad išmoksite mano išvardintas pamokas – bet atsiminkite pagrindinę: kiekvienas iš mūsų darome klaidų – gėdingų, juokingų, baisių. Būsiu nustebęs ir nusiminęs, jei ateityje neturėsiu pakankamai medžiagos, kad galėčiau tęsti straipsnį.

Šaltinis: www.habr.com