Pagsusuri ng mga karaniwang pagkakamali na ginawa ng mga baguhang programmer, pt. 1

Hello, mundo! Kapag natutunan mo na ang lahat ng kailangan mong malaman at sa wakas ay makapagtrabaho ka na bilang intern o junior dev, malamang na makakapag-relax ka na, di ba? Hindi. Nagsisimula pa lang ang lahat para sa iyo... Napapalibutan ka ng maraming bago at hindi maintindihan. Paano mo hindi ito sirain kaagad sa labas ng gate? Iyan ang pag-uusapan natin ngayon. Sa artikulong ito, gusto kong suriin ang mga karaniwang pagkakamali ng rookie at magbigay ng ilang payo, batay sa sarili kong karanasan, tungkol sa kung paano maiiwasan ang mga ito. Kaya, magsimula tayo nang walang karagdagang ado:

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

Tayong lahat ay tao. Lahat tayo ay natatakot na magmukhang tanga, lalo na sa mga mata ng ating mga bago, mas makaranasang kasamahan. Kapag ang mga developer ay kumuha ng kanilang unang trabaho, sila ay madalas na ginagabayan ng takot na ito at, sa isang malakas na narinig, umatras sa kanilang sarili, sinusubukang malaman ang lahat sa kanilang sarili. Bukod pa rito, ang isang tao ay maaaring mapalibutan ng mas maraming karanasan na mga kasamahan, na, sa turn, ay maaaring ituro sa kanya sa pinaka-maaasahan na direksyon, na tumutulong upang maiwasan ang higit pang mga pagkakamali at hindi kinakailangang "mga bumps sa ulo". Kaya tandaan: huwag matakot magtanong. Ikaw ay isang baguhan at lubos na nauunawaan ito ng lahat. Kapag nagtanong ka, walang papalo sa iyo ng stick. Marahil kahit na ang kabaligtaran ay mangyayari: mas mabilis kang magiging kaibigan ng iyong mga kasamahan at magsisimulang masiyahan sa mas aktibong pakikipag-usap sa kanila. ako Marami pa akong sasabihin: kapag mas nagtatanong at tumatalakay ka sa iba't ibang teknikal na isyu, mas mabilis mong mapupuksa ang iyong berdeng balat at magiging eksperto sa iyong larangan. At isa pang payo. Huwag maging estranghero saStackOverflow . Partikular kong pinag-uusapan ang tungkol sa pagtatanong sa mapagkukunang ito. Sa isang banda, nangangailangan ng ilang oras upang makakuha ng sagot sa iyong tanong. Ngunit sa kabilang banda, maaari kang mabilis na matuto ng maraming mga diskarte sa paglutas ng iyong problema at tingnan ito mula sa isang bahagyang naiibang anggulo. Gusto ko ring tandaan na may mga praktikal na benepisyo sa pagsusulat ng komento/sagot at pagsusulat ng mga paglilinaw ng mga tanong sa mga tanong sa StackOverflow mula sa iba pang mga developer: magkakaroon ka ng pagkakataong makipagdebate at pag-aralan nang mas malalim ang mga isyu, hindi pa banggitin ang pagpapalakas ng karma.

2. Hindi sinusubukang maghanap ng impormasyon sa iyong sarili

Ang pagkakamaling ito ay maaaring ituring na flipside ng nauna.Narito ang ibig kong sabihin kapag sinimulan mong guluhin ang iyong mga kasamahan at kakilala tungkol sa bawat problema o sinok na iyong nararanasan. Ang pagtatanong ay mabuti, ngunit huwag mag-overboard sa mga tanong. Kung hindi man, maaaring makita ka lamang ng mga tao na nakakainis. Kung nalilito ka tungkol sa isang bagay, ang unang bagay na dapat gawin ay gamitin ang iyong mga kasanayan sa paghahanap sa pinakamahusay na search engine — Google. May ibang taong nakatagpo na ng napakaraming hindi maintindihan na mga pagkakamali at iba pang mga isyu. At lubos kang magugulat kung i-google mo ang iyong tanong at makita ang bilang ng mga tao na pamilyar sa isang katulad na problema, at nakatanggap na ng mga kumpletong sagot na maaari mong ilapat sa iyong sariling trabaho. Kaya naman madalas mong maririnig na tumugon ang iyong mga kasamahan gamit ang "Google it". huwag huwag kang masaktan sa sagot na ito — ang iyong kasamahan ay hindi ang iyong personal na guro na dapat maghatid ng lahat ng mga subtleties ng iyong larangan ng trabaho. Ang walang katapusang expanses ng Internet ang iyong magiging mentor. Minsan ang mga programmer ay tinutukoy din bilangmga taong may black belt sa paghahanap sa Google . Kaya kung tayo ay may "sinok", i-google muna natin ang problema. Kung ang isang solusyon ay hindi mahanap (ito ay bihira, ngunit ito ay nangyayari), pagkatapos lamang namin magsisimulang magtanong sa mga kasamahan. Ang mga agarang tanong ay para sa pagkuha ng payo tungkol sa kung aling diskarte ang dapat mong piliin upang malutas ang isang problema nang higit sa kung ano ang gagawin mo kapag natamaan mo ang isang speed bump o isang hindi maintindihan na mensahe ng error. Pagkatapos ng lahat, maaari nilang makita ang higit sa iyong ginustong diskarte at agad na mahulaan kung saan hahantong ang anumang ibinigay na diskarte sa katagalan.

3. Blindly copying and paste

Ngunit ang mga problema sa pag-googling at ang kanilang mga solusyon ay may mga pitfalls nito. Halimbawa, bulag na pagkopya at pag-paste .Karaniwan itong nangyayari kapag nakakita ka ng katulad na problema (ngunit marahil ay hindi eksaktong pareho) at isang nauugnay na solusyon, halimbawa, sa StackOverflow. Kunin mo ang solusyon na ito at kopyahin-at-i-paste ito nang hindi na pinag-aaralan pa ang mga detalye. At pagkatapos ay matuklasan mo o ng iyong mga katrabaho ang ilang kakaibang bug o maling pag-uugali sa iyong code. At walang makahuhula agad kung saan sila nanggaling. Sa kalaunan, siyempre, ang lugar na may kinopyang code ay matatagpuan, at tiyak na hindi ka pupurihin para sa iyong solusyon. Samakatuwid, kapag nakakita ka ng isang handa na solusyon sa StackOverflow (o saanman), kailangan mo munang lubusang maunawaan ang kung ano, paano, at bakit. Marahil ay i-google ang nauugnay na pag-andar at basahin ang dokumentasyon para dito. At pagkatapos mo lang gawin iyon dapat mo itong idagdag sa iyong proyekto.

4. Nananatili sa maling solusyon

Kapag nagsusulat ng isang solusyon, kung minsan ay makikita mo na ito ay patuloy na nagiging mas kumplikado, sa kalaunan ay dumarating sa isang dead end. At pagkatapos ay subukan mong gawing mas detalyado ang solusyon upang kahit papaano ay gumana ito sa halip na maghanap ng isa pa, mas angkop na alternatibo. Marahil ay naramdaman mong nag-invest ka ng maraming oras at pagsisikap at samakatuwid ay nagpasya na, anuman ang mangyari, hindi ka susuko at malulutas mo ang problema sa iyong umiiral na diskarte. Hindi ito ang tamang saloobin. At least sa programming. Kung mas maaga kang sumubok ng ibang diskarte, mas maraming oras ang matitipid mo sa huli. Kaya huwag matakot na mag-eksperimento at subukan ang iba pang mga diskarte, anuman ang dami ng oras na iyong namuhunan sa iyong kasalukuyang diskarte. Higit pa rito, sa pamamagitan ng pagsubok ng maraming diskarte at pagsisid nang mas malalim sa paksa,

5. Takot na magtanong tungkol sa iyong kasalukuyang takdang-aralin

Ang pagtatrabaho sa isang software development project ay kadalasang nauuwi sa pagsasagawa ng mga partikular na gawain. Halimbawa, sa Jira. Ang mga gawaing ito ay hindi palaging nakabalangkas nang malinaw at detalyado. Ang mga paglalarawan ng gawain ay karaniwang isinulat ng mga pinuno ng pangkat, na mga mortal lang din. Maaaring makalimutan nilang magdagdag ng isang bagay o mabigo sa pagsasaalang-alang sa katotohanang hindi ka pamilyar sa ito o sa pagpapagana na iyon. O marahil ay wala kang anumang access sa proyekto (halimbawa, access sa database, ang log server, at iba pa). At ngayon, natanggap mo na ang gawain, pinag-aralan ito nang higit sa ilang oras, ngunit nakaupo ka pa rin doon, nakatitig sa screen nang may pagkataranta. Sa halip na patuloy na hindi matagumpay na subukang maunawaan ito, dapat kang magsimulang humingi ng paglilinaw o patnubay mula sa sinumang lumikha ng gawain. Halimbawa, sa app na ginagamit ng iyong team para sa komunikasyon (halimbawa, Microsoft Teams), maaari kang magtanong o gumawa ng direktang komento tungkol sa gawain. Sa isang banda, kung isusulat mo ang iyong tanong sa isang personal na mensahe, malamang na mas mabilis kang makakuha ng sagot, dahil makikita kaagad ng tao ang iyong tanong. Sa kabilang banda, sa pamamagitan ng pagtatanong sa Jira, nagtatatag ka ng patunay na may ginagawa ka, ibig sabihin, pagsusuri sa problema. Mayroong isang paraan upang mapabilis ang prosesong ito: tanungin ang iyong tanong sa isang komento sa Jira at pagkatapos ay sa isang DM, mag-drop ng link sa iyong komento at hilingin na tingnan.

6. Paglalagay ng hindi makatotohanang mataas na mga inaasahan sa pinuno ng koponan

Muli, ito ang pitik na bahagi ng nakaraang punto. Ang pinuno ng koponan ay ang pinuno ng isang pangkat ng pag-unlad. Bilang isang tuntunin, ginugugol ng pinuno ng iyong koponan ang karamihan sa kanyang oras sa iba't ibang uri ng komunikasyon. Gayunpaman, nagsusulat din siya ng code upang hindi makalimutan ang lahat tungkol sa programming. Tulad ng naiintindihan mo, ang buhay ng isang pinuno ng koponan ay abala. Ang paghila sa manggas ng iyong team lead sa tuwing kailangan mong bumahing ay halatang hindi kasiya-siya. Isipin na ang bawat miyembro ng pangkat ay nagbobomba sa pangunguna ng isang grupo ng mga katanungan. Mababaliw iyon sa sinuman, tama ba? At kung magtatambak ka ng maraming tanong, ang iyong pinuno ng koponan ay kailangang gumugol ng maraming oras sa pagsagot sa iyo. Ano ang maaaring gawin upang bawasan ang bilang ng mga tanong na nakadirekta sa pinuno ng pangkat:

• I-explore ang dokumentasyon ng proyekto nang mas malalim para mabawasan ang bilang ng mga blind spot.
• Idirekta ang iyong mga tanong sa iyong iba pang miyembro ng koponan. Maaaring pamilyar sila sa functionality na ito gaya ng lead, o posibleng higit pa, dahil ang functionality ay malamang na isinulat ng isa sa kanila.

Bilang kahalili, maaari mong tingnan ang mga anotasyon sa IDE kung sino at kailan huling binago ang code sa isang partikular na linya. Ganyan mismo kung paano mo malalaman kung sino ang pinakaangkop na tao para itanong ang iyong tanong. Tulad ng malamang na napagtanto mo na, pagdating sa mga tanong sa pinuno ng koponan, tulad ng sa mga tanong sa mga kasamahan, kailangan mong subukang humanap ng masayang medium — huwag matakot na magtanong, ngunit huwag din magtanong ng masyadong marami sa kanila.

7. Takot sa mga pagsusuri sa code

Isang pagsusuri ng codeay isang yugto na nangyayari bago mo isumite ang iyong code sa isang karaniwang aplikasyon (sa isang nakabahaging sangay, halimbawa, master o dev). Ang pagsusuring ito ay isinasagawa ng isang developer na hindi kasali sa gawain, na ang mga sariwang mata ay makaka-detect ng mga error, kamalian, o mga depekto sa iyong istilo ng code na hindi napansin noong una mong isinulat ang iyong code. Kung may mga kritisismo, iniiwan ang mga ito bilang mga komento sa ilang bahagi ng code. Sa kasong ito, dapat itama ng developer na sumulat ng code ang mga error na natukoy sa pagsusuri (o talakayin ang kanyang mga desisyon sa reviewer, posibleng kumbinsihin siya na tama ang mga ito). Pagkatapos ay isinumite ang code para sa pagsusuri nang paulit-ulit hanggang sa wala nang komento ang tagasuri. Nagsisilbing "gateway" ang reviewer bago isagawa ang code. Ang hamon ay ang tingin ng maraming baguhang programmer sa pagsusuri ng code bilang pagpuna at pagkondena. Hindi nila pinahahalagahan ang mga review ng code at natatakot sa kanila. Hindi sila dapat. Ang mga pagsusuri sa code ay eksakto kung ano ang nagbibigay-daan sa amin na 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 bigyang pansin. Dapat mong isaalang-alang ang bawat pagsusuri ng code bilang bahagi ng curve ng pagkatuto, isang bagay na makakatulong sa iyong maging mas mahusay. Kapag may nagkomento sa iyong code, nagbabahagi siya ng karanasan at pinakamahuhusay na kagawian sa iyo. Ako mismo ay hindi naniniwala na maaari kang maging isang mahusay na programmer nang hindi nakakakuha ng mga pagsusuri sa code. Dahil hindi mo alam ang kalidad ng iyong code at kung ang isang may karanasan na tagalabas ay magtuturo ng mga pagkakamali. t pinahahalagahan ang mga review ng code at natatakot sa kanila. Hindi sila dapat. Ang mga pagsusuri sa code ay eksakto kung ano ang nagbibigay-daan sa amin na 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 bigyang pansin. Dapat mong isaalang-alang ang bawat pagsusuri ng code bilang bahagi ng curve ng pagkatuto, isang bagay na makakatulong sa iyong maging mas mahusay. Kapag may nagkomento sa iyong code, nagbabahagi siya ng karanasan at pinakamahuhusay na kagawian sa iyo. Ako mismo ay hindi naniniwala na maaari kang maging isang mahusay na programmer nang hindi nakakakuha ng mga pagsusuri sa code. Dahil hindi mo alam ang kalidad ng iyong code at kung ang isang may karanasan na tagalabas ay magtuturo ng mga pagkakamali. t pinahahalagahan ang mga review ng code at natatakot sa kanila. Hindi sila dapat. Ang mga pagsusuri sa code ay eksakto kung ano ang nagbibigay-daan sa amin na 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 bigyang pansin. Dapat mong isaalang-alang ang bawat pagsusuri ng code bilang bahagi ng curve ng pagkatuto, isang bagay na makakatulong sa iyong maging mas mahusay. Kapag may nagkomento sa iyong code, nagbabahagi siya ng karanasan at pinakamahuhusay na kagawian sa iyo. Ako mismo ay hindi naniniwala na maaari kang maging isang mahusay na programmer nang hindi nakakakuha ng mga pagsusuri sa code. Dahil hindi mo alam ang kalidad ng iyong code at kung ang isang may karanasan na tagalabas ay magtuturo ng mga pagkakamali. gumagawa ng mali at kung ano ang nararapat na bigyang pansin. Dapat mong isaalang-alang ang bawat pagsusuri ng code bilang bahagi ng curve ng pagkatuto, isang bagay na makakatulong sa iyong maging mas mahusay. Kapag may nagkomento sa iyong code, nagbabahagi siya ng karanasan at pinakamahuhusay na kagawian sa iyo. Ako mismo ay hindi naniniwala na maaari kang maging isang mahusay na programmer nang hindi nakakakuha ng mga pagsusuri sa code. Dahil hindi mo alam ang kalidad ng iyong code at kung ang isang may karanasan na tagalabas ay magtuturo ng mga pagkakamali. gumagawa ng mali at kung ano ang nararapat na bigyang pansin. Dapat mong isaalang-alang ang bawat pagsusuri ng code bilang bahagi ng curve ng pagkatuto, isang bagay na makakatulong sa iyong maging mas mahusay. Kapag may nagkomento sa iyong code, nagbabahagi siya ng karanasan at pinakamahuhusay na kagawian sa iyo. Ako mismo ay hindi naniniwala na maaari kang maging isang mahusay na programmer nang hindi nakakakuha ng mga pagsusuri sa code. Dahil hindi mo alam ang kalidad ng iyong code at kung ang isang may karanasan na tagalabas ay magtuturo ng mga pagkakamali.

8. Pagkahilig para sa mga arcane na desisyon

Ang iba't ibang gawain/problema ay kadalasang may iba't ibang solusyon. At sa lahat ng magagamit na mga solusyon, ang mga nagsisimula ay madalas na gumamit ng mga pinaka-kumplikado at arcane. At iyon ay makatuwiran: ang mga baguhang programmer kahapon ay natuto ng maraming iba't ibang mga algorithm, pattern, at istruktura ng data, kaya nangangati ang kanilang mga kamay na ipatupad ang ilan sa mga ito. Trust me, ganyan ako, kaya alam ko kung ano ang pinag-uusapan ko :) Nagkaroon ako ng sitwasyon kung saan matagal akong nagpapatupad ng functionality. Ito ay naging napaka-komplikado. Pagkatapos ay muling isinulat ng senior developer ang aking code. Siyempre, sobrang interesado akong makita kung ano at paano niya ito binago. Tiningnan ko ang kanyang pagpapatupad at namangha ako sa kung gaano ito kasimple. At mayroong tatlong beses na mas kaunting code. At nakakagulat din, ang mga automated na pagsubok para sa functionality na ito ay hindi inalis o binago! Sa madaling salita, ang pangkalahatang lohika ay nanatiling pareho. Mula dito, nakarating ako sa konklusyon naang pinaka mapanlikhang solusyon ay laging simple . Pagkatapos ng pagsasakatuparan na ito, naging mas madali ang coding, at ang kalidad ng aking code ay tumalon sa mas mataas na antas. At kailan sulit na mag-aplay ng mga pattern ng disenyo at magarbong algorithm, itatanong mo? Kapag nag-aaplay ang mga ito ay ang pinakasimpleng at pinaka-compact na solusyon.

9. Muling pag-imbento ng gulong

Ang gulong ay isang matibay na solusyon na naimbento nang matagal na ang nakalipas. Sa anti-pattern na ito, ipinapatupad ng developer ang kanyang sariling pagmamay-ari na solusyon para sa isang problemang nalutas na. Minsan ang mga umiiral na solusyon na ito ay mas mahusay kaysa sa naisip ng programmer. Bilang isang patakaran, ang muling pag-imbento ng gulong ay hahantong sa nawawalang oras at pagbaba ng produktibidad, dahil ang solusyon na makikita mo ay maaaring malayo sa pinakamahusay, o, mabuti, maaaring wala ka talagang mahanap. Iyon ay sinabi, hindi namin maaaring alisin ang posibilidad ng paglikha ng aming sariling independiyenteng solusyon: kung ginawa namin, pagkatapos ang lahat ng natitira ay copy-and-paste programming. Ang programmer ay dapat na magabayan nang maayos ng mga partikular na gawain sa programming na lumitaw upang malutas ang mga ito nang mahusay at kaagad, sa pamamagitan man ng paggamit ng mga handa na solusyon o sa pamamagitan ng paglikha ng mga custom na solusyon. Sa isang kamay, sa mga unibersidad at sa mga online na kurso, binomba tayo ng iba't ibang uri ng mga gawain na tila idinisenyo upang tulungan tayong muling likhain ang mga gulong. Ngunit sa unang sulyap lamang: Ang tunay na layunin dito ay bumuo ng algorithmic na pag-iisip at isang mas malalim na kasanayan sa syntax ng wika. Ang ganitong mga gawain ay nakakatulong din sa iyo na mas maunawaan ang mga algorithm at istruktura ng data, at nagbibigay sa iyo ng mga kasanayan upang ipatupad ang mas sopistikadong mga katapat, kung kinakailangan (ito ay kung minsan ay kinakailangan, ngunit ito ay napakabihirang). Sa totoong buhay, hindi mo kailangang mag-imbento ng sarili mong gulong sa napakaraming kaso, dahil ang mga gulong na nakakatugon sa iyong mga pangangailangan ay matagal nang umiiral. Marahil ang iyong kawalan ng karanasan ay humahadlang sa iyo na malaman ang tungkol sa pagkakaroon ng mga pagpapatupad ng pag-andar na kailangan mo. Dito kailangan mong kunin ang payo na ibinigay sa unang punto ng artikulong ito, ibig sabihin, humingi ng tulong sa mas maraming karanasang kasamahan. Magagawa nilang gabayan ka (halimbawa, ituro ka sa tamang direksyon sa iyong paghahanap sa Google) o magmungkahi ng isang partikular na pagpapatupad (halimbawa, ilang library).

10. Pagkabigong sumulat ng mga pagsusulit

Lahat ng mga baguhan ay ayaw sa mga pagsusulit sa pagsulat. Ngunit bakit dapat nating iisa ang mga baguhan, dito? Hindi rin gustong magsulat ng mga pagsubok ang mas maraming batikang developer, ngunit mas naiintindihan nila kung bakit kailangan ang mga pagsubok. Kapag ikaw ay ganap na berde, nagtataka ka kung bakit dapat mong isulat ang mga ito. Gumagana ang lahat, kaya hindi maaaring magkamali. Ngunit paano mo matitiyak na hindi masisira ng iyong mga pagbabago ang isang bagay sa ibang lugar sa system? Hindi ito mapapahalagahan ng iyong mga kasamahan kung magsusulong ka ng mga pagbabagong nagdudulot ng higit na pinsala kaysa sa kabutihan. Dito dumarating ang mga pagsubok para iligtas tayo. Kung mas nasasaklaw ng mga pagsubok ang code ng application, mas mabuti (ito ay tinatawag na saklaw ng code o saklaw ng pagsubok). Kung ang application ay may mahusay na saklaw ng pagsubok, maaari mong patakbuhin ang lahat ng mga pagsubok upang makahanap ng mga lugar na masisira ng iyong code. At gaya ng sinabi ko sa halimbawa sa itaas, nang i-refactor ng senior developer ang code, hindi nabigo ang mga pagsubok. Ito ay dahil ang pangkalahatang lohika ay hindi nagbago. Gumagamit kami ng mga pagsubok upang ipakita kung nagbago o hindi ang lohika ng ilang functionality. Kaya kahit na hindi mo gusto ang pagsulat ng mga pagsusulit, tiyak na kapaki-pakinabang ang mga ito at sulit ang oras na ginugol sa mga ito.

11. Labis na komento

Maraming mga developer ang nagdurusa sa pagiging perpekto, at ang mga newbie ay walang pagbubukod. Minsan ay nagpapakita lamang sila ng isang bahagi ng hilig na ito kapag nagsimula silang magkomento sa lahat at sa lahat ng bagay. Kahit na ang paggawa ng mga komento na hindi kailangan, dahil ang code 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 mabuti, dahil ang labis na mga komento ay nakakalat sa code at nagpapahirap sa pagbasa. At paano kung magbago ang code, ngunit hindi na-update ang mga lumang komento? Tapos ililigaw at lituhin lang nila tayo. Kung gayon bakit gumawa ng ganoong komento sa lahat? Karaniwan, ang mahusay na pagkakasulat na code ay hindi kailangang magkomento , dahil ang lahat ng nasa loob nito ay halata at nababasa na. Kung kailangan mong magsulat ng komento, nasira mo na ang pagiging madaling mabasa ng code at sinusubukan mong ayusin ang sitwasyon. Ang pinakamahusay na diskarte ay ang pagsulat ng nababasa na code mula sa simula, ibig sabihin, ang code na hindi nangangailangan ng mga komento. Hindi ko rin maiwasang banggitin ang pangangailangang sundin ang tamang mga kombensiyon sa pagbibigay ng pangalan para sa mga pamamaraan, variable, at klase. Narito ang aking panuntunan: Ang pinakamahusay na komento ay alinman sa walang komento o tamang pagpapangalan na malinaw na naglalarawan sa paggana sa iyong aplikasyon.

12. Masamang pagpapangalan

Ang mga baguhan ay mabilis at maluwag na naglalaro sa kanilang pagbibigay ng pangalan ng mga klase, variable, pamamaraan, atbp. Halimbawa, sa pamamagitan ng paglikha ng isang klase na ang pangalan ay hindi naglalarawan sa layunin nito. O nagdedeklara sila ng variable na may maikling pangalan, tulad ng x . Sila kapag dalawa pang variable na pinangalanang n at yay nilikha, ang pag-alala kung ano ang responsable para sa x ay nagiging napakahirap. Sa sitwasyong ito, kailangan mong pag-isipang mabuti ang code, pag-aralan ito sa ilalim ng isang mikroskopyo (marahil gamit ang isang debugger), pag-aaral ng pag-andar upang maunawaan lamang kung ano ang nangyayari. Ito ay kung saan ang tamang mga kombensiyon sa pagpapangalan na aking nabanggit sa itaas ay tumutulong sa atin. Ang mga tamang pangalan ay nagpapabuti sa pagiging madaling mabasa ng code, kaya binabawasan ang oras na kinakailangan upang maging pamilyar sa code, dahil ang paggamit ng isang paraan ay mas madali kapag ang pangalan nito ay humigit-kumulang na naglalarawan sa paggana nito. Ang lahat ng nasa code ay binubuo ng mga pangalan (mga variable, pamamaraan, klase, bagay, file, atbp.), kaya ang puntong ito ay nagiging napakahalaga kapag gumagawa ng tama at malinis na code. Dapat mong tandaan na ang pangalan ay dapat maghatid ng kahulugan, halimbawa, kung bakit umiiral ang variable, kung ano ang ginagawa nito, at kung paano ito ginagamit. Mapapansin ko nang higit sa isang beses na ang pinakamahusay na komento para sa isang variable ay upang bigyan ito ng isang magandang pangalan. Para sa mas malalim na pag-aaral ng mga komento at tamang pagbibigay ng pangalan, inirerekumenda kong basahin ang walang hanggang mga klasiko:"Clean Code: A Handbook of Agile Software Craftsmanship" ni Robert Martin . Sa tala na iyon, ang unang bahagi ng artikulong ito (aking mga pagmumuni-muni) ay natapos na. Itutuloy...