Адна з самых перагружаных ідыётамі спецыяльнасцяў - менеджэры, якія кіруюць праграмістамі. Не ўсе, а тыя, якія самі праграмістамі зроду не былі. Тыя, якія думаюць, што можна "павышаць" эфектыўнасць (ці падвышаць "эфектыўнасць"?) метадамі з кніжак. Нават не знайшоўшы час гэтыя самыя кніжкі прачытаць — відасік жа ёсць цыганскі.
Тыя, якія ніколі не пісалі код. Тыя, для якіх здымаюць галівудскія фільмы пра праграмістаў - ну, тыя, дзе электронную пошту камандным радком глядзяць. Тыя, якім не цікава нічога, акрамя паказчыкаў, тэрмінаў і ўласнай зарплаты.
Тыя, якіх большасць.
Але ідыёты яны па іншай прычыне. Яны жадаюць эфектыўнасці, ці хаця б рэзультатыўнасці (давай, менеджэр, гуглі, у чым розніца), не разбіраючыся ні ў тым, ні ў іншым. Наогул не разумеючы сутнасці, працэсу атрымання выніку, страт, якія адбываюцца ў гэтым працэсе, затрат на распрацоўку. Карацей, працуючы з праграмістам, як з чорнай скрыняй.
Панабеглі ва ўпраўленне праграмістамі роўна па адной прычыне: тут хайп, грошы, рынак і куча такіх жа ідыётаў. Ёсць, дзе згубіцца.
Быў бы хайп у механазборачнай вытворчасці - пабеглі б туды. Універсалы хрэновы. Не здзіўлюся, што чувак, які прадае ў снежні ёлкі ў нашым квартале, гэта ІТ-мэнэджар у адпачынку.
Карацей, калі ёсць магчымасць, ганіце гэтых хлопцаў у шыю. Не хвалюйцеся, яны знойдуць сабе працу. Ніхто з іх ніколі не зробіць нічога прыстойнага, пакуль сам не стане праграмістам. Бо не разумее сутнасці, механізму, логікі працэсу, якім кіруе.
Ну ўсё, хопіць пра мэнэджэраў. Цяпер па справе, для праграмістаў. Як павысіць эфектыўнасць распрацоўкі, навучыўшыся пісаць якасны код.
Каб павысіць эфектыўнасць, трэба хутчэй рашаць задачы, не губляючы якасці. Каб хутчэй рашаць задачы, трэба ўмець адразу пісаць якасны код. І "якасны", і "пісаць", і "адразу". Растлумачу метафарай.
Пісаць якасны код - гэта як пісьменна гаварыць на замежнай мове. Калі мовы не ведаеш, марнуеш кучу часу на тое, каб сфармуляваць на ёй свае думкі.
Калі сказаць трэба тэрмінова, проста налепіш нейкіх слоў, часцяком не тых, што трэба, забудзешся пра артыклі, правільны парадак слоў, не кажучы ўжо пра часы дзеясловаў і ўбогім вымаўленні.
Калі ёсць час на фармулёўку адказу, то давядзецца адкрываць слоўнік, або інтэрнэт-перакладчык, і марнаваць кучу часу на фармулёўку сваіх думак. Пачуццё, праўда, усё роўна будзе непрыемнае: адказ кажаш, і не ведаеш, правільны ён ці не. Аналагічна з кодам - накшталт напісаў, накшталт працуе, а якасны ён ці не - ХЗ.
Атрымліваецца падвойная страта часу. На тое, каб прыдумаць адказ, ідзе час. На тое, каб гэты адказ сфармуляваць, таксама сыходзіць час - прычым, не так ужо і мала.
Калі ж навык напісання якаснага кода прысутнічае, то адказ можна фармуляваць адразу, як толькі ён саспеў у галаве, не марнуючы дадатковы час на пераклад.
Навык напісання якаснага кода дапамагае пры праектаванні архітэктуры. Ты проста не будзеш разглядаць у галаве няправільныя, нерэалізуемыя або рукажопыя варыянты.
Рэзюмуючы: навык напісання якаснага кода істотна паскарае рашэнне задач.
Але і гэта не ўсё. Дзякуючы валёнкам-мэнэджарам, ёсць адна загваздка - вось так у нас няма падставы пісаць якасны код. Мэнэджар код не глядзіць, кліент код не глядзіць. Адно аднаму мы код паказваем рэдка, толькі часам, у некаторых праектах, дзе ёсць прызначаны «правяратар» кода або перыядычны рэфактарынг.
Атрымліваецца, у большасці выпадкаў гаўнакод сыходзіць у прадакшн або кліенту. У чалавека, які напісаў гаўнакод, фармуецца ўстойлівая нейронавая сувязь - гаўнакод пісаць не толькі можна, але і трэба - яго прымаюць, ды яшчэ і плацяць за гэта.
У выніку, у навыку напісання якаснага кода наогул няма шанцаў развіцца. Код, напісаны ўмоўным супрацоўнікам, не правярае ніхто і ніколі. Адзіная прычына, па якой ён навучыцца нармальна праграмаваць - унутраная матывацыя.
Але гэтая ўнутраная матывацыя ўступае ў супярэчнасць з планамі і патрабаваннямі па эфектыўнасці і прадуктыўнасці. Вырашаецца гэта супярэчнасць відавочна не на карысць якаснага кода, бо за гаўнакод нават не лаюць. А за невыкананне плана - яшчэ як.
Як быць? Я бачу і прапаную два шляхі, якія можна спалучаць.
Першы - паказваць свой код камусьці ўнутры кампаніі. Не рэактыўна (калі просяць/прымушаюць), а проактивно (э, чувак, зірні мой код, пжлста). Тут галоўнае - не развешваць цукровыя соплі, не імкнуцца апрануць крытыку кода ў ветлівую форму. Калі код лайно, мы так і які гаворыцца: код - лайно. З тлумачэннямі, зразумела, і рэкамендацыямі, як зрабіць яго лепшым.
Але гэты шлях таксама так сабе. Яго дастасавальнасць залежыць ад кропкі, у якой адбыўся кантакт. Калі праца ўжо патрапіла ў прадакшн, і высветлілася, што код - лайно, перарабляць яго ўжо няма сэнсу. Дакладней, нагоды - яшчэ і метрыкі просядуць. Набягуць менеджэры і задушаць патрабаваннямі да эфектыўнасці. І нават не спрабуй ім растлумачыць, што гаўнакод абавязкова вернецца ў выглядзе багаў - табе ж бокам выйдзе. Можна толькі ўзяць на сябе абавязацельства больш так не рабіць.
Калі ж праца яшчэ не здадзена, ці толькі пачата, тое паліванне кода (ці яго праекту, задумкі) лайном можа мець суцэль сабе практычны сэнс – чалавек зробіць звычайна.
Другі шлях, самы круты - заняцца апенсорс-распрацоўкай у непрацоўны час. Мэта ж якая: каб куча праграмістаў, менавіта праграмістаў, убачылі твой код і выказаліся аб ім. Унутры кампаніі ўсім некалі. А праграмістам усяго свету ўсё роўна заняцца няма чым, і, калі ты напішаш карысную з прыкладнога пункта гледжання штуку, то яны абавязкова зазірнуць унутр.
Галоўная фішка, на мой погляд - гэта напісанне кода ў непрацоўны час, таму што не будзе працаваць супярэчнасць якасці кода і хуткасці выдачы выніку. Хоць год пішы сваю распрацоўку. На цябе не будуць ціснуць ні тэрміны, ні ТЗ, ні грошы, ні начальнік. Поўная свабода і творчасць.
Толькі ў свабоднай творчасці ты зразумееш і адчуеш, што такое класны код, убачыш прыгажосць ЯП і тэхналогій, адчуеш хараство бізнес-задач. Ну і навучышся пісаць якасны код.
Праўда, гэта запатрабуе ад цябе выдаткаў асабістага часу. Як і, уласна, любое іншае развіццё. Разглядай гэта не як выдатак, а як інвестыцыю - у сябе.
Крыніца: habr.com