Ang paggawa ng iyong code na malinis at maganda ay isang mahusay na paraan upang matugunan ang mga deadline. Si Robert Martin ay natamaan sa ulo ng isa sa kanyang mapanlinlang na mga pahayag: "Ang tanging tunay na sukatan ng kalidad ng code ay ang What-The-F**ks/Minute unit ." " sa orihinal). Hayaan akong ipaliwanag kung ano ang ibig sabihin nito. Sa tuwing susuriin ko ang code, dumadaan ang utak ko sa isa sa tatlong emosyon:
“WTF?! Ano ba?!" (na may disgust) - hindi ito... lahat ay napakasama....
“WTF?! Ano ba?!" (na may paghanga) - hmm, isang matalinong tao ang gumawa nito!
“WTF?! Ano ba?!" (na may pagkairita) - kung anong uri ng pagkalito, ano ang pinag-uusapan natin?!
Kaya ano ang pinakamahalaga at ano ang eksaktong sinusuri natin kapag nakakita tayo ng ilang code? Iyon lang: ang kadalisayan at kagandahan nito. Ang kakayahang magsulat ng malinis at magandang code ay isang tagapagpahiwatig ng isang mataas na propesyonal na developer. Ang pagsasanay sa kasanayang ito ay batay sa dalawang bahagi - kaalaman at trabaho. Ang kaalaman ay nagtuturo sa iyo ng mga pattern, prinsipyo, kasanayan, heuristics. Kailangan mo silang lumago nang propesyonal. Ikaw lamang ang dapat sumipsip ng kaalamang ito tulad ng isang espongha sa pamamagitan ng patuloy na pagsasanay at pagsusumikap. Sa madaling salita, hindi madali ang pagsulat ng malinis na code. Ito ay mahirap, maingat na trabaho, at kailangan mong pagsikapan ito. Sa pamamagitan ng trial at error, mapapabuti ka sa pamamagitan ng paulit-ulit na pag-uulit sa parehong mga hakbang hanggang sa mahanap mo ang solusyon na gusto mo. Walang mas simpleng paraan. Nasa ibaba ang ilang tip upang matulungan kang matutunan kung paano magsulat ng malinis na code.
Ano ang nasa isang pangalan
Si Kendrick Lamar (American hip-hop artist - editor's note) ay isang beses tumpak na nabanggit: "Kung sasabihin ko ang totoong kuwento, kailangan kong magsimula sa aking pangalan." Ang mga pangalan sa pagbuo ng software ay nasa lahat ng dako. Pinangalanan namin ang mga function, klase, argumento, package, program—lahat. Pinangalanan namin ang mga source file at reference na libro at lahat ng konektado dito. Pinangalanan namin ang mga bagay nang walang katapusan, at ito ay nagiging isang kritikal na bahagi ng paggawa tungo sa paglikha ng malinis na code. Ang pangalang ibibigay mo sa isang bagay ay dapat magpakita ng layunin. Ang paghahanap ng magandang pangalan ay hindi madali, nangangailangan ng oras, ngunit nakakatipid din ito ng maraming oras kapag kailangan mong harapin ang code at nagiging kumplikado ang sitwasyon. Kaya mag-ingat sa prosesong ito at huwag matakot na baguhin ang mga pangalan sa ibang pagkakataon kung makakita ka ng mas angkop. Ang lahat ng nakikitungo sa iyong code ay lubos na magpapasalamat sa iyo.
Tandaan na ang pangalan ng anumang variable, klase, function ay dapat sumagot sa tatlong pangunahing tanong: kung bakit ito (variable, function, atbp.) ay umiiral, kung ano ang ginagawa nito at kung para saan ito ginagamit.
Nangangailangan ito hindi lamang ng mahusay na mga kasanayan sa paglalarawan, kundi pati na rin ang pangkalahatang karunungan at isang malawak na pananaw. At walang makapagtuturo nito nang mas mahusay kaysa sa iyong sarili.
"Isang function" - isang bagay
Si Louis Henry Sullivan (American rationalist at modernist architect) minsan ay tanyag na nagsabi: "Ang function ay tumutukoy sa anyo . " Sinabi niya ito tungkol sa arkitektura ng mga bahay, ngunit hindi nito binabago ang kakanyahan. Ang bawat system ay binuo sa ilang wikang tukoy sa domain na nilikha ng mga programmer upang tumpak na ilarawan ito. Ang mga function ay kumikilos bilang mga pandiwa ng wika, at ang mga klase ay mga pangngalan. Kadalasan, ang mga function ay pinakamahalaga sa organisasyon ng isang programming language, at ang pagsulat ng mga ito ng tama ay ang kakanyahan ng paglikha ng magandang code. Mayroon lamang dalawang gintong panuntunan para sa pagsusulat ng mga function ng kalidad:
Dapat silang maliit
Dapat nilang gawin ang isang bagay, isang gawain, at gawin ito nang maayos
Ibig sabihin, dapat maliit ang iyong function at hindi dapat maglaman ng mga nested na istruktura. Kaya, ang mga antas ng indentation ng function ay hindi dapat higit sa isa o dalawa. Ang diskarte na ito ay ginagawang mas madaling basahin, maunawaan, at maunawaan ang code. Bilang karagdagan, dapat nating tiyakin na ang mga expression sa loob ng function ay nasa parehong antas ng abstraction. Ang paghahalo ng mga antas ng abstraction sa loob ng isang function ay palaging lumilikha ng maraming kalituhan at kalaunan ay humahantong sa hindi mapamahalaang code. Ang pinakamahusay na mga programmer ay tinatrato ang mga function bilang mga kwento na sasabihin, hindi lamang code na isusulat. Ginagamit nila ang mga tool ng kanilang napiling programming language upang lumikha ng isang mayaman, nagpapahayag, at mas malinis na bloke ng code na maaaring kumilos bilang isang mahusay na mananalaysay.
"Ang mga komento ay hindi bumubuo ng masamang code"
Si Venus Williams, Amerikanong manlalaro ng tennis at limang beses na kampeon sa Wimbledon, ay tumama sa ulo nang sabihin niya: "Lahat ay nag-iiwan ng kanilang mga komento. Ganito lumalabas ang mga tsismis . " Ang mga komento ay parang isang espada na may dalawang talim. Ang isang mahusay na pagkakalagay na komento ay isang napaka-kapaki-pakinabang na bagay. Sa kabilang banda, walang mas nakakagulo sa espasyo kaysa sa mga walang kuwentang komento. Ngunit ang pinakanakapipinsalang komento ay yaong nagkakalat ng maling impormasyon at kasinungalingan. Sa madaling salita, ang mga komento ay isang uri ng kinakailangang kasamaan. Hindi palaging, ngunit para sa karamihan. Bakit? Ito ay simple, mas matanda ang komento, mas mahirap itong panatilihin, at karamihan sa mga programmer, tulad ng alam mo, ay hindi palaging nagbabago ng mga komento kasama ang mga pagbabago sa code. Ang code ay gumagalaw at nagbabago. Ang mga bahagi ng code ay inilipat pabalik-balik, ngunit walang mga komento. At ito ay nagiging problema!
Tandaan: ang malinis, malinaw na code na may kaunting komento ay higit na mas mahusay kaysa sa kumplikado, kalat na code. Huwag sayangin ang iyong enerhiya sa pagpapaliwanag sa kaguluhang ginawa mo sa mga komento. Mas mabuting gugulin ang oras na iyon sa paglilinis ng kalat na iyon.
"Palaging priyoridad ang pag-format ng code"
Ito ay sinabi ng walang iba kundi si Robert C. Martin (Robert Cecil Martin), aka Uncle Bob, developer, may-akda ng maraming libro sa software development, consultant, co-author ng Agile manifesto, at iba pa. At idinagdag niya: "Ang pag-format ng code ay isang uri ng komunikasyon. At ang komunikasyon ay isang pangunahing priyoridad para sa sinumang propesyonal na developer." Ang pahayag sa itaas ay hindi dapat maliitin, dahil ito ay nagsasalita sa isa sa pinakamahalagang katangian ng isang mahusay na developer. Binibigyang-daan ka ng naka-format na code na tingnan nang malalim ang iyong isipan. Nais naming mapabilib ang mga tao sa aming pagiging malinis, pansin sa detalye, kakayahang mag-ayos at maipahayag nang malinaw ang aming mga iniisip. Ngunit kung, kapag tiningnan ng mga tao ang code, nakakita sila ng ilang uri ng pagkalito, na nakapagpapaalaala sa isang vinaigrette, na walang simula o wakas, ito ay nagpapawalang-bisa sa iyong mga pagsisikap at nagpapababa sa reputasyon ng developer. Huwag mo nang pagdudahan! Napakalayo mo sa katotohanan kung sa tingin mo ang pangunahing bagay sa negosyong ito ay ang "gumagana lang ang code." Malamang na mababago ang functionality na gagawin mo ngayon sa susunod na release, ngunit hindi magbabago ang pagiging madaling mabasa ng code. Ang istilo ng code at ang pagiging madaling mabasa nito ay nagpapadali sa pagpapanatili ng code sa mahabang panahon, kahit na matapos ang orihinal na code ay nabago nang hindi na makilala.
Huwag kalimutan na sa hinaharap, ang pinakamalamang na maaalala ay hindi ang iyong code mismo, ngunit ang iyong estilo at pagkakapare-pareho. Samakatuwid, tiyaking maayos ang pagkaka-format ng code at sumusunod sa mga simpleng panuntunan na naiintindihan ng lahat ng miyembro ng team.
Gumawa muna ng block na "try-catch-finally".
Si Georges Canguilhem (mananalaysay ng siyensiya, pilosopo) ay wastong sinabi: “Ang magkamali ay natural sa isang tao, ngunit ang igiit ang mga pagkakamali ay mula sa diyablo . ” Ang pag-troubleshoot ay isang bagay na ginagawa ng lahat ng programmer. Maaaring pumasok ang di-wastong data sa input at maaaring mabigo ang mga device. At bilang mga developer, kailangan nating tiyakin na ginagawa ng code ang dapat nitong gawin. Ang isyu ay hindi lamang paghawak ng error, ngunit "malinis at madaling basahin" na paghawak ng error. Maraming mga programa ang umaangkop sa paghawak ng error. Kung gagawin mo ito, ang lahat ay bumaba sa gayong kaguluhan na ang layunin at lohika ng pangunahing code ay nawasak. Mali ito, hindi dapat ganito. Ang code ay dapat na malinis at maaasahan, at ang paghawak ng error ay dapat na walang putol at natural na hinabi sa code. Isa itong indicator ng isang high-class programmer. At isa sa mga paraan upang makamit ito ay sa pamamagitan ng wastong pagpupugad at pagsakop sa lahat ng mga error sa try-catch blocks. Tinutukoy ng mga bloke na ito ang saklaw ng iyong code. Kapag nag-execute ka ng code sa try portion ng isang try-catch-finally block, sinasabi mo na ang execution ay maaaring i-abort anumang oras at pagkatapos ay ipagpatuloy sa isang catch. Samakatuwid, inirerekomenda naming magsimula sa try-catch-finally kapag sumulat ka ng code. Makakatulong ito na matukoy kung ano ang maaasahan ng user mula sa code, anuman ang mali sa code sa panahon ng pagsubok.
Palaging tandaan na ang bawat pagbubukod na iyong ihahagis ay dapat maglaman ng sapat na konteksto upang matukoy ang lokasyon at pinagmulan ng error. Ang malikhain at nagbibigay-kaalaman na mga mensahe ng error ay naaalala nang matagal pagkatapos maisulat ang code, kahit na ang programmer ay abala na sa ganap na magkakaibang mga gawain.
Isa-isahin natin
Ang isang hindi pangkaraniwang parirala ay makakatulong sa amin na ibuod ang lahat ng nasa itaas. Ito ay code-sense o "isang sense of common code," isang uri ng programmer na katumbas ng common sense. Sa mga salita ni Robert Martin: "Ang pagsulat ng malinis na code ay nangangailangan ng sistematikong paggamit ng maraming maliliit na pamamaraan, na inilapat bilang resulta ng isang maselan at medyo masakit na kahulugan ng "kalinisan." Ang maliliit na pamamaraang ito ay sama-samang tinatawag na code-sense . " Ang ilan sa atin ay may ganitong "sound code sense" sa simula, habang ang iba ay kailangang bumuo nito sa pamamagitan ng patuloy na pagsasanay. Ang instinct na ito ay nakakatulong hindi lamang na makilala ang pagkakaiba sa pagitan ng masama at magandang code, ngunit tumutulong din sa pagbuo ng mga estratehiya na naglalayong gawing mabuti ang masamang code. Ang masamang code ay sumisira sa lahat. Sa matalinghagang pagsasalita, kung pinalamig mo ang pinakamasarap na cake na may tae ng aso, kung gayon... eh... halos walang magugustuhan nito. Tinutulungan ng code sense ang isang programmer na gamitin ang mga tamang tool upang makamit ang kanyang layunin na lumikha ng malinis na code. Ang isang programmer na nakakaunawa kung ano ang code-sense ay isang artist na maaaring lumikha ng isang gawa ng sining sa isang blangkong screen na tatandaan sa loob ng maraming taon. Gaya ng pagbubuod ni Harold “Hal” Abelson, propesor ng computer science sa Mit at founding director ng Creative Commons at ng Free Software Foundation: “Kailangan munang isulat ang mga programa upang mabasa ito ng mga tao, at pagkatapos ay pinaandar.” kotse" . Ano ang mababasa mo sa paksa: "Isang handbook ng Agile Software Craftsmanship" - Robert Martin. "Isang handbook ng Agile estimation" - Mike Cohn Tungkol sa may-akda: Si Ravi Shankar Rajan ay isang Global IT Program Manager mula sa Mumbai (India). Sikat na blogger, haiku poet, avid archaeology at history buff. Maaari kang kumonekta sa kanya sa Twitter , Medium , LinkedIn
GO TO FULL VERSION