Tulad ng sinasabi nila, kung hindi ka nahihiya sa iyong lumang code, hindi ka lumalaki bilang isang programmer - at sumasang-ayon ako sa opinyon na ito. Nagsimula akong magprograma para sa kasiyahan mahigit 40 taon na ang nakalilipas, at propesyonal 30 taon na ang nakakaraan, kaya marami akong pagkakamali. magkano. Bilang propesor sa computer science, tinuturuan ko ang aking mga estudyante na matuto mula sa mga pagkakamali—sa kanila, sa akin, at sa iba. Sa tingin ko oras na para pag-usapan ang mga pagkakamali ko para hindi mawala ang pagiging mahinhin ko. Umaasa ako na sila ay magiging kapaki-pakinabang sa isang tao.

Ikatlong lugar - Microsoft C compiler

Naniniwala ang guro ko sa paaralan na hindi maituturing na trahedya sina Romeo at Juliet dahil ang mga karakter ay walang trahedya na pagkakasala - sila ay kumilos nang hangal, gaya ng nararapat sa mga tinedyer. Hindi ako sumasang-ayon sa kanya noon, ngunit ngayon ay nakikita ko ang isang butil ng katwiran sa kanyang opinyon, lalo na sa koneksyon sa programming.

Sa oras na natapos ko ang aking sophomore year sa MIT, bata pa ako at walang karanasan, kapwa sa buhay at sa programming. Noong tag-araw, nag-intern ako sa Microsoft, sa pangkat ng compiler ng C. Sa una ay gumawa ako ng mga nakagawiang bagay tulad ng suporta sa pag-profile, at pagkatapos ay pinagkatiwalaan akong magtrabaho sa pinakanakakatuwang bahagi ng compiler (tulad ng naisip ko) - backend optimization. Sa partikular, kailangan kong pagbutihin ang x86 code para sa mga pahayag ng sangay.

Determinado akong isulat ang pinakamainam na code ng makina para sa bawat posibleng kaso, itinapon ko ang sarili ko sa pool nang marahan. Kung ang density ng pamamahagi ng mga halaga ay mataas, pinasok ko ang mga ito talahanayan ng paglipat. Kung mayroon silang isang karaniwang divisor, ginamit ko ito upang gawing mas mahigpit ang talahanayan (ngunit kung magagawa lamang ang paghahati gamit ang medyo shift). Kapag ang lahat ng mga halaga ay kapangyarihan ng dalawa, gumawa ako ng isa pang pag-optimize. Kung ang isang hanay ng mga halaga ay hindi nakakatugon sa aking mga kondisyon, hinati ko ito sa ilang mga na-optimize na kaso at ginamit ang na-optimize na code.

Ito ay isang bangungot. Pagkalipas ng maraming taon, sinabi sa akin na ang programmer na nagmana ng aking code ay napopoot sa akin.

Lesson learned

Tulad ng isinulat nina David Patterson at John Hennessy sa Computer Architecture at Computer Systems Design, isa sa mga pangunahing prinsipyo ng arkitektura at disenyo ay ang pangkalahatang gawing gumagana ang mga bagay sa lalong madaling panahon.

Ang pagpapabilis ng mga karaniwang kaso ay magpapahusay sa pagganap nang mas epektibo kaysa sa pag-optimize ng mga bihirang kaso. Kabalintunaan, ang mga karaniwang kaso ay kadalasang mas simple kaysa sa mga bihirang. Ipinapalagay ng lohikal na payo na ito na alam mo kung aling kaso ang itinuturing na karaniwan - at posible lamang ito sa pamamagitan ng proseso ng maingat na pagsubok at pagsukat.

Sa aking pagtatanggol, sinubukan kong malaman kung ano ang hitsura ng mga pahayag ng sangay sa pagsasanay (tulad ng kung gaano karaming mga sangay ang mayroon at kung paano ipinamahagi ang mga constant), ngunit noong 1988 ang impormasyong ito ay hindi magagamit. Gayunpaman, hindi dapat ako nagdagdag ng mga espesyal na kaso sa tuwing ang kasalukuyang compiler ay hindi makabuo ng pinakamainam na code para sa artipisyal na halimbawa na aking naisip.

Kailangan kong tumawag sa isang may karanasang developer at, kasama niya, isipin kung ano ang mga karaniwang kaso at partikular na harapin ang mga ito. Magsusulat ako ng mas kaunting code, ngunit iyon ay isang magandang bagay. Tulad ng isinulat ng tagapagtatag ng Stack Overflow na si Jeff Atwood, ang pinakamasamang kaaway ng isang programmer ay ang programmer mismo:

Alam kong ikaw ang may pinakamabuting hangarin, gaya nating lahat. Gumagawa kami ng mga programa at mahilig magsulat ng code. Ganyan tayo ginawa. Sa tingin namin, ang anumang problema ay malulutas sa duct tape, isang gawang bahay na saklay at isang kurot ng code. Kahit masakit sa mga coder na aminin ito, ang pinakamagandang code ay ang code na wala. Ang bawat bagong linya ay nangangailangan ng pag-debug at suporta, kailangan itong maunawaan. Kapag nagdagdag ka ng bagong code, dapat mong gawin ito nang may pag-aatubili at pagkasuklam dahil ang lahat ng iba pang mga opsyon ay naubos na. Maraming mga programmer ang sumusulat ng masyadong maraming code, na ginagawa itong ating kaaway.

Kung nagsulat ako ng mas simpleng code na sumasaklaw sa mga karaniwang kaso, magiging mas madaling i-update kung kinakailangan. Nag-iwan ako ng gulo na walang gustong harapin.

Pangalawang lugar: advertising sa mga social network

Noong nagtatrabaho ako sa Google sa advertising sa social media (tandaan ang Myspace?), nagsulat ako ng ganito sa 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)) {
  }
}

Maaaring makita agad ng mga programmer ang error: ang huling argument ay dapat na j, hindi i. Ang pagsubok sa unit ay hindi nagpahayag ng error, at gayundin ang aking tagasuri. Isinagawa ang paglulunsad, at isang gabi napunta ang code ko sa server at na-crash ang lahat ng computer sa data center.

Walang nangyaring masama. Walang nasira para sa sinuman, dahil bago ang pandaigdigang paglulunsad ang code ay nasubok sa loob ng isang data center. Maliban kung ang mga inhinyero ng SRE ay tumigil sa paglalaro ng bilyar saglit at gumawa ng kaunting rollback. Kinaumagahan nakatanggap ako ng email na may crash dump, itinama ang code at nagdagdag ng mga unit test na makakahuli sa error. Dahil sinunod ko ang protocol - kung hindi ay mabibigo lang na tumakbo ang aking code - walang ibang mga problema.

Lesson learned

Marami ang nakatitiyak na ang gayong malaking pagkakamali ay tiyak na magagastos sa pagpapaalis sa salarin, ngunit hindi ito ganoon: una, lahat ng mga programmer ay nagkakamali, at pangalawa, bihira silang gumawa ng parehong pagkakamali nang dalawang beses.

Sa katunayan, mayroon akong kaibigan na programmer na isang napakatalino na inhinyero at tinanggal dahil sa isang pagkakamali. Pagkatapos noon, natanggap siya sa Google (at hindi nagtagal ay na-promote) - tapat niyang sinabi ang pagkakamaling nagawa niya sa isang panayam, at hindi ito itinuring na nakamamatay.

Narito kung ano sabihin tungkol kay Thomas Watson, ang maalamat na pinuno ng IBM:

Isang utos ng gobyerno na nagkakahalaga ng halos isang milyong dolyar ang inihayag. IBM Corporation - o sa halip, personal na gusto ni Thomas Watson Sr. - talagang gustong makuha ito. Sa kasamaang palad, hindi ito nagawa ng sales representative at natalo ang IBM sa bid. Kinabukasan, pumasok ang empleyadong ito sa opisina ni G. Watson at naglagay ng sobre sa kanyang mesa. Si Mr. Watson ay hindi man lang nag-abala na tingnan ito - naghihintay siya ng isang empleyado at alam niya na ito ay isang sulat ng pagbibitiw.

Tinanong ni Watson kung ano ang nangyari.

Detalyadong nagsalita ang sales representative tungkol sa progreso ng tender. Pinangalanan niya ang mga pagkakamaling nagawa na maaaring iwasan. Sa wakas, sinabi niya, “Mr. Watson, salamat sa pagpayag mo sa akin na magpaliwanag. Alam ko kung gaano namin kailangan ang order na ito. Alam ko kung gaano siya kahalaga,” at naghanda na para umalis.

Lumapit sa kanya si Watson sa pintuan, tiningnan siya sa mga mata at ibinalik ang sobre na may mga salitang: “Paano kita pakakawalan? Nag-invest lang ako ng isang milyong dolyar sa iyong pag-aaral.

Mayroon akong T-shirt na nagsasabing: "Kung talagang natututo ka sa mga pagkakamali, isa na akong master." Sa katunayan, pagdating sa mga pagkakamali, ako ay isang doktor ng agham.

Unang lugar: App Inventor API

Ang tunay na kakila-kilabot na mga error ay nakakaapekto sa isang malaking bilang ng mga gumagamit, naging kaalaman ng publiko, tumatagal ng mahabang panahon upang iwasto, at ginawa ng mga hindi maaaring gumawa ng mga ito. Ang aking pinakamalaking pagkakamali ay umaangkop sa lahat ng pamantayang ito.

Ang masama mas mabuti

nabasa ko sanaysay ni Richard Gabriel tungkol sa diskarteng ito noong dekada nobenta bilang isang nagtapos na mag-aaral, at gusto ko ito kaya itinatanong ko ito sa aking mga mag-aaral. Kung hindi mo ito matandaan ng mabuti, i-refresh ang iyong memorya, ito ay maliit. Inihambing ng sanaysay na ito ang pagnanais na "itama ito" at ang "mas masahol pa ay mas mahusay" na diskarte sa maraming paraan, kabilang ang pagiging simple.

Paano ito dapat: ang disenyo ay dapat na simple sa pagpapatupad at interface. Ang pagiging simple ng interface ay mas mahalaga kaysa sa pagiging simple ng pagpapatupad.

Ang mas masahol pa, mas mabuti: ang disenyo ay dapat na simple sa pagpapatupad at interface. Ang pagiging simple ng pagpapatupad ay mas mahalaga kaysa sa pagiging simple ng interface.

Kalimutan natin iyon kahit sandali. Sa kasamaang palad, nakalimutan ko ito sa loob ng maraming taon.

Imbentor ng App

Habang nagtatrabaho sa Google, bahagi ako ng team Imbentor ng App, isang drag-and-drop na online development environment para sa mga nagnanais na mga developer ng Android. Taong 2009 noon, at nagmamadali kaming ilabas ang alpha version sa oras upang sa tag-araw ay makapagdaos kami ng mga master class para sa mga guro na maaaring gumamit ng kapaligiran kapag nagtuturo sa taglagas. Nagboluntaryo akong magpatupad ng mga sprite, nostalhik sa kung paano ako sumulat ng mga laro sa TI-99/4. Para sa mga hindi nakakaalam, ang sprite ay isang two-dimensional na graphical na bagay na maaaring gumalaw at makipag-ugnayan sa ibang mga elemento ng software. Kabilang sa mga halimbawa ng sprite ang mga spaceship, asteroid, marbles, at racket.

Nagpatupad kami ng object-oriented na App Inventor sa Java, kaya mayroong isang grupo ng mga bagay doon. Dahil halos magkapareho ang kilos ng mga bola at sprite, gumawa ako ng abstract sprite class na may mga katangian (mga patlang) X, Y, Bilis (bilis) at Heading (direksyon). Mayroon silang parehong mga pamamaraan para sa pag-detect ng mga banggaan, pagtalbog sa gilid ng screen, atbp.

Ang pangunahing pagkakaiba sa pagitan ng isang bola at isang sprite ay kung ano ang eksaktong iginuhit - isang puno na bilog o isang raster. Dahil ipinatupad ko muna ang mga sprite, lohikal na tukuyin ang mga x- at y-coordinate ng kaliwang sulok sa itaas kung saan matatagpuan ang imahe.

Kapag gumagana na ang mga sprite, napagpasyahan kong maipapatupad ko ang mga ball object na may napakaliit na code. Ang tanging problema ay kinuha ko ang pinakasimpleng ruta (mula sa punto ng view ng tagapagpatupad), na nagpapahiwatig ng x- at y-coordinate ng itaas na kaliwang sulok ng contour na nag-frame ng bola.

Sa katunayan, kinakailangang ipahiwatig ang x- at y-coordinate ng gitna ng bilog, tulad ng itinuro sa anumang aklat-aralin sa matematika at anumang iba pang mapagkukunan na nagbabanggit ng mga bilog.

Hindi tulad ng mga nakaraang pagkakamali ko, naapektuhan ng isang ito hindi lang ang aking mga kasamahan, kundi pati na rin ang milyun-milyong user ng App Inventor. Marami sa kanila ay mga bata o ganap na bago sa programming. Kailangan nilang magsagawa ng maraming hindi kinakailangang mga hakbang kapag nagtatrabaho sa bawat aplikasyon kung saan naroroon ang bola. Kung naaalala ko ang iba ko pang mga pagkakamali sa pagtawa, kung gayon ang isang ito ay nagpapawis sa akin kahit ngayon.

Sa wakas ay na-patch ko ang bug na ito kamakailan lamang, makalipas ang sampung taon. "Na-patch", hindi "naayos", dahil gaya ng sabi ni Joshua Bloch, ang mga API ay walang hanggan. Hindi makagawa ng mga pagbabagong makakaapekto sa mga kasalukuyang program, idinagdag namin ang OriginAtCenter property na may value na false sa mga lumang program at true sa lahat ng mga hinaharap. Ang mga gumagamit ay maaaring magtanong ng isang lohikal na tanong: na kahit na naisip na ilagay ang panimulang punto sa isang lugar maliban sa gitna. Para kanino? Sa isang programmer na masyadong tamad na lumikha ng isang normal na API sampung taon na ang nakararaan.

Mga aral na natutunan

Kapag nagtatrabaho sa mga API (na halos lahat ng programmer ay kailangang gawin minsan), dapat mong sundin ang pinakamahusay na payo na nakabalangkas sa video ni Joshua Bloch "Paano gumawa ng magandang API at kung bakit ito napakahalaga"O sa maikling listahang ito:

• Ang isang API ay maaaring magdala sa iyo ng parehong malaking pakinabang at malaking pinsala.. Ang isang mahusay na API ay lumilikha ng mga umuulit na customer. Ang masama ay nagiging iyong walang hanggang bangungot.
• Ang mga pampublikong API, tulad ng mga diamante, ay tumatagal magpakailanman. Ibigay mo ang lahat: hindi na magkakaroon ng isa pang pagkakataon na gawin ang lahat ng tama.
• Ang mga balangkas ng API ay dapat na maikli — isang pahina na may mga lagda at paglalarawan ng klase at pamamaraan, na tumatagal ng hindi hihigit sa isang linya. Papayagan ka nitong madaling ayusin ang API kung hindi ito magiging perpekto sa unang pagkakataon.
• Ilarawan ang mga kaso ng paggamitbago ipatupad ang API o kahit na magtrabaho sa detalye nito. Sa ganitong paraan maiiwasan mo ang pagpapatupad at pagtukoy ng ganap na hindi gumaganang API.

Kung nagsulat ako ng kahit isang maikling buod na may artipisyal na script, malamang na natukoy ko ang pagkakamali at naitama ko ito. Kung hindi, tiyak na gagawin ito ng isa sa aking mga kasamahan. Anumang desisyon na may malalayong kahihinatnan ay kailangang pag-isipan nang hindi bababa sa isang araw (ito ay nalalapat hindi lamang sa programming).

Ang pamagat ng sanaysay ni Richard Gabriel, "Mas Mabuti," ay tumutukoy sa kalamangan na napupunta sa pagiging una sa merkado-kahit na may isang hindi perpektong produkto-habang ang ibang tao ay gumugugol ng walang hanggan sa paghabol sa perpekto. Sa pagmumuni-muni sa sprite code, napagtanto ko na hindi ko na kinailangan pang magsulat ng higit pang code para maayos ito. Anuman ang sabihin ng isa, ako ay lubos na nagkamali.

Konklusyon

Ang mga programmer ay nagkakamali araw-araw, sumusulat man ito ng buggy code o hindi gustong sumubok ng isang bagay na magpapahusay sa kanilang kakayahan at pagiging produktibo. Siyempre, maaari kang maging isang programmer nang hindi gumagawa ng malubhang pagkakamali tulad ng ginawa ko. Ngunit imposibleng maging isang mahusay na programmer nang hindi kinikilala ang iyong mga pagkakamali at natututo mula sa kanila.

Palagi akong nakakaharap ng mga mag-aaral na pakiramdam nila ay napakaraming pagkakamali at samakatuwid ay hindi nababagay sa programming. Alam ko kung gaano kadalas ang impostor syndrome sa IT. Sana ay matutunan mo ang mga aral na inilista ko - ngunit tandaan ang pangunahing isa: bawat isa sa atin ay nagkakamali - nakakahiya, nakakatawa, nakakatakot. Magugulat ako at magalit kung sa hinaharap ay wala akong sapat na materyal upang ipagpatuloy ang artikulo.

Pinagmulan: www.habr.com