ApkaunojoŔākās kļūdas manā programmÄ“Å”anas karjerā (lÄ«dz Å”im)

ApkaunojoŔākās kļūdas manā programmÄ“Å”anas karjerā (lÄ«dz Å”im)
Kā saka, ja tev nav kauna par savu veco kodu, tad tu neaug par programmētāju - un es piekrÄ«tu Å”im viedoklim. Es sāku programmēt prieka pēc vairāk nekā pirms 40 gadiem un profesionāli pirms 30 gadiem, tāpēc man ir daudz kļūdu. ļoti daudz. Kā datorzinātņu profesors es mācu saviem studentiem mācÄ«ties no savām, manām un citu kļūdām. Es domāju, ka ir pienācis laiks runāt par savām kļūdām, lai nezaudētu savu pieticÄ«bu. Ceru, ka kādam tie noderēs.

TreŔā vieta - Microsoft C kompilators

Mana skolas skolotāja uzskatÄ«ja, ka Romeo un Džuljetu nevar uzskatÄ«t par traģēdiju, jo varoņiem nebija traÄ£iskas vainas ā€“ viņi vienkārÅ”i uzvedās stulbi, kā jau pusaudžiem pienākas. Toreiz es viņam nepiekritu, bet tagad viņa uzskatos saskatu racionalitātes graudu, Ä«paÅ”i saistÄ«bā ar programmÄ“Å”anu.

Kad es pabeidzu savu otro kursu MIT, es biju jauns un nepieredzējis gan dzÄ«vē, gan programmÄ“Å”anas jomā. Vasarā stažējos Microsoft kompilatoru komandā C. Sākumā veicu tādas ikdieniŔķas lietas kā profilÄ“Å”anas atbalsts, bet pēc tam man uzticēja strādāt pie kompilatora jautrākās daļas (kā es domāju) - aizmugursistēmas optimizācijas. Jo Ä«paÅ”i man bija jāuzlabo x86 kods filiāles paziņojumiem.

Apņēmies uzrakstÄ«t optimālo maŔīnas kodu katram iespējamajam gadÄ«jumam, es metos baseinā ar galvu. Ja vērtÄ«bu sadalÄ«juma blÄ«vums bija augsts, es tās ievadÄ«ju pārejas tabula. Ja tiem bija kopÄ«gs dalÄ«tājs, es to izmantoju, lai padarÄ«tu tabulu stingrāku (bet tikai tad, ja dalÄ«jumu var veikt, izmantojot bitu maiņa). Kad visas vērtÄ«bas bija divas, es veicu vēl vienu optimizāciju. Ja vērtÄ«bu kopa neatbilda maniem nosacÄ«jumiem, es to sadalÄ«ju vairākos optimizējamos gadÄ«jumos un izmantoju jau optimizēto kodu.

Tas bija murgs. Pēc daudziem gadiem man teica, ka programmētājs, kurÅ” mantoja manu kodu, mani ienÄ«st.

ApkaunojoŔākās kļūdas manā programmÄ“Å”anas karjerā (lÄ«dz Å”im)

Gūta mācība

Kā raksta Deivids Patersons un Džons Hennessijs grāmatā Computer Architecture and Computer Systems Design, viens no galvenajiem arhitektūras un dizaina principiem ir panākt, lai lietas darbotos pēc iespējas ātrāk.

Paātrinot parastos gadÄ«jumus, veiktspēja uzlabosies daudz efektÄ«vāk nekā optimizējot retos gadÄ«jumos. Ironiski, ka bieži sastopamie gadÄ«jumi bieži ir vienkārŔāki nekā reti. Å is loÄ£iskais padoms paredz, ka jÅ«s zināt, kurÅ” gadÄ«jums tiek uzskatÄ«ts par izplatÄ«tu, un tas ir iespējams, tikai rÅ«pÄ«gi pārbaudot un veicot mērÄ«jumus.

Savā aizstāvÄ«bā es mēģināju noskaidrot, kā praksē izskatās zaru paziņojumi (piemēram, cik zaru ir un kā konstantes tika sadalÄ«tas), taču 1988. gadā Ŕī informācija nebija pieejama. Tomēr man nevajadzēja pievienot Ä«paÅ”us gadÄ«jumus, kad paÅ”reizējais kompilators nevarēja Ä£enerēt optimālu kodu mākslÄ«gajam piemēram, ko es izdomāju.

Vajadzēja piezvanÄ«t pieredzējuÅ”am izstrādātājam un kopā ar viņu padomāt, kādi ir izplatÄ«tākie gadÄ«jumi, un risināt tos konkrēti. Es rakstÄ«tu mazāk kodu, bet tas ir labi. Kā rakstÄ«ja Stack Overflow dibinātājs Džefs Atvuds, programmētāja ļaunākais ienaidnieks ir pats programmētājs:

Es zinu, ka jums, tāpat kā mums visiem, ir vislabākie nodomi. Mēs veidojam programmas un mums patÄ«k rakstÄ«t kodu. Tā mēs esam radÄ«ti. Mēs domājam, ka jebkuru problēmu var atrisināt ar lÄ«mlenti, paÅ”taisÄ«tu kruÄ·i un Ŕķipsniņu koda. Lai arÄ« cik sāpÄ«gi kodētājiem to atzÄ«t, labākais kods ir kods, kas neeksistē. Katrai jaunai rindai ir nepiecieÅ”ama atkļūdoÅ”ana un atbalsts, tas ir jāsaprot. Pievienojot jaunu kodu, tas jādara ar nelabprātÄ«bu un riebumu, jo visas pārējās iespējas ir izsmeltas. Daudzi programmētāji raksta pārāk daudz koda, padarot to par mÅ«su ienaidnieku.

Ja es bÅ«tu uzrakstÄ«jis vienkārŔāku kodu, kas aptvertu izplatÄ«tus gadÄ«jumus, vajadzÄ«bas gadÄ«jumā to bÅ«tu bijis daudz vieglāk atjaunināt. Es atstāju aiz sevis nekārtÄ«bu, ar kuru neviens negribēja tikt galā.

ApkaunojoŔākās kļūdas manā programmÄ“Å”anas karjerā (lÄ«dz Å”im)

Otrā vieta: reklāma sociālajos tīklos

Kad strādāju Google ar sociālo mediju reklāmu (atceraties Myspace?), es C++ ierakstīju kaut ko līdzīgu:

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

Programmētāji var uzreiz redzēt kļūdu: pēdējam argumentam jābÅ«t j, nevis i. VienÄ«bas pārbaude neatklāja kļūdu, un to neatklāja arÄ« mans recenzents. PalaiÅ”ana tika veikta, un kādu nakti mans kods nonāca serverÄ« un avarēja visi datu centra datori.

Nekas slikts nenotika. Nevienam nekas nesaplÄ«sa, jo pirms globālās palaiÅ”anas kods tika testēts viena datu centra ietvaros. Ja vien SRE inženieri kādu laiku nepārtrauks spēlēt biljardu un nedaudz atkāpās. Nākamajā rÄ«tā es saņēmu e-pastu ar avārijas izgāztuvi, izlaboju kodu un pievienoju vienÄ«bas testus, kas atklās kļūdu. Tā kā es ievēroju protokolu - pretējā gadÄ«jumā mans kods vienkārÅ”i nedarbosies, citu problēmu nebija.

ApkaunojoŔākās kļūdas manā programmÄ“Å”anas karjerā (lÄ«dz Å”im)

Gūta mācība

Daudzi ir pārliecināti, ka Ŕāda liela kļūda noteikti maksās vainÄ«go atlaiÅ”anu, taču tas tā nav: pirmkārt, visi programmētāji pieļauj kļūdas, un, otrkārt, viņi reti pieļauj vienu un to paÅ”u kļūdu divas reizes.

PatiesÄ«bā man ir draugs programmētājs, kurÅ” bija izcils inženieris un tika atlaists par vienu kļūdu. Pēc tam viņŔ tika pieņemts darbā Google (un drÄ«z tika paaugstināts) - viņŔ godÄ«gi runāja par kļūdu, ko viņŔ pieļāva intervijā, un tā netika uzskatÄ«ta par liktenÄ«gu.

Tas ir kas pastāsti par Tomasu Vatsonu, leģendāro IBM vadītāju:

Tika paziņots par valdÄ«bas pasÅ«tÄ«jumu aptuveni miljona dolāru vērtÄ«bā. IBM korporācija ā€“ pareizāk sakot, Tomass Vatsons vecākais personÄ«gi ā€“ ļoti vēlējās to iegÅ«t. Diemžēl tirdzniecÄ«bas pārstāvis to nevarēja izdarÄ«t, un IBM zaudēja piedāvājumu. Nākamajā dienā Å”is darbinieks ienāca Vatsona kunga kabinetā un nolika uz viņa galda aploksni. Vatsona kungs pat nepÅ«lējās uz to paskatÄ«ties ā€“ viņŔ gaidÄ«ja darbinieku un zināja, ka tā ir atlÅ«guma vēstule.

Vatsons jautāja, kas nogāja greizi.

TirdzniecÄ«bas pārstāvis detalizēti stāstÄ«ja par konkursa norisi. ViņŔ nosauca pieļautās kļūdas, no kurām varēja izvairÄ«ties. Visbeidzot viņŔ teica: "Votsona kungs, paldies, ka ļāvāt man paskaidrot. Es zinu, cik ļoti mums bija vajadzÄ«gs Å”is pasÅ«tÄ«jums. Es zinu, cik viņŔ bija svarÄ«gs,ā€ un gatavojās doties prom.

Vatsons piegāja viņam pie durvÄ«m, paskatÄ«jās viņam acÄ«s un atdeva aploksni ar vārdiem: ā€œKā es varu tevi palaist? Es tikko ieguldÄ«ju miljonu dolāru jÅ«su izglÄ«tÄ«bā.

Man ir T-krekls, uz kura ir rakstÄ«ts: "Ja tu tieŔām mācies no kļūdām, tad es jau esmu meistars." PatiesÄ«bā, runājot par kļūdām, es esmu zinātņu doktors.

Pirmā vieta: App Inventor API

PatieŔām briesmÄ«gas kļūdas ietekmē milzÄ«gu skaitu lietotāju, kļūst publiski zināmas, to laboÅ”ana prasa ilgu laiku, un tās pieļauj tie, kuri nav varējuÅ”i tās pieļaut. Mana lielākā kļūda atbilst visiem Å”iem kritērijiem.

Jo sliktāk, jo labāk

ES lasu Ričarda Gabriela eseja par Å”o pieeju deviņdesmitajos gados kā maÄ£istrants, un man tā tik ļoti patÄ«k, ka jautāju saviem studentiem. Ja jÅ«s to labi neatceraties, atsvaidziniet atmiņu, tā ir maza. Å ajā esejā daudzos veidos, tostarp vienkārŔībā, tiek pretstatÄ«ta vēlme ā€œlabotā€ un ā€œsliktāk, jo labākā€.

Kā tam vajadzētu bÅ«t: dizainam jābÅ«t vienkārÅ”am ievieÅ”anai un saskarnei. Interfeisa vienkārŔība ir svarÄ«gāka par ievieÅ”anas vienkārŔību.

Jo sliktāk, jo labāk: dizainam jābūt vienkārŔam gan ievieŔanai, gan saskarnei. IevieŔanas vienkārŔība ir svarīgāka par saskarnes vienkārŔību.

Aizmirsīsim par to uz minūti. Diemžēl es par to aizmirsu daudzus gadus.

Lietotņu izgudrotājs

Strādājot Google, es biju daļa no komandas Lietotņu izgudrotājs, vilkÅ”anas un nomeÅ”anas tieÅ”saistes izstrādes vide topoÅ”ajiem Android izstrādātājiem. Bija 2009. gads, un mēs steidzāmies laicÄ«gi izdot alfa versiju, lai vasarā varētu rÄ«kot meistarklases skolotājiem, kuri varētu izmantot vidi, mācot rudenÄ«. Es brÄ«vprātÄ«gi pieteicos ieviest spraitus, jo man bija nostalÄ£ija par to, kā es mēdzu rakstÄ«t spēles uz TI-99/4. Tiem, kas nezina, sprite ir divdimensiju grafisks objekts, kas var pārvietoties un mijiedarboties ar citiem programmatÅ«ras elementiem. Spraitu piemēri ir kosmosa kuÄ£i, asteroÄ«di, bumbiņas un raketes.

Mēs Java ieviesām objektu orientētu App Inventor, tāpēc tajā ir tikai virkne objektu. Tā kā bumbiņas un spraiti uzvedas ļoti lÄ«dzÄ«gi, es izveidoju abstraktu spraitu klasi ar Ä«paŔībām (laukiem) X, Y, Ātrums (ātrums) un Virziens (virziens). Viņiem bija tādas paÅ”as metodes sadursmju noteikÅ”anai, atlēcieniem no ekrāna malas utt.

Galvenā atŔķirÄ«ba starp bumbu un spraitu ir tieÅ”i tajā, kas ir uzzÄ«mēts ā€“ aizpildÄ«ts aplis vai rastrs. Tā kā es vispirms ieviesu spraitus, bija loÄ£iski norādÄ«t attēla atraÅ”anās vietas augŔējā kreisā stÅ«ra x un y koordinātas.

ApkaunojoŔākās kļūdas manā programmÄ“Å”anas karjerā (lÄ«dz Å”im)
Kad spraiti darbojās, es nolēmu, ka varu ieviest lodÄ«Å”u objektus ar ļoti mazu kodu. VienÄ«gā problēma bija tā, ka izvēlējos vienkārŔāko marÅ”rutu (no realizētāja viedokļa), norādot bumbu ierāmējoŔās kontÅ«ras augŔējā kreisā stÅ«ra x un y koordinātas.

ApkaunojoŔākās kļūdas manā programmÄ“Å”anas karjerā (lÄ«dz Å”im)
Faktiski bija jānorāda apļa centra x un y koordinātas, kā to māca jebkurā matemātikas mācību grāmatā un jebkurā citā avotā, kurā minēti apļi.

ApkaunojoŔākās kļūdas manā programmÄ“Å”anas karjerā (lÄ«dz Å”im)
AtŔķirÄ«bā no manām pagātnes kļūdām, Ŕī skāra ne tikai manus kolēģus, bet arÄ« miljoniem App Inventor lietotāju. Daudzi no viņiem bija bērni vai pilnÄ«gi jauni programmÄ“Å”ana. Viņiem bija jāveic daudz nevajadzÄ«gu darbÄ«bu, strādājot pie katras programmas, kurā bija bumba. Ja ar smiekliem atceros citas savas kļūdas, tad Ŕī man liek pasvÄ«st arÄ« Å”odien.

Es beidzot izlaboju Å”o kļūdu tikai nesen, desmit gadus vēlāk. ā€œLabotsā€, nevis ā€œizlabotsā€, jo, kā saka DžoÅ”ua Blohs, API ir mūžīgas. Nevarot veikt izmaiņas, kas ietekmētu esoŔās programmas, mēs pievienojām OriginAtCenter rekvizÄ«tu ar vērtÄ«bu false vecajās programmās un true visās turpmākajās programmās. Lietotāji var uzdot loÄ£isku jautājumu: kurÅ” vispār domāja novietot sākumpunktu kaut kur citur, nevis centrā. Kam? Vienam programmētājam, kurÅ” pirms desmit gadiem bija par slinku, lai izveidotu normālu API.

Gūtās mācības

Strādājot ar API (kas dažreiz ir jādara gandrÄ«z katram programmētājam), jums jāievēro vislabākie padomi, kas izklāstÄ«ti DžoÅ”ua Bloha videoklipā.Kā izveidot labu API un kāpēc tas ir tik svarÄ«gi"Or Å”ajā Ä«sajā sarakstā:

  • API var sniegt jums gan lielu labumu, gan lielu kaitējumu.. Laba API rada atkārtotus klientus. Sliktais kļūst par tavu mūžīgo murgu.
  • Publiskās API, tāpat kā dimanti, kalpo mūžīgi. Atdodiet visu: nekad vairs nebÅ«s iespējas izdarÄ«t visu pareizi.
  • API kontÅ«rām jābÅ«t Ä«sām ā€” viena lapa ar klaÅ”u un metožu parakstiem un aprakstiem, kas aizņem ne vairāk kā vienu rindiņu. Tas ļaus jums viegli pārstrukturēt API, ja tas pirmajā reizē neizrādÄ«sies ideāls.
  • Aprakstiet lietoÅ”anas gadÄ«jumuspirms API ievieÅ”anas vai pat darba pie tās specifikācijas. Tādā veidā jÅ«s izvairÄ«sieties no pilnÄ«bā nefunkcionējoÅ”a API ievieÅ”anas un norādÄ«Å”anas.

Ja es bÅ«tu uzrakstÄ«jis kaut Ä«su konspektu ar mākslÄ«gu skriptu, visticamāk, es bÅ«tu identificējis kļūdu un to izlabojis. Ja nē, tad kāds no maniem kolēģiem noteikti to darÄ«tu. Par jebkuru lēmumu, kam ir tālejoÅ”as sekas, ir jādomā vismaz dienu (tas attiecas ne tikai uz programmÄ“Å”anu).

Ričarda Gabriela esejas nosaukums ā€œSliktāks ir labāksā€ norāda uz priekÅ”rocÄ«bu, kas rodas pirmajam tirgÅ« ā€” pat ar nepilnÄ«gu produktu ā€”, kamēr kāds cits pavada mūžību, dzenoties pēc perfektā. Pārdomājot sprite kodu, es saprotu, ka man pat nebija jāraksta vairāk koda, lai tas bÅ«tu pareizi. Lai ko arÄ« teiktu, es rupji kļūdÄ«jos.

Secinājums

Programmētāji katru dienu pieļauj kļūdas neatkarīgi no tā, vai tas raksta kļūdainu kodu vai nevēlas izmēģināt kaut ko, kas uzlabos viņu prasmes un produktivitāti. Protams, jūs varat būt programmētājs, nepieļaujot tik nopietnas kļūdas kā es. Bet nav iespējams kļūt par labu programmētāju, neatzīstot savas kļūdas un nemācoties no tām.

Es pastāvÄ«gi sastopos ar studentiem, kuriem Ŕķiet, ka viņi pieļauj pārāk daudz kļūdu un tāpēc nav gatavi programmÄ“Å”anai. Es zinu, cik izplatÄ«ts krāpnieku sindroms ir IT jomā. Es ceru, ka jÅ«s iemācÄ«sities manis uzskaitÄ«tās mācÄ«bas, taču atcerieties galveno: katrs no mums pieļauj kļūdas - apkaunojoÅ”as, smieklÄ«gas, briesmÄ«gas. BÅ«Å”u pārsteigts un sarÅ«gtināts, ja turpmāk man nepietiks materiāla raksta turpināŔanai.

Avots: www.habr.com

Pievieno komentāru