Ang isa sa mga pinaka-idiot-laden na propesyon ay ang mga manager na namamahala sa mga programmer. Hindi lahat, ngunit ang mga hindi programmer mismo. Ang mga nag-iisip na posibleng "pataasin" ang kahusayan (o dagdagan ang "kahusayan"?) gamit ang mga pamamaraan mula sa mga libro. Nang hindi man lang nag-abala na basahin ang parehong mga librong ito, ang video ay isang gypsy.
Ang mga hindi kailanman nagsulat ng code. Yaong para kanino ginawa ang mga pelikulang Hollywood tungkol sa mga programmer - mabuti, ang mga kung saan sila nanonood ng email gamit ang command line. Ang mga hindi interesado sa anumang bagay maliban sa mga tagapagpahiwatig, mga deadline at kanilang sariling suweldo.
Yung mga nakakarami.
Ngunit sila ay mga tanga sa ibang dahilan. Gusto nila ng kahusayan, o hindi bababa sa pagiging epektibo (halika, manager, Google kung ano ang pagkakaiba), nang hindi nauunawaan ang alinman sa isa o ang isa pa. Nang walang pangkalahatang pag-unawa sa kakanyahan, ang proseso ng pagkuha ng resulta, ang mga pagkalugi na nangyayari sa prosesong ito, ang mga gastos sa pag-unlad. Sa madaling salita, nagtatrabaho sa isang programmer na parang siya ay isang itim na kahon.
Dumating sila sa pamamahala ng mga programmer para sa eksaktong isang dahilan: mayroong hype, pera, merkado at isang grupo ng mga parehong idiots. May isang lugar upang mawala.
Kung mayroong hype sa paggawa ng mekanikal na pagpupulong, tatakbo kami doon. Pangit ang mga station wagon. Hindi ako magtataka na ang lalaking nagbebenta ng mga Christmas tree sa aming lugar noong Disyembre ay isang IT manager na nagbabakasyon.
Sa madaling salita, kung maaari, barilin ang mga taong ito sa leeg. Huwag mag-alala, makakahanap sila ng trabaho. Wala sa kanila ang gagawa ng anumang disente hanggang sila mismo ay maging programmer. Dahil hindi niya maintindihan ang esensya, mekanismo, lohika ng prosesong kinokontrol niya.
Okay, sapat na tungkol sa mga manager. Ngayon sa punto, para sa mga programmer. Paano pataasin ang kahusayan sa pag-unlad sa pamamagitan ng pag-aaral na magsulat ng mataas na kalidad na code.
Upang madagdagan ang kahusayan, kailangan mong malutas ang mga problema nang mas mabilis nang hindi nawawala ang kalidad. Upang mas mabilis na malutas ang mga problema, kailangan mong agad na makapagsulat ng mataas na kalidad na code. At "mataas na kalidad", at "magsulat", at "kaagad". Hayaan akong ipaliwanag sa isang metapora.
Ang pagsulat ng mataas na kalidad na code ay parang pagsasalita ng isang wikang banyaga nang tama. Kapag hindi mo alam ang isang wika, gumugugol ka ng maraming oras upang subukang bumalangkas ang iyong mga saloobin dito.
Kung kailangan mong sabihin ang isang bagay nang mapilit, manatili ka lamang sa ilang mga salita, madalas na hindi ang mga tama, nakakalimutan mo ang tungkol sa mga artikulo, ang tamang pagkakasunud-sunod ng salita, hindi banggitin ang mga panahunan ng pandiwa at mahinang pagbigkas.
Kung mayroon kang oras upang bumalangkas ng isang sagot, kakailanganin mong magbukas ng isang diksyunaryo o isang online na tagasalin at gumugol ng maraming oras sa pagbabalangkas ng iyong mga iniisip. Ang pakiramdam, gayunpaman, ay hindi pa rin kasiya-siya: sasabihin mo ang sagot, at hindi mo alam kung ito ay tama o hindi. Ito ay pareho sa code - ito ay tila nakasulat, tila gumagana, ngunit kung ito ay may magandang kalidad o hindi ay isang misteryo.
Ito ay lumiliko na maging isang dobleng pag-aaksaya ng oras. Ito ay tumatagal ng oras upang makabuo ng isang sagot. Kailangan din ng oras upang mabuo ang sagot na ito - at hindi gaanong kaunti.
Kung ang kasanayan sa pagsulat ng mataas na kalidad na code ay naroroon, kung gayon ang sagot ay maaaring mabuo kaagad, sa sandaling ito ay matured sa ulo, nang hindi gumugol ng karagdagang oras sa pagsasalin.
Ang kasanayan sa pagsulat ng mataas na kalidad na code ay nakakatulong kapag nagdidisenyo ng arkitektura. Hindi mo lang isasaalang-alang ang mga hindi tama, hindi mapagtanto o hand-me-down na mga opsyon sa iyong ulo.
Upang ibuod: ang kasanayan sa pagsulat ng mataas na kalidad na code ay makabuluhang nagpapabilis sa paglutas ng problema.
Ngunit hindi lang iyon. Salamat sa mga tagapamahala ng felt boots, mayroong isang catch - wala kaming dahilan upang magsulat ng mataas na kalidad na code. Ang manager ay hindi tumitingin sa code, ang kliyente ay hindi tumitingin sa code. Bihira kaming magpakita ng code sa isa't isa, minsan lang, sa ilang proyekto kung saan may nakatalagang code na "checker" o panaka-nakang refactoring.
Lumalabas na sa karamihan ng mga kaso ang bastos na code ay napupunta sa produksyon o sa kliyente. Ang isang tao na nagsulat ng shitty code ay bumubuo ng isang stable na neural connection - hindi lang posible na magsulat ng shitty code, ngunit kailangan din - ito ay tinatanggap, at binabayaran pa nila ito.
Bilang resulta, ang kasanayan sa pagsulat ng mataas na kalidad na code ay walang pagkakataon na umunlad. Ang code na isinulat ng isang may kondisyong empleyado ay hindi kailanman sinusuri ng sinuman. Ang tanging dahilan kung bakit siya matututong magprograma nang normal ay ang panloob na pagganyak.
Ngunit ang panloob na pagganyak na ito ay sumasalungat sa mga plano at kinakailangan para sa kahusayan at pagiging produktibo. Ang kontradiksyon na ito ay malinaw na hindi naresolba pabor sa mataas na kalidad na code, dahil hindi man lang pinupuna ng mga tao ang mga tao para sa bastos na code. At para sa kabiguan na matupad ang plano - kahit na.
Anong gagawin ko? Nakikita ko at nagmumungkahi ng dalawang landas na maaaring pagsamahin.
Ang una ay ipakita ang iyong code sa isang tao sa loob ng kumpanya. Hindi reaktibo (kapag tinanong/pinilit), ngunit maagap (uh, pare, tingnan mo ang aking code, mangyaring). Ang pangunahing bagay dito ay hindi mag-post ng matamis na snot, hindi subukang ilagay ang pagpuna sa code sa isang magalang na anyo. Kung ang code ay crap, sinasabi namin ito: ang code ay crap. Sa mga paliwanag, siyempre, at mga rekomendasyon kung paano ito gagawing mas mahusay.
Ngunit ang landas na ito ay ganoon din. Ang pagiging angkop nito ay depende sa punto kung saan naganap ang pakikipag-ugnayan. Kung ang trabaho ay napunta na sa produksyon at ito ay lumabas na ang code ay crap, walang saysay na gawin itong muli. Mas tiyak, ang mga dahilan - bababa din ang mga sukatan. Dadalhin ka ng mga manager at dudurugin ka ng mga kinakailangan sa kahusayan. At huwag mo ring subukang ipaliwanag sa kanila na ang bastos na code ay tiyak na babalik sa anyo ng mga bug - ito ay magiging backfire sa iyo. Maaari ka lamang gumawa ng pangako na hindi na ito gagawin muli.
Kung ang gawain ay hindi pa naihatid, o nagsisimula pa lang, kung gayon ang pagbuhos ng tae sa code (o proyekto nito, ideya) ay maaaring magkaroon ng isang praktikal na kahulugan - gagawin ito ng tao nang normal.
Ang pangalawang paraan, ang pinakaastig, ay ang paggawa ng open source development sa mga oras na hindi nagtatrabaho. Ano ang layunin: para sa isang grupo ng mga programmer, katulad ng mga programmer, upang makita ang iyong code at magsalita tungkol dito. Lahat ng tao sa loob ng kumpanya ay walang oras. Ngunit ang mga programmer sa buong mundo ay wala pa ring magagawa, at kung magsusulat ka ng isang bagay na kapaki-pakinabang mula sa isang punto ng aplikasyon, tiyak na titingnan nila ang loob.
Ang pangunahing lansihin, sa palagay ko, ay ang pagsulat ng code sa mga oras na hindi nagtatrabaho, dahil hindi gagana ang kontradiksyon sa pagitan ng kalidad ng code at ang bilis ng paghahatid ng resulta. Isulat ang iyong pag-unlad nang hindi bababa sa isang taon. Ang mga deadline, o teknikal na mga detalye, o pera, o boss ay hindi maglalagay ng presyon sa iyo. Ganap na kalayaan at pagkamalikhain.
Sa libreng pagkamalikhain lamang mauunawaan at madarama mo kung ano ang magandang code, makikita ang kagandahan ng wika at teknolohiya, at madarama ang kagandahan ng mga gawain sa negosyo. Well, matututunan mong magsulat ng mataas na kalidad na code.
Totoo, kakailanganin mong gumugol ng personal na oras. Katulad ng ibang development. Tingnan ito hindi bilang isang gastos, ngunit bilang isang pamumuhunan - sa iyong sarili.
Pinagmulan: www.habr.com