Pagsusuri ng mga karaniwang pagkakamali ng mga baguhan na programmer: bahagi 1

Hello, mundo! Pagkatapos mong matutunan ang lahat ng kailangan mo at tuluyang matanggap bilang intern o junior, makakapag-relax ka na, di ba? Hindi mahalaga kung paano ito ay! Nagsisimula pa lang ang lahat... Maraming bago at hindi maintindihan na mga bagay sa paligid mo, at paanong hindi masisira ang ganito sa labas ng gate? Iyan ang pag-uusapan natin ngayon. Sa artikulong ito, gusto kong tingnan ang mga karaniwang pagkakamali ng mga nagsisimula at magbigay ng ilang mga tip mula sa sarili kong karanasan kung paano maiiwasan ang mga ito. Kaya, magsimula tayo nang walang karagdagang ado:

1. Takot na humingi ng tulong sa mas maraming karanasang kasamahan

Lahat tayo ay tao, at lahat tayo ay natatakot na magmukhang tanga, lalo na sa mga mata ng ating mga bagong minted, mas makaranasang kasamahan. Sa sandaling makuha na nila ang kanilang unang trabaho, madalas na binibigyan ng mga developer ang takot na ito at walang humpay na umatras sa kanilang sarili, sinusubukang alamin ang lahat sa kanilang sarili. Kasabay nito, ang isang tao ay maaaring mapalibutan ng mas maraming karanasan na mga kasamahan, na, sa turn, ay magagawang gabayan siya sa pinakatamang landas, na makakatulong upang maiwasan ang higit pang mga pagkakamali at hindi kinakailangang "mga bumps". Samakatuwid, tandaan: huwag matakot na magtanong: ikaw ay isang baguhan, at naiintindihan ito ng lahat. Kapag nagtanong ka, walang papalo sa iyo ng pamalo. Marahil ito ay kabaligtaran pa rin: mas mabilis kang makikipagkaibigan sa iyong mga kasamahan at magsisimulang makipag-ugnayan nang mas aktibo sa kanila. Sasabihin ko pa: kapag mas nagtatanong at tinatalakay mo ang iba't ibang mga teknikal na isyu, mas mabilis kang makakaalis sa mga sapatos ng isang berdeng baguhan at lumaki bilang isang dalubhasa sa iyong larangan. At isa pang payo. Huwag pabayaan ang StackOverFlow . Sa kontekstong ito, ang ibig kong sabihin ay pagtatanong sa mapagkukunang ito. Sa isang banda, nangangailangan ng ilang oras upang makakuha ng sagot sa iyong tanong. Ngunit sa kabilang banda, maaari mong malaman kaagad ang tungkol sa ilang mga diskarte sa paglutas ng kasalukuyang problema at tingnan ito mula sa isang bahagyang naiibang pananaw. Nais ko ring tandaan na ang pagsulat ng mga komento-sagot, paglilinaw ng mga tanong sa mga tanong sa StackOverFlow mula sa iba pang mga developer, bilang karagdagan sa isang plus sa karma, ay may praktikal na benepisyo: mayroon kang pagkakataon na talakayin at maunawaan ang isyung ito nang mas malalim.

2. Huwag subukang maghanap ng impormasyon sa iyong sarili

Marahil ang error na ito ay ang reverse side ng nauna. I mean kapag sinimulan mong hatakin ang iyong mga kasamahan at kakilala sa bawat problema o problema. Mabuti ang pagtatanong, ngunit hindi ka dapat lumayo sa mga tanong, kung hindi, baka magsawa ka lang. Ang unang bagay na dapat gawin kung may dumating na hindi maintindihan na punto ay ilapat ang iyong mga kasanayan sa paghahanap sa pinakamahusay na search engine - Google. May nakatagpo na ng karamihan sa mga hindi maintindihang error at iba pang isyu. At medyo magugulat ka kung i-Google mo ito at makita ang bilang ng mga taong pamilyar sa isang katulad na problema, at nakatanggap na ng mga komprehensibong sagot na angkop para magamit sa kanilang trabaho. Batay dito, madalas mong marinig ang isang kasamahan sa pagsagot sa isang tanong - "I-Google ito." Hindi ka dapat masaktan sa sagot na ito, dahil pagkatapos ng lahat, ang iyong kasamahan ay hindi isang personal na guro na dapat maghatid ng lahat ng mga intricacies ng iyong larangan ng trabaho. Ang walang katapusang kalawakan ng Internet ay tutulong sa iyo sa gayong paggabay. Minsan ang isang programmer ay tinatawag ding isang taong may itim na sinturon sa paghahanap sa Google . Samakatuwid, kapag natigil kami, i-Google muna namin ang problema, at kung walang nahanap na solusyon (bihira, ngunit nangyayari ito), pagkatapos ay magsisimula kaming magtanong sa aming mga kasamahan. Ito ay nagkakahalaga ng pagtatanong sa kanila kaagad, hindi kapag mayroong ilang uri ng glitch o hindi maintindihan na pagkakamali, ngunit kapag pumipili ng isang diskarte upang malutas ang isang problema. Pagkatapos ng lahat, maaari nilang makita ang higit pa sa iyo at agad na sabihin kung paano ito o ang diskarte na iyon ay maaaring maging resulta sa katagalan.

3. Blind copy-paste

Ngunit Googling ang problema at, nang naaayon, ang solusyon nito ay may mga pitfalls nito. Halimbawa, blind copy-paste . Karaniwang nangyayari ito kapag nakakita ka ng katulad na problema (ngunit marahil ay hindi eksaktong pareho) at sa ilalim nito, halimbawa, sa StackOverFlow mayroong solusyon. Kinuha mo ang solusyon na ito, kopyahin at i-paste ito sa iyong sarili, nang hindi naglalagay ng masyadong maraming detalye. At pagkatapos ay ikaw o ang iyong mga kasamahan sa proyekto ay nakatuklas ng ilang kakaibang bug o maling pag-uugali ng iyong functionality. At kaagad na walang ideya kung saan nanggaling ang mga binti. Pagkatapos, siyempre, isang lugar na may ganitong code ay matatagpuan, at tiyak na hindi ka pupurihin para sa desisyong ito. Samakatuwid, kapag nakakita ka ng isang handa na solusyon sa StackOverFlow (o sa ibang lugar), una sa lahat dapat mong suriin ito nang detalyado, kung ano ito, paano at bakit. Marahil ay i-google ang pag-andar na ito at tingnan ang dokumentasyon para dito. At pagkatapos lamang na ipatupad ito sa iyong proyekto.

4. Paghahagis ng maling solusyon

Kapag nagsusulat ng isang solusyon, kung minsan ay nangyayari na ito ay nagiging mas kumplikado at kalaunan ay umabot sa isang dead end. At sinusubukan mong gawing kumplikado ito nang higit pa upang kahit papaano ay malutas ang problemang ito gamit ang diskarteng ito sa halip na subukang maghanap ng isa pa, mas magagamit na alternatibo. Marahil ay naaawa ka lang sa lakas at oras na iyong ginugol, kaya't nagpasya ka: anuman ang mangyari, huwag sumuko, ngunit lutasin ang problema sa ganitong paraan. Ito ay hindi ganap na tamang diskarte. At least sa programming. Kapag mas maaga kang sumubok ng ibang diskarte, mas maraming oras ang makakatipid mo. Kaya huwag matakot na mag-eksperimento at subukan ang iba pang mga diskarte, sa kabila ng dami ng oras na iyong namuhunan sa isang ito. Bukod dito, ang mga ito ay magiging mga punto para sa iyong karanasan, dahil susubukan mo ang ilang mga diskarte at mas mahusay na pag-aralan ang lugar na ito.

5. Takot na magtanong tungkol sa kasalukuyang gawain

Ang paggawa sa isang proyekto ay karaniwang nauuwi sa pagkumpleto ng ilang mga gawain (Mga Gawain). Halimbawa, sa Jira . At ang mga gawaing ito ay hindi palaging inilarawan nang detalyado at malinaw. Ang mga ito ay karaniwang isinulat ng mga pinuno ng koponan, at ito rin ay mga tao, kung mangyari iyon. Maaari din nilang makalimutan na magdagdag ng isang bagay o hindi isinasaalang-alang na hindi ka masyadong pamilyar sa ito o sa pag-andar na iyon. Well, o wala kang anumang access sa proyekto (halimbawa, access sa Database, sa log server, at iba pa). At ngayon, na natanggap ang gawain, na pinag-aralan ito nang higit sa ilang oras, nakaupo ka pa rin at tumingin sa screen nang may pagkalito. At sa halip na patuloy na isipin ito nang walang pakinabang, dapat mong simulan ang pagtatanong ng mga nangungunang/paglilinaw ng mga tanong sa lumikha ng gawaing ito. Sabihin nating, sa isang application na ginagamit mo para sa komunikasyon sa isang team (halimbawa, Microsoft Teams) o direkta bilang komento sa ilalim ng gawaing ito. Sa isang banda, kung sumulat ka ng isang tanong sa isang personal na mensahe, malamang na ang sagot ay magiging mas mabilis, dahil makikita kaagad ng tao ang tanong. Sa kabilang banda, sa pamamagitan ng pagtatanong sa Jira, mayroon kang katibayan na may ginagawa ka, ibig sabihin, pagsusuri sa problema. May paraan para mapabilis ang prosesong ito: magtanong bilang komento sa Jira at magpadala ng link sa komentong ito sa isang pribadong mensahe na may kahilingang tingnan.

6. Masyadong umaasa sa pinuno ng pangkat

Muli, ito ang pitik na bahagi ng nakaraang punto. Ang isang team lead ay isang tao na pinuno ng isang development team. Bilang isang tuntunin, karamihan sa oras ng naturang miyembro ng koponan ay ginugugol sa iba't ibang uri ng komunikasyon. At kasabay nito, nagsusulat din siya ng code upang hindi makalimutan kung ano ang lahat. Well, tulad ng naiintindihan mo, ito ay isang napaka-abala na karakter. At ang sobrang pagkibot sa bawat pagbahin ay halatang hindi siya mapapasaya. Isipin kung binomba siya ng bawat miyembro ng koponan ng maraming tanong. Para mabaliw ka diba? At hindi kataka-taka na sa maraming tanong sa iyong bahagi, sasagutin ka niya nang mahabang panahon. Ano ang maaari mong gawin upang bawasan ang bilang ng mga tanong sa pinuno ng pangkat:

• Pag-aralan ang dokumentasyon ng proyektong ito nang mas malalim para mabawasan ang bilang ng mga blind spot.
• Magtanong ng mga tanong sa ibang miyembro ng pangkat. Posible na pamilyar sila sa pagpapaandar na ito bilang nangunguna, o higit pa, dahil malamang na isa sa kanila ang sumulat ng pagpapaandar na iyon.

Bilang kahalili, sa IDE maaari kang tumingin sa mga anotasyon: sino at kailan huling binago ang code sa isang partikular na linya. Sa ganitong paraan malalaman natin kung sino ang pinakatamang magtanong ng tanong na ito. Tulad ng malamang na naintindihan mo na, kapag nagtatanong sa pinuno ng koponan, pati na rin kapag nagtatanong sa mga kasamahan, kailangan mong subukang panatilihin ang ginintuang ibig sabihin - huwag matakot na magtanong, ngunit huwag din silang guluhin ng labis na bilang.

7. Takot sa pagsusuri ng code

Ang pagsusuri ng code o pagsusuri ng code ay isang yugto bago mag-upload ng code sa isang karaniwang application (sa isang karaniwang sangay, halimbawa, master o dev). Isinasagawa ang pagsusuring ito ng isang developer na hindi nauugnay sa gawaing ito, na makakatuklas ng mga error, kamalian, o pagkukulang sa istilo ng code na hindi napansin sa unang yugto ng pag-unlad, nang may bagong hitsura. Kung may mga komento, iniiwan ang mga ito bilang mga komento sa ilang partikular na seksyon ng code. Sa kasong ito, dapat itama ng developer na nagsagawa ng gawaing ito ang mga pagkakamali ayon sa pagsusuri (o talakayin ang kanyang mga desisyon sa tagasuri, marahil ay kumbinsihin siya sa kawastuhan ng kanyang desisyon). Pagkatapos, ipadala ito pabalik para sa pagsusuri, at iba pa hanggang sa walang komento ang tagasuri. Nagsisilbing "filter" ang reviewer bago i-upload ang code. Kaya, maraming mga baguhang programmer ang nakikita ang pagsusuri ng code bilang pagpuna at pagkondena. Hindi nila siya pinahahalagahan at natatakot sa kanya, at iyon ay mali. Ito ay ang pagsusuri ng code na nagbibigay-daan sa amin upang mapabuti ang aming code. Pagkatapos ng lahat, nakakatanggap kami ng mahalagang impormasyon tungkol sa kung ano ang aming ginagawang mali at kung ano ang dapat naming bigyang pansin. Kinakailangang tingnan ang bawat pagsusuri ng code bilang bahagi ng pag-aaral, isang bagay na makakatulong sa iyong pagbutihin. Kapag nag-iwan ng komento ang isang tao sa iyong code, ibinabahagi niya sa iyo ang kanyang karanasan, ang kanyang pinakamahuhusay na kagawian. Para sa akin, hindi ka maaaring maging isang mahusay na programmer nang hindi nakakakuha ng pagsusuri sa code. Dahil hindi mo alam kung gaano kahusay ang iyong code at kung mayroong anumang mga pagkakamali doon mula sa punto ng view ng isang may karanasan na tao mula sa labas.

8. Pagkahilig sa abstruse solusyon

Kadalasan ang iba't ibang gawain/problema ay maaaring magkaroon ng iba't ibang solusyon. At sa lahat ng magagamit na mga solusyon, ang mga nagsisimula ay karaniwang gumagamit ng mga pinaka kumplikado at "abstruse". At totoo ito: kung ang isang baguhan na programmer kahapon ay nag-aral ng maraming iba't ibang mga algorithm, pattern, istruktura ng data, kung gayon ang kanyang mga kamay ay nangangati na ipatupad ang isa sa mga ito. Oo, at gusto kong sabihin, ipahayag ang aking sarili. Believe me, I was like that myself and I know what I’m talking about :) Nagkaroon ako ng sitwasyon kung saan matagal akong nagsusulat ng isang functionality na naging very, very complex. Pagkatapos ay muling isinulat ito ng isang developer sa antas ng Senior+. Siyempre, interesado akong makita kung ano at paano niya ito binago. Tiningnan ko ang kanyang pagpapatupad at namangha ako sa kung gaano ito naging simple. At ang code ay naging tatlong beses na mas kaunti. At sa parehong oras, ang mga pagsubok para sa pag-andar na ito ay hindi nagbago at hindi nabigo! Iyon ay, ang pangkalahatang lohika ay nananatiling pareho. Mula dito ay dumating ako sa konklusyon na: ang pinaka-mapanlikha na mga solusyon ay palaging simple . Pagkatapos ng pagsasakatuparan na ito, ang pagsulat ng code ay naging mas madali, at ito ay naging kapansin-pansing mas mataas na antas. Kung gayon, kailan sulit ang paggamit ng mga pattern at algorithm, itatanong mo? Pagkatapos, kapag ginagamit ang mga ito ay ang pinakasimpleng at pinaka-compact na paraan.

9. Ang pag-imbento ng mga bisikleta

Ang konseptong ito ay kilala rin bilang ang pag-imbento ng gulong. Ang kakanyahan nito ay nakasalalay sa katotohanan na ang developer ay nagpapatupad ng kanyang sariling solusyon sa isang problema kung saan mayroon nang mga solusyon, at maraming beses na mas mahusay kaysa sa mga naimbento ng programmer. Bilang isang patakaran, ang pag-imbento ng iyong sariling bisikleta ay hahantong sa pagkawala ng oras at pagbaba sa kahusayan ng trabaho ng developer, dahil ang isang solusyon ay maaaring hindi matagpuan na malayo sa pinakamahusay, o maaaring hindi matagpuan. Kasabay nito, hindi natin maaaring itapon ang posibilidad ng isang malayang desisyon. Ang programmer ay dapat na mag-navigate nang tama sa mga gawain na maaaring lumitaw sa harap niya upang malutas ang mga ito nang may kakayahan at sa isang napapanahong paraan, gamit ang mga handa na solusyon o pag-imbento ng kanyang sarili. Sa isang banda, sa mga unibersidad at sa mga kurso ay binubugbog tayo ng iba't ibang uri ng mga gawain na dapat tumulong sa atin sa paggawa ng mga bisikleta. Ngunit ito ay sa unang tingin lamang. Sa katunayan, ang layunin nito ay upang bumuo ng algorithmic na pag-iisip at isang mas malalim na kasanayan sa syntax ng wika. At ang mga naturang gawain ay nakakatulong din upang mas maunawaan ang mga algorithm/istruktura, at, kung kinakailangan, bigyan sila ng mga kasanayan upang ipatupad ang kanilang mga advanced na analogues (ngunit ito ay napakabihirang kinakailangan). Sa totoong buhay, sa karamihan ng mga kaso, hindi na kailangang mag-imbento ng iyong sariling gulong, dahil ang mga analogue ay matagal nang umiral na nakakatugon sa ating mga pangangailangan. Marahil, dahil sa iyong karanasan, hindi mo malalaman ang tungkol sa pagkakaroon ng mga pagpapatupad ng ito o ang pag-andar na kailangan mo. Dito kailangan mong gamitin ang unang punto ng artikulong ito, ibig sabihin, humingi ng tulong mula sa mas may karanasan na mga kasamahan. Magagawa nilang gabayan ka (halimbawa, payuhan kung saang direksyon papunta sa Google) o magmungkahi ng partikular na pagpapatupad (ilang library).

10. Huwag sumulat ng mga pagsusulit

Hindi gusto ng lahat ng mga nagsisimula ang mga pagsusulit sa pagsulat. Paano naman ang mga baguhan: hindi rin mahilig ang mga hindi baguhan sa pagsulat ng mga pagsusulit, ngunit mas nauunawaan nila kung bakit ito kailangan. Kapag ikaw ay ganap na berde, iniisip mo: bakit isulat ang mga ito? Gumagana ang lahat, at walang mga pagkakamali. Ngunit paano ka makatitiyak na ang iyong mga pagbabago ay hindi nakakasira ng isang bagay sa ibang bahagi ng system? Hindi ito maa-appreciate ng iyong mga kasamahan kung pipilitin mo ang mga pagbabagong mas nakakagambala kaysa sa kanilang nakikinabang. Ito ay kung saan dumating ang mga pagsubok upang iligtas. Ang mas maraming aplikasyon ay sakop ng mga pagsubok, mas mabuti (tinatawag din na porsyento ng saklaw). Kung ang application ay mahusay na sakop ng mga pagsubok, sa pamamagitan ng pagpapatakbo ng lahat ng ito maaari kang makahanap ng mga lugar na maaaring sirain ng iyong mga pagbabago. At tulad ng sinabi ko sa halimbawa sa itaas, kapag refactoring ang pag-andar, ang mga pagsubok ay hindi nabigo, at lahat dahil ang pangkalahatang lohika ay hindi nagbago. Nangangahulugan ito na maaari ding ipakita ng mga pagsubok kung nagbago o hindi ang lohika ng isang partikular na functionality. Kaya kahit na hindi mo gusto ang pagsusulat ng mga pagsusulit, may mga walang alinlangan na benepisyo mula sa mga ito, at sulit ang mga ito sa oras na ginugol sa kanila.

11. Labis na pagkokomento

Maraming mga developer ang nagdurusa sa pagiging perpekto, at ang mga nagsisimula ay walang pagbubukod. Ngunit kung minsan ang isang side effect ng pagnanais na ito ay nagsimula silang magkomento sa lahat at lahat. Kahit na hindi kailangan, dahil ito ay napakalinaw:

Cat cat = new Cat(); // cat Object

Hindi lahat ng mga baguhang programmer ay agad na napagtanto na ang pagkomento ng code ay hindi palaging isang magandang bagay, dahil ang code ay magiging mas kalat at mahirap basahin. Paano kung binago ang code, ngunit walang komento para dito? Liligawan niya pala tayo at guguluhin lang tayo. Bakit ganoon ang komento? Karaniwan, ang mahusay na pagkakasulat na code ay hindi nangangailangan ng pagkomento , dahil lahat ng nasa loob nito ay halata at nababasa na. Kung sumulat ka ng komento, nangangahulugan ito na nasira mo na ang pagiging madaling mabasa ng code at sinusubukan mong pahusayin ang sitwasyon. Ang pinakamahusay na diskarte ay ang unang magsulat ng nababasa na code na hindi kailangang dagdagan ng mga komento. Hindi ko rin maiwasang banggitin ang tamang pagpapangalan ng mga pamamaraan, variable at klase, ibig sabihin, isang panuntunan na ako mismo ay sumusunod: Ang pinakamagandang komento ay ang kawalan ng komento, at sa halip - ang tamang pagpapangalan na malinaw na naglalarawan dito o iyon functionality sa iyong application.

12. Masamang pagpapangalan

Kadalasan, pinapalsipika ng mga nagsisimula ang mga pangalan ng mga klase, variable, pamamaraan, atbp. Halimbawa, kapag gumawa sila ng klase na ang pangalan ay hindi naglalarawan ng layunin nito. O ang isang variable ay nilikha gamit ang isang maikling pangalan, isang bagay tulad ng x , at kapag ang dalawa pang variable na pinangalanang n at y ay nilikha , ito ay nagiging napakahirap na matandaan kung ano ang x . Sa ganitong mga kaso, kailangan mong maingat na pag-isipan ang tungkol sa code at pag-aralan ang functionality na ito sa ilalim ng mikroskopyo (marahil gamit ang isang debugger) upang maunawaan lamang kung ano ang nangyayari doon. Dito nakakatulong ang tamang pagpapangalan sa code na nabanggit ko sa itaas. Ang mga tamang pangalan ay nagpapabuti sa pagiging madaling mabasa ng code, nang naaayon sa pag-save ng oras sa familiarization, dahil mas madaling gumamit ng isang paraan kung saan ang pangalan ay humigit-kumulang na naglalarawan sa pag-andar nito. Sa code, ang lahat ay binubuo ng mga pangalan (mga variable, pamamaraan, klase, file object, atbp.), Ang puntong ito ay nagiging napakahalaga kapag lumilikha ng tama, malinis na code. Ito ay nagkakahalaga ng pag-alala na ang pangalan ay dapat maghatid ng kahulugan: bakit, halimbawa, ang variable ay umiiral, kung ano ang ginagawa nito at kung paano ito ginagamit. At muli kong papansinin na ang pinakamahusay na komento para sa paglalarawan ng isang variable ay ang tamang pangalan nito. Para sa isang mas malalim na pag-aaral ng mga komento at tamang pagpapangalan, ipinapayo ko sa iyo na basahin ang walang hanggang klasiko: "Malinis na code. Paglikha, pagsusuri at refactoring", Robert Martin . Sa talang ito, ang unang bahagi ng artikulong ito (mga pagninilay) ay natapos na. Itutuloy…