Coffee break #43. 6 na pagkakamali sa programming na pumipigil sa iyong makuha ang iyong pinapangarap na trabaho. Paano Mag-ambag sa Open Source Software sa Unang pagkakataon

6 na pagkakamali sa programming na pumipigil sa iyong makuha ang iyong pinapangarap na trabaho

Source: Medium Para makahanap ng trabaho bilang programmer, kailangan mong magkaroon ng Git repository. Isa ito sa mga unang titingnan ng mga recruiter. Para magkaroon ng positibong impression ang iyong repository, dapat itong maglaman ng mga proyektong may mga kamakailang pagbabago. Ipakita lamang ang mga proyektong ipinagmamalaki mo, hindi lahat ng linya ng code na naisulat mo na. Ito ang mga pangunahing kaalaman sa pagtatrabaho sa isang repositoryo. Tandaan na maya-maya ay may titingin sa iyong code upang makita kung ikaw ay angkop para sa kumpanya. Ito ay magiging isang mapagpasyang sandali para sa iyo. Pagkaraan ng ilang minuto, magpapasya ang recruiter kung iimbitahan ka para sa isang pakikipanayam. At dito mayroong parehong mabuting balita at masama. Ang masamang balita ay ang isang simpleng pagkakamali ay maaaring makapinsala sa iyong mga pagkakataong makakuha ng trabaho. Ang magandang balita ay karaniwang ayaw ng mga tao na maghukay ng malalim sa code. Kailangan nila ng pangkalahatang pag-unawa sa iyong code at arkitektura. Kaya hindi mo kailangang maging isang henyo - kailangan mo lang maging isang mahusay na programmer. Narito ang ilang karaniwang pagkakamali na ginagawa ng mga baguhan. Iwasan ang mga ito at ang iyong mga pagkakataon sa pakikipanayam ay tataas nang malaki.

Mga lumang komento

Ang mga programmer ay may iba't ibang opinyon tungkol sa mga komento. Ang iba ay nagmamahal sa kanila, ang iba ay napopoot sa kanila. Hindi tayo makakarating sa isang karaniwang konklusyon tungkol sa kung ito ay nagkakahalaga ng pagkomento sa code at sa kung anong mga kaso ito gagawin. Ngunit lahat ay nagkakaisa sa isang bagay: kung mayroon kang mga komento, dapat silang tumugma sa iyong code. Mayroong mga komento upang ipaliwanag ang code. Kapag kumplikado o hindi malinaw ang iyong code, kailangan mo ng tulong para maunawaan ito ng mga mambabasa. Gayundin kailangan mong baguhin ang iyong komento kapag binago mo ang code. Kung hindi mo ito gagawin, hindi na magiging kapaki-pakinabang ang iyong komento. Ang isang masamang komento ay mas masahol pa kaysa sa walang komento. Para lumala pa, ang mga komento ay naka-highlight sa code. Hina-highlight ng mga modernong IDE ang mga komento sa ibang kulay para mas madaling basahin ang mga ito. Sa pamamagitan ng pagdaragdag ng komento, naglalagay ka ng sign na "basahin mo ako" sa code. Sa ganitong paraan, ang anumang pagkakaiba sa pagitan ng komento at ng code ay madaling matukoy. Piliin ang iyong mga komento nang matalino at tandaan na i-update ang mga ito kasama ng iyong code. Sa ganitong paraan, maglilingkod sila sa iyo nang maayos.

Kumbinasyon ng mga aklatan at wika na may parehong mga kaso ng paggamit

Bago ang unang panayam, kailangan kong lutasin ang isang problema sa pangangalap. Isa itong simpleng web app, kaya nagsulat ako ng ilang code, nag-Google ng ilang kumplikadong tanong, at handa na ang app. Sa panahon ng panayam, tinanong ako ng recruiter kung bakit pinaghalo ko ang jQuery code sa simpleng JavaScript sa buong code. Ang sagot ko? “Umm...” Sa totoo lang, nag-paste ako ng ilang code snippet mula sa Stack Overflow. Hindi ko masyadong pinag-isipan. Gumagana ang code, kaya nagpatuloy ako. Ang error na ito ay karaniwan sa mga bagong developer. Kami ay nakatuon sa paglutas ng mga problema sa trabaho na hindi namin binibigyang pansin kung paano namin ito ginagawa. Huwag maging isa sa mga baguhan na nahuhulog sa bitag na ito. Suriin ang bawat linya ng code at tiyaking alam mo kung bakit mo ito inilagay doon.

Pag-uulit ng code

Ang Don't Repeat Yourself (DRY) ay isang programming dogma. Ang paglikha ng mga abstraction para sa paulit-ulit na code ay ang kakanyahan ng programming. Oo, maaaring mahirap sa una. Kapag gusto mong lutasin ang isang problema, gagawin mo ito sa anumang paraan na posible. Pagkatapos ay lumipat ka sa iba pang mga gawain at mananatili sa iyo ang paulit-ulit na code. Maaari mong alisin ang ugali na ito sa pamamagitan ng paglikha ng isang hanay ng mga patakaran para sa iyong sarili. Sa tuwing pinipino mo ang isang feature, basahin muli ang code at tingnan kung mayroon kang magagawa para baguhin ito. Tandaan na ang unang bersyon ng code ay kadalasang mali, at maaari mo itong pagbutihin. Kapag may napansin kang duplicate na code, maglaan ng oras upang pag-aralan ito. Sa ganitong paraan maaari mong malaman ang pinakamahusay na paraan upang muling isulat ito (halimbawa, gamit ang isang loop o paglikha ng isang bagong function). Kung gagawin mo ang paglilinis na ito sa bawat oras, magkakaroon ka ng mas maaasahan at eleganteng code.

Mga error na hindi nahawakan

Halos imposible na lumikha ng anumang makabuluhang application na palaging gagana nang walang kamali-mali. Nagpo-populate ka man ng database o gumagawa ng mga tawag sa API, may mga error na nagaganap. Ang mga hindi nahawakang error ay hindi lamang makakapigil sa mga indibidwal na pag-andar mula sa pagtakbo, ngunit maaaring maging sanhi ng pag-crash ng buong application. Ang pag-asa sa mga posibleng pagkakamali ay tanda ng isang karampatang programmer. Anumang oras na i-access o i-update mo ang anumang panlabas na data, kailangan mong maging handa para sa pinakamasamang sitwasyon. I-flag ang mga potensyal na problema sa paraang hindi ginagawang mahirap gamitin ang application. Papayagan nito ang mga mambabasa ng iyong code (at marahil ikaw) na mabilis na makahanap ng mga error. Ipapakita rin nito sa recruiter na maaari kang magsulat ng cohesive code.

Kakulangan ng pagkakapare-pareho

Ang pagkakapare-pareho ay ang tanda ng kalidad ng software. Ginagawa nitong mas madaling basahin at panatilihin ang code. Ang code na nilikha sa isang pare-parehong istilo ay mas predictable, at mas madaling suriin ang pagganap ng programa. Sa isang mas mataas na antas ng abstraction, ang pagkakapare-pareho ay mahirap makamit. Aabutin ng maraming taon upang makabisado ito, kaya kailangan mong simulan ang pag-aaral ng diskarteng ito nang maaga hangga't maaari. Tandaang gumawa ng mga pamagat gamit lamang ang isang wika. Marahil ito ay Ingles, ngunit sa mga personal na proyekto maaari mong pangalanan ang mga variable at function sa anumang wika hangga't ito ay palaging ang parehong wika. Kung pare-pareho ka, hindi mahalaga kung gumagamit ka ng mga tab o espasyo. Lumikha o pumili ng isang gabay sa istilo at palaging manatili dito. Dapat ka ring gumamit ng tool tulad ng Prettier . Talagang nakakatulong na panatilihing naka-format ang code sa pare-parehong paraan. Anuman ang mga tool at istilo na iyong ginagamit, gamitin ang mga ito nang palagian. Kahit na sumulat ka ng masamang code sa isang pare-parehong istilo, kadalasan ay mas mahusay ito kaysa sa hindi pare-parehong magandang code dahil mas madaling ayusin ito.

Hindi pagkakaunawaan sa mga kasangkapan

Sa isang tipikal na proyekto, malamang na kailangan mong gumamit ng ilang panlabas na library. Maraming programmer ang halos awtomatikong nag-i-install ng mga aklatan dahil ginagamit ang mga ito sa bawat proyekto. Ang mga panlabas na aklatan ay mahusay dahil ang mga ito ay isang napatunayang paraan upang malutas ang mga paulit-ulit na problema. Gayunpaman, madalas na hindi nauunawaan ng mga bagong developer kung aling mga aklatan ang kanilang ginagamit at nagtatapos sa pagdaragdag ng isang library sa itaas ng isa pa o muling pagpapatupad ng ilang umiiral nang functionality. Sa tuwing mag-i-install ka ng library sa iyong proyekto, basahin o tingnan man lang ang dokumentasyon. Suriin ang mga pamamaraan at katangian na magagamit mo at tiyaking nauunawaan mo kung aling mga problema ang dapat lutasin ng library at kung alin ang nangangailangan ng paggamit ng ibang tool. Sa ganitong paraan maaari mong piliin ang mga tamang tool para sa trabaho at ipaliwanag ang iyong mga pagpipilian.

Paano Mag-ambag sa Open Source Software sa Unang pagkakataon

Pinagmulan: Jamestucker.dev Noong isang araw nakakita ako ng tweet mula kay Evan Yu (tagalikha ng Vue.js ) tungkol sa isang bagong repositoryo na ginagawa niya at naging interesado ako. Nagpasya akong gusto kong mag-ambag dito! Ang catch ay hindi pa ako nag-ambag sa mga open source na proyekto bago at hindi alam kung saan magsisimula. Pero hindi naman ganun kahirap diba? Nang makapasok ako sa repository, agad akong natigilan. “What the hell should I do?” sabi ko sa sarili ko. Kung gagawa ako ng PR (pull request, merge request), malamang na punitin ng mga espesyalista ang aking code. Palagi akong makikilala sa mundo ng pag-unlad bilang ang taong hindi alam kung paano magtrabaho nang maayos sa open source. At magtatapos ang aking karera. Sa kabutihang palad, nabasa ko ang isang artikulo (hindi ko matandaan kung saan) pinayuhan ng may-akda na ang iyong unang kontribusyon sa repositoryo ng ibang tao ay dapat na maging maingat hangga't maaari. Ito ay maaaring isang bagay na kasing simple ng pagwawasto ng typo. At kaya ko ginawa. Binasa ko ang dokumentasyon ng repositoryo, nakakita ng ilang typo, nagbukas ng PR, at narito, inaprubahan ni Evan ang aking mga pagbabago. Ako ay opisyal na isang kontribyutor ng Vue! Siguro dapat kong ilagay ito sa aking Twitter bio?

"Iyan ay mahusay, ngunit paano ako magsisimula?"

Okay, magsimula tayo: Ipapakita ko sa iyo ang mga hakbang na maaari mong gawin upang makagawa ng pagbabago.

1. Humanap ng proyekto

Para sa inspirasyon, isipin ang iyong paboritong teknolohiya o tool. Sabihin nating nagtatrabaho ka sa JavaScript at madalas kang gumagamit ng Gatsby ? Tingnan ang kanilang imbakan ! Maaari ka ring mag-ambag sa isa sa aking mga repositoryo. Narito ang isang listahan ng aking mga frontend na proyekto. Kung mayroon kang isang bagay na gusto mo o kapaki-pakinabang, gusto kong idagdag mo ito! Sa wakas, ang Awesome First PR Opportunities ay isang higanteng repository ng mga open source na proyekto para sa mga nagsisimula. May mga proyekto sa 22 iba't ibang wika!

2. Magpasya kung paano ka makakapag-ambag

Tingnan ang proyekto. Basahin ang Readme. I-scan ang iba't ibang mga folder at file. Magkaroon ng pag-unawa sa istruktura ng codebase. Sa paggawa nito, madali mong mahahanap at maitama ang typo! Kapag nagawa mo na iyon, tingnan ang seksyong Mga Isyu ng proyekto. Doon ay makikita mo ang isang listahan ng mga dating nakitang bug o iminungkahing feature. Sa kabutihang palad, maraming mga proyekto ang nagsasangkot ng mga problema na nakatuon sa mga nagsisimula. Sa tingin ko, ang iyong unang kontribusyon ay dapat na banayad hangga't maaari, ngunit kung gusto mong mabilis na makilala, ikaw ang bahala. Kapag nakakita ka ng isang bagay na maaari mong idagdag sa proyekto, kakailanganin mong i-fork ito.

3. Paglikha ng isang tinidor ng proyekto

Ang isang tinidor (tinidor ng isang proyekto) ay lumilikha ng eksaktong kopya nito sa iyong sariling Github repository.

4. I-clone ang proyekto nang lokal

Pagkatapos ay i-clone ang proyekto sa isang lokal na folder gamit ang URL ng proyekto.

git clone <project-url>

Dito makikita mo ang URL. Ngayon na ang proyekto ay nasa iyong computer, buksan ito sa isang editor. Kung sa tingin mo ay magtatagal ang mga pagbabago, tiyaking mag-sync ng kopya ng proyekto sa orihinal upang lagi mong malaman ang mga pagbabago. Mahahanap mo ang eksaktong mga utos ng Git para dito .

5. Gumawa ng bagong branch para sa iyong mga pagbabago

Oras na para gawin ang iyong mga pagbabago/pagwawasto! Gumawa ng bagong branch kung saan magkakabisa ang iyong mga pagbabago.

git branch <branch-name>

Maaari mong tawagan ito kahit anong gusto mo, ngunit sa aking karanasan ay makikita mo ang isang pattern para sa pagbibigay ng pangalan sa mga sangay sa orihinal na proyekto. Sa kasong ito, inirerekumenda kong sundin ang kasalukuyang template. Ang isang magandang pangalan ng sangay upang ayusin ang typo ay patch/typo-fix . Maaari kang lumipat sa sangay na ito gamit ang git checkout <branch-name> . Ngayon gawin ang iyong mga pagbabago!

6. Magbukas ng PR (Pagsamahin ang Kahilingan)

Kaya naayos mo ang isang nakasisilaw na typo o nag-update ng sirang link. Ipinagmamalaki mo ang iyong trabaho. Gusto mong malaman ng buong mundo na isa ka sa mga mythical developer na kayang mag-code, magbura, at manood ng Netflix nang sabay-sabay. Itulak ang iyong mga pagbabago sa isang branched Github repository gamit ang git push -u origin <branch-name> . Pumunta sa iyong forked Github repository at magbukas ng PR (pull request). Tandaan: Kung hindi ka pa nakagawa ng pull request dati, panoorin ang video na ito ni Kent Dodds para matutunan kung paano ito gawin. Tiyaking tumuturo ang iyong sangay sa master branch ng source repository. Ngayon ay handa ka nang magdagdag ng mga detalye sa iyong PR. Siguraduhing malinaw na naihahatid ng iyong headline ang nilalaman ng PR. Magdagdag ng paglalarawan: Kung nag-aayos ka ng kasalukuyang problema, tiyaking magsama ng link dito. Kapag tapos ka na sa iyong paglalarawan, isumite ang iyong PR para sa pagsusuri. Ang sinumang may awtoridad na aprubahan ang PR ay malamang na susuriin ang iyong aplikasyon sa loob ng ilang araw at gagawin ang isa sa mga sumusunod:

1. Pagsasamahin kaagad ang mga pagbabago.
2. Hihilingin nito sa iyo na gumawa ng mga pagbabago.
3. Isasara ang iyong PR.

Mangyaring maging mapagpasensya dahil maaaring abala ang gumawa ng repositoryo sa isang full-time na trabaho o iba pang mga proyekto.

Nagawa mo!

Isa ka na ngayong contributor sa open source na proyekto! Anong pakiramdam? Handa nang bumuo ng sarili mong kakumpitensya sa Node.js? Umaasa ako na sa pamamagitan ng paggawa ng isang simpleng kontribusyon, ang mga prospect para sa hinaharap na open source na trabaho ay magiging mas nakakatakot. Para sa higit pang impormasyon sa mga open source na kontribusyon, tingnan ang open source na mga gabay .