Coffee break #13: Ano ang dapat malaman ng bawat newbie sa programming; 4 na Paraan para Isama ang Pag-iisip ng Disenyo sa Iyong Proseso ng Pag-unlad

Ano ang dapat malaman ng bawat baguhan sa programming

Source: Stackoverflow Bilang isang developer, maririnig mo ang maraming iba't ibang teorya tungkol sa kung ano ang dapat na hitsura ng code. Ang ilang mga tao ay naniniwala na ang mas kaunting mga linya ng code ay mayroon ang isang application, mas madali itong basahin. Ngunit ito ay bahagyang totoo lamang. Mas gusto kong suriin ang kalidad ng code gamit ang sumusunod na pamantayan:

1. Ang code ay dapat na pare-pareho, nagbibigay-kaalaman, at mahusay na dokumentado.
2. Ang code ay dapat gumamit ng matatag at modernong mga tampok.
3. Ang code ay hindi dapat maging kumplikado o sira nang hindi kinakailangan.

Kung magpasya kang bawasan ang bilang ng mga linya ng code sa gastos ng isa sa mga pamantayan sa itaas, ito ay magiging isang problema. Huwag mong gawin yan.

Ang pagbabasa ng code ng ibang tao ay mahirap

Sa katunayan, ang ratio ng oras na ginugol sa pagbabasa at pagsulat ng code ay higit sa 10 sa 1. Ngunit hindi mo magagawa nang hindi binabasa ang code ng ibang tao. Kakailanganin mong basahin ang code ng ibang tao. At kung mas maaga mong pagbutihin ang iyong mga kasanayan, mas mabuti. Subukang pag-aralan ang code ng ibang tao gamit ang bukas na GitHub repository. Maaari kang magsanay anumang oras: maghanap lang ng proyektong nababagay sa iyo at suriin ang bawat linya. Ang isa pang paraan upang mapabuti ang iyong kakayahang magbasa ng code ng ibang tao ay ang simulang kopyahin mo ang istilo. Kapag sumulat ka ng code sa istilo ng ibang tao, hindi lamang nito pinapabuti ang iyong mga kasanayan sa pagbabasa, ngunit ginagawang mas pamilyar sa iyo ang code. Subukan.

Hindi ka magsusulat ng "perpektong" code

Ako ay isang solo developer sa loob ng apat na taon bago ako nagsimulang magtrabaho sa isang koponan. Para sa karamihan ng oras na ito, naniniwala ako na ang sinumang may karanasan na programmer ay nagsulat ng perpektong code. Sa aking opinyon, ang pag-aaral na magsulat ng perpektong code ay isang bagay lamang ng oras at pagsisikap. Ngunit nang sumali ako sa koponan, naging malinaw na walang nagsusulat ng "perpektong" code. Totoo, ang code na sa huli ay kasama sa system ay halos palaging "perpekto." Bakit nangyari ito? Ito ay tungkol sa pagsusuri ng code. Nagtatrabaho ako sa isang pangkat ng mga tunay na mahuhusay na inhinyero. Ito ang ilan sa mga pinaka-kompetensya, may kumpiyansa na mga programmer na makukuha ng pera. Ngunit ang bawat isa sa kanila (kabilang ako) ay magkakaroon ng totoong panic attack kung sinuman ang nagmungkahi na isama ang hindi pa nasubok na code sa application. Kahit na iniisip mong ikaw na ang susunod na Bill Gates, magkakamali ka. Hindi ako nagsasalita tungkol sa mga lohikal na error, ang sinasabi ko ay tungkol sa mga typo, nawawalang mga character. Mga bagay na minsan hindi nahuhuli ng utak mo. Mga bagay na mapapansin lamang ng sariwang mata. Sikaping makipagtulungan sa mga taong matulungin sa detalye at handang pumuna sa iyong gawa. Mahirap tanggapin ang pagpuna sa simula, ngunit ito ang tanging maaasahang paraan upang mapabuti ang kalidad ng iyong code. Gawin ang iyong makakaya upang hindi maging defensive kapag nagre-review ng code, at huwag na huwag nang personal na pintasan. Hindi ikaw ang iyong code.

Hindi ka dapat magsulat ng code 8 oras sa isang araw

Walang makapagsasabi sa iyo nang eksakto kung gaano karaming oras sa isang araw ang ginugugol nila sa pagsusulat ng code. Ngunit sa katotohanan, kakaunti ang nagsusulat ng code nang higit sa 4 na oras sa isang araw. Ang mga taong hindi sumasang-ayon dito ay maaaring eksepsiyon sa panuntunan o nagtatrabaho para sa mga kumpanyang hindi maganda ang pakikitungo sa kanilang mga tauhan. Ang programming ay matindi, nakakapagod sa pag-iisip. Ganap na mali ang isipin na may magsusulat ng code 8 oras sa isang araw, 5 araw sa isang linggo. May mga bihirang pagkakataon na kailangan mong matugunan ang isang deadline, ngunit kapag sinabi kong bihira, ang ibig kong sabihin ay halos hindi. Huwag hayaang mabigatan ka ng trabaho at pilitin kang mag-overtime. Hindi ko iminumungkahi na magtrabaho ka lamang ng apat na oras sa isang araw. Ang natitirang apat na oras ay karaniwang pinakamahusay na ginugol sa mga bagay tulad ng:

• pag-aaral ng mga bagong tool, function, application;
• pagtalakay sa mga proseso ng trabaho sa mga kasamahan;
• pagtulong sa mga kasamahan na nahihirapan sa trabaho;
• pagpaplano ng gawain;
• pagsusuri ng code;
• mga pulong/pagpupulong sa negosyo.

Inirerekomenda ko rin ang pagkuha ng mga regular na pahinga sa buong araw at pag-eehersisyo (kahit kaunti). Ang mga positibong epekto ng ehersisyo ay matagal nang napatunayan.

4 na Paraan para Isama ang Pag-iisip ng Disenyo sa Iyong Proseso ng Pag-unlad

Source Tech Beacon Upang lumikha ng isang produkto na nakakatugon sa mga pangangailangan ng iyong mga customer, kailangan mong isaalang-alang kung ano ang gusto nila. Kung nagsulat ka ng isang app na may nakalilitong nabigasyon o isang hindi kinakailangang mahabang interface sa paglo-load, ihanda ang iyong sarili para sa kabiguan sa hinaharap. Bilang isang programmer, maaaring kailanganin mong pag-isipang mabuti ang disenyo ng produktong pinagtatrabahuhan ng iyong koponan. Ang ganitong uri ng pakikipagtulungan ay lubhang kapaki-pakinabang dahil ang bawat tao ay napapansin ang mga bagay na maaaring hindi napapansin ng iba. Nag-aalok ako sa iyo ng 4 na tip sa kung paano maaaring magtulungan ang isang developer at designer.

1. Makilahok sa simula pa lamang

Huwag ipagpalagay na ang disenyo ay palaging nauuna at ang pag-unlad ay pumapangalawa. Maaaring totoo ito, ngunit hindi ito nangangahulugan na hindi dapat kasangkot ang mga developer sa proseso ng disenyo. Ang programmer ay nakapagbibigay ng mahalagang teknikal na impormasyon tungkol sa kung paano maipapatupad ang proyekto, habang ang mga taga-disenyo ay mas nauunawaan ang mga hinahangad ng mga gumagamit. Mas mainam na alamin sa lalong madaling panahon kung aling function ang teknikal na imposible o hindi nakakatugon sa mga kinakailangan ng user. Kung magtutulungan ang mga designer at developer, matutuklasan at maresolba kaagad ang mga problema sa halip na matapos maaprubahan ang disenyo. Maraming mga kumpanya ang kumukuha ng isang collaborative na diskarte sa pagbuo ng software. Nangangahulugan ito na ang mga miyembro ng koponan ay hindi lamang responsable para sa kanilang sariling yugto o piraso ng code, ngunit kumuha ng sama-samang responsibilidad para sa lahat mula sa disenyo hanggang sa pagsubok.

2. Alamin ang proseso ng UX

Maaaring hindi maintindihan ng mga hindi pamilyar sa UX (karanasan ng user) kung bakit paulit-ulit na nagbabago ang mga disenyo ng mga team para sa tila maliliit na detalye. Ang bawat hakbang sa proseso ng UX ay nangyayari para sa isang dahilan: upang magbigay ng pinakamahusay na posibleng karanasan sa user. Samakatuwid, mahalagang bigyang-pansin ang paglikha ng proseso ng UX mula pa sa simula. Maaaring kabilang dito ang:

• pagsasaliksik sa layunin ng proyekto;
• paglikha ng isang wireframe - isang simpleng disenyo na nagbibigay-daan sa iyo upang matukoy ang mga pangunahing katangian ng produkto;
• pagdaragdag ng mas pinong mga detalye sa disenyo ng proyekto, tulad ng user interface;
• pagsubok ng gumagamit ng mga disenyo. Ito marahil ang pinakamahalagang yugto ng pag-unlad ng UX. Nagbibigay ito ng mahalagang impormasyon tungkol sa produkto bago ka gumugol ng oras sa pagbuo nito;
• Pag-ulit: Gamit ang pagsusuri ng mga resulta ng pagsubok, ulitin ang disenyo upang mapabuti ang karanasan ng user.

Ulitin ng mga koponan ang mga hakbang sa disenyo at pagsubok nang maraming beses hanggang sa wala nang mga pagbabagong natitira, o hangga't pinapayagan ng oras. Karaniwang nangangahulugan ito na magkakaroon ka ng maraming bersyon ng disenyo.

3. Sundin ang pagbuo ng disenyo

Napakasama kapag ang mga taga-disenyo ay lumikha ng isang proyekto nang hindi kumukunsulta sa mga developer. Ito ay kontraproduktibo. Mahalaga para sa DevOps na magtakda ng mga panuntunan para magkaroon ng access ang mga developer sa pagdidisenyo ng mga blueprint sa madaling ma-access na mga format gaya ng PNG o PDF. Ang epektibong pakikipagtulungan sa pagitan ng mga developer at designer ay kritikal sa matagumpay na pagpapatupad ng isang application. Iwasang bulag na ibigay ang isang tapos na disenyo sa lahat ng gastos. Mas mabuting itama ang isang pagkakamali sa simula kaysa sa huli.

4. Sumang-ayon sa kung anong yugto ipapakita sa iyo ang proyekto

Kapag hiniling sa mga developer na lumikha ng isang minimum na viable na bersyon ng isang produkto (MVP), kailangan nilang malaman ang mga kinakailangan para sa huling bersyon sa simula pa lang. Ito ay kinakailangan upang maiwasan ang mga problema sa hindi makatarungang mga inaasahan. Dapat ipakita ng mga designer ang parehong bersyon ng disenyo sa developer: parehong MVP at ang huling bersyon. Makakatulong ito sa pagpapatupad ng MVP, na isinasaalang-alang kung ano ang inaasahan ng customer na makita sa huling bersyon. Kapag nagtutulungan ang mga taga-disenyo at developer, nakakakuha sila ng maraming benepisyo. Ang bawat isa sa kanila ay may kaalaman na maaaring magamit sa karanasan ng iba. Maaaring magbigay ang mga developer ng mahalagang insight sa kung anong mga feature ang hindi maipapatupad sa disenyo. Sa kabilang banda, ang pakikipagtulungan sa isang programmer ay magpapagaan sa taga-disenyo mula sa pangangailangan na gawing muli ang proyekto, na, nang naaayon, ay makatipid ng oras para sa buong koponan.