Я гляджу на кавалак кода. Магчыма, гэта найгоршы код, што мне калі-небудзь сустракаўся. Каб абнавіць усяго адзін запіс у базе дадзеных, ён здабывае ўсе запісы ў калекцыі, а затым адпраўляе запыт на абнаўленне кожнага запісу ў базе, нават тыя, якія абнаўляць не патрабуецца. Тут ёсць map-функцыя, якая проста вяртае перададзенае ёй значэнне. Ёсць умоўныя праверкі зменных з відавочна аднолькавым значэннем, проста найменных у розных стылях (firstName и first_name). Для кожнага UPDATE'а код адпраўляе паведамленне ў іншую чаргу, якая апрацоўваецца іншай serverless-функцыяй, але якая выконвае ўсю працу для іншай калекцыі ў той жа базе дадзеных. Я не згадаў, што гэтая serverless-функцыя з хмарнай «сэрвіс-арыентаванай архітэктуры», утрымоўвальнай больш 100 функцый у асяроддзі?
Як увогуле можна было такое зрабіць? Я закрываю твар і выразна ўсхліпваю скрозь смех. Мае калегі пытаюцца, што здарылася, і я ў фарбах пераказваю Worst Hits Of BulkDataImporter.js 2018. Усе спачувальна ківаюць мне і згаджаюцца: як яны маглі так з намі паступіць?
Негатыў: эмацыйны інструмент у праграмісткай культуры
Негатыў гуляе ў праграмаванні важную ролю. Ён убудаваны ў нашу культуру і выкарыстоўваецца для таго, каб падзяліцца пазнаным («ты не паверыш, на што быў падобны гэты код!»), для выказвання спагады праз засмучэнне («пане, НАВОШТА так рабіць?»), каб паказаць сябе ў выгадным святле («я б ніколі так не зрабіў»), каб узваліць віну на іншага («мы зафейліліся з-за яго кода, які немагчыма суправаджаць»), ці, як прынята ў самых «таксічных» арганізацыях, каб кіраваць іншымі праз пачуццё сораму («ты пра што наогул думаў ? выпраўляй »).
Негатыў гэтак важны для праграмістаў таму, што гэта вельмі эфектыўны спосаб перадачы каштоўнасці. Калісьці я вучыўся ў лагеры для праграмістаў, і стандартнай практыкай прышчэпкі студэнтам цэхавай культуры было шчодрае забеспячэнне мемамі, гісторыямі і відэа, самыя папулярныя з якіх эксплуатавалі . Добра, калі можна выкарыстоўваць эмацыйныя прылады для пазначэння методык Добрых, Дрэнных, Жудасных, Ніколі Так Не Рабіце, Наогул Ніколі. Трэба падрыхтаваць пачаткоўцаў да таго, што іх, напэўна, будуць разумець памылкова калегі, далёкія ад IT. Што іх сябры пачнуць уцюхваць ім ідэі прыкладанняў "на мільён". Што ім давядзецца блукаць у бясконцых лабірынтах састарэлага кода з кучай мінатаўра за вуглом.
Калі мы пачынаем упершыню вучыцца праграмаванню, наша ўяўленне аб глыбіні "досведу праграмавання" грунтуецца на назіраннях за эмацыйнымі рэакцыямі іншых людзей. Гэта добра відаць па пастах у , у якім тусуецца шмат пачаткоўцаў-праграмістаў Многія гумарыстычныя ў той ці іншай ступені афарбаваны рознымі адценнямі негатыву: расчараванне, песімізму, абурэння, паблажлівасці і іншых. А калі вам гэтага здасца мала, пачытайце каментары.
Я заўважыў, што, па меры назапашвання досведу, у праграмістаў становіцца ўсё больш негатыву. Навічкі, якія не падазраюць аб чакаюць іх цяжкасцях, пачынаюць з энтузіязмам і гатоўнасцю паверыць, што прычына гэтых цяжкасцяў проста ў недахопе вопыту і ведаў; і ў рэшце рэшт яны сутыкнуцца з рэальным становішчам рэчаў.
Праходзіць час, яны набіраюцца досведу і знаходзяць магчымасць адрозніць Добры код ад Дрэннага. І калі гэты момант надыходзіць, маладыя праграмісты адчуваюць засмучэнне ад працы з відавочна дрэнным кодам. А калі яны працуюць у калектыве (дыстанцыйна ці вочна), то часта пераймаюць эмацыйныя звычкі больш дасведчаных калег. Нярэдка гэта прыводзіць да павелічэння негатыву, бо маладыя зараз могуць глыбакадумна казаць аб кодзе і падзяляць яго на дрэнны і добры, паказваючы тым самым, што яны "ў тэме". Гэта яшчэ больш узмацняе негатыў: на глебе расчаравання лёгка сысціся з калегамі і стаць часткай групы, крытыка Дрэннага кода павялічвае ваш статут і прафесіяналізм у вачах іншых: .
Узмацненне негатыву не абавязкова дрэнная з'ява. Абмеркаванне праграмавання, апроч іншага, вельмі засяроджана на якасці напісанага кода. Тое, чым з'яўляецца код, цалкам вызначае функцыю, для якой ён прызначаны (адкінем абсталяванне, сетка і т. д.), так што важна мець магчымасць выказаць сваё меркаванне аб гэтым кодзе. Амаль усе дыскусіі зводзяцца да таго, ці дастаткова добры гэты код, і да асуджэння саміх маніфестаў дрэннага кода ў выразах, эмацыйная афарбоўка якіх характарызуе якасць кода:
- "У гэтым модулі шмат лагічных неадпаведнасцяў, гэта добры кандыдат на значную аптымізацыю прадукцыйнасці".
- "Гэты модуль даволі дрэнны, нам трэба яго рэфактарыць".
- "Гэты модуль не мае сэнсу, яго трэба перапісаць".
- "Гэты модуль адстой, яго трэба патчыць".
- «Гэта кавалак барана, а не модуль, яго ўвогуле не трэба было пісаць, пра што, блін, думаў яго аўтар».
Дарэчы, менавіта гэтая "эмацыйная разрадка" прымушае распрацоўшчыкаў называць код "сэксі", што рэдка бывае справядлівым - калі толькі вы не працуеце ў PornHub.
Праблема заключаецца ў тым, што людзі - дзіўныя, неспакойныя, напоўненыя эмоцыямі стварэння, і ўспрыманне і выраз любых эмоцый мяняе нас: спачатку ледзь прыкметна, але з часам - кардынальна.
Неспакойная слізкая дарожка негатыву
Некалькі гадоў таму я быў нефармальным тымлідам і гутарыў аднаго распрацоўшчыка. Ён нам вельмі падабаўся: быў разумны, задаваў добрыя пытанні, быў тэхнічна падкаваны і цудоўна ўпісваўся ў нашу культуру. Мне асабліва імпанавала яго пазітыўнасць і тое, якім прадпрымальным ён здаваўся. І я яго наняў.
На той момант я працаваў у кампаніі пару гадоў і адчуваў, што прынятая ў нас культура не надта эфектыўная. Мы спрабавалі запусціць прадукт двойчы, тройчы і яшчэ пару разоў да майго прыходу, што прыводзіла да вялікіх выдаткаў на пераробкі, на працягу якіх нам няма чаго было паказаць акрамя доўгіх начэй, сціслых тэрмінаў і тыпу-працуючых прадуктаў. І хоць я яшчэ старанна працаваў, аднак скептычна выказваўся ў адносінах да апошняга дэдлайну, прызначанага нам кіраўніцтвам. І нядбайна вылаяўся пры абмеркаванні з маімі калегамі некаторых аспектаў кода.
Так што не было нічога дзіўнага ў тым - хоць я здзівіўся, - што праз некалькі тыдняў той самы новы распрацоўшчык выказаўся ў тым жа негатыўным ключы, што і я (уключаючы лаянку). Я зразумеў, што ён павёў бы сябе інакш у іншай кампаніі з іншай культурай. Ён толькі падстроіўся пад тую культуру, якую стварыў я. Мяне накрыла пачуццё віны. З-за свайго суб'ектыўнага досведу я прышчапіў песімізм пачаткоўцу, якога я ўспрымаў зусім іншым. Нават калі ён насамрэч не быў такім і толькі стараўся здавацца, каб паказаць, што можа ўліцца ў калектыў, я навязаў яму сваё лайновае стаўленне. А ўсё сказанае, хай нават жартам ці мімаходзь, мае дурную манеру ператварацца тое, у што вераць.
Шляхі негатыву
Вернемся да нашых былых пачаткоўцаў-праграмістам, якія трошкі набраліся мудрасці і досведу: яны бліжэй пазнаёміліся з індустрыяй праграмавання і разумеюць, што дрэнны код усюды, яго нельга пазбегнуць. Ён сустракаецца нават у найболей прасунутых кампаніях, засяроджаных на якасці (і дазвольце заўважыць: судзячы па ўсім, сучаснасць зусім не ратуе ад дрэннага кода).
Добры сцэнар. З часам распрацоўшчыкі пачынаюць змірацца з тым, што дрэнны код – рэальнасць праграмнага забеспячэння, і што іх праца заключаецца ў тым, каб яго палепшыць. І што калі нельга пазбегнуць дрэннага кода, то і няма сэнсу паднімаць з-за яго шум. Яны ўстаюць на шлях дзэна, засяроджваюцца на рашэнні праблем ці задач, якія ўстаюць перад імі. Даведаюцца, як можна дакладна вымераць і падаць якасць ПЗ уладальнікам бізнесу, на аснове свайго шматгадовага вопыту пішуць выдатна абгрунтаваныя каштарысы, і ў канчатковым выніку атрымліваюць шчодрыя ўзнагароды за сваю неверагодную і нязменную каштоўнасць для бізнесу. Яны так добра робяць сваю працу, што ім плацяць прэміяльныя бонусы ў $10 млн., і яны выходзяць на пенсію, каб да канца жыцця займацца тым, чым хочацца (калі ласка, не прымайце на веру).
Іншы сцэнар - гэта шлях цемры. Замест таго, каб прыняць дрэнны код як непазбежнасць, распрацоўшчыкі бяруць на сябе абавязак абвяшчаць аб усім дрэнным у свеце праграмавання, каб яны маглі перамагчы гэта. Яны адмаўляюцца паляпшаць існуючы дрэнны код па мностве добрых прычын: "людзі павінны больш ведаць і не быць такімі тупымі"; "гэта непрыемна"; "гэта дрэнна для бізнесу"; "гэта даказвае, наколькі я разумны"; "калі я не раскажу, які гэта паршывы код, уся кампанія зрынецца ў акіян", і гэтак далей.
Напэўна не маючы магчымасці рэалізаваць жаданыя імі змены, паколькі бізнэс, на жаль, павінен працягваць распрацоўваць і не можа марнаваць час на клопат аб якасці кода, такія людзі знаходзяць рэпутацыю скаржнікаў. Іх трымаюць за высокую кампетэнтнасць, аднак выцясняюць на задворкі кампаніі, дзе яны не будуць шмат каму дапякаць, але пры гэтым будуць падтрымліваць працу крытычна важных сістэм. Пазбавіўшыся доступу да новых магчымасцяў у распрацоўцы, яны губляюць навыкі і перастаюць адпавядаць патрабаванням індустрыі. Іх негатыў ператвараецца ў жорсткую горыч, і ў выніку яны цешаць сваё эга, спрачаючыся з дваццацігадовымі студэнтамі аб шляху, пройдзеным іх каханай старой тэхналогіяй і чаму яна яшчэ бадзёрым. У рэшце рэшт яны выходзяць на пенсію і пражываюць старасць, лаючыся на птушак.
Верагодна, рэальнасць знаходзіцца недзе пасярэдзіне паміж гэтымі дзвюма крайнасцямі.
Некаторыя кампаніі надзвычай атрымалі поспех у стварэнні вельмі негатыўных, адасобленых, валявых культур (накшталт Microsoft да яе ) - Часта гэта кампаніі з прадуктамі, выдатна адпаведнымі рынку, і неабходнасцю расці як мага хутка; або кампаніі з іерархіяй кіравання і кантролю (Apple у лепшыя гады Джобса), дзе кожны робіць тое, што загадаюць. Аднак сучасныя бізнэс-даследаванні (ды і разумны сэнс) кажуць аб тым, што для максімальнай вынаходлівасці, якая прыводзіць да інавацыйнасці кампаніі, і высокай прадуктыўнасці асобных людзей неабходны нізкі ўзровень стрэсу, каб падтрымліваць бесперапыннае творчае і метадычнае мысленне. І вельмі цяжка выконваць творчую працу, у аснове якой ляжаць абмеркаванні, калі ўвесь час турбуешся аб тым, што твае калегі павінны будуць сказаць пра кожны радок твайго кода.
Негатыў - гэта інжынерная поп-культура
Сёння адносінам інжынераў надаецца столькі ўвагі, як ніколі. У інжынерных арганізацыях усё больш папулярным становіцца правіла.“. У Твітары з'яўляецца ўсё больш анекдотаў і гісторый пра людзей, якія пакінулі гэтую прафесію таму, што не змаглі (не захацелі) і далей мірыцца з варожасцю і нядобразычлівасцю ў адносінах да старонніх. Нават Лінус Торвальдс за гады сваёй варожасці і крытыкі ў адрас іншых Linux-распрацоўнікаў - гэта прывяло да дыскусіі аб эфектыўнасці такога падыходу.
Хтосьці да гэтага часу адстойвае права Лінуса быць вельмі крытычным - тыя, хто павінен шмат ведаць аб перавагах і недахопах «таксічнага негатыву». Так, карэктнасць вельмі важная (нават фундаментальная), але калі рэзюмаваць прычыны, па якіх многія з нас дазваляюць выказванню негатыўнага меркавання ператварыцца ў «таксічнасць», то гэтыя прычыны выглядаюць патэрналісцкімі ці падлеткавымі: «яны заслугоўваюць гэта, таму што ідыёты», «ён павінен быць упэўнены, што яны гэтага не паўтораць», «калі б яны так не зрабілі, яму не прыйшлося б на іх гарлапаніць», і гэтак далей. Прыкладам таго, які ўплыў эмацыйныя рэакцыі лідэра аказваюць на супольнасць праграмістаў, з'яўляецца абрэвіятура MINASWAN у супольнасці Ruby - "Matz is nice so we are nice" (Мац [стваральнік мовы] добры, значыць і мы добрыя).
Я прымеціў, што шматлікія палкія прыхільнікі падыходу «забі дурня» часта вельмі клапоцяцца аб якасці і карэктнасці кода, ідэнтыфікуючы сябе са сваёй працай. Нажаль, яны часта блытаюць цвёрдасць з калянасцю. Недахоп такой пазіцыі вынікае з простага чалавечага, але непрадуктыўнага жадання адчуць сваю перавагу над іншымі. Людзі, якія апускаюцца ў гэтае жаданне, захрасаюць на шляхі цемры.
Свет праграмавання хутка расце і ўпіраецца ў межы свайго кантэйнера - свету непраграмавання (ці гэта свет праграмавання з'яўляецца кантэйнерам для свету непраграмавання? добрае пытанне).
Па меры таго, як наша індустрыя пашыраецца нарастальнымі тэмпамі і праграмаванне становіцца ўсё даступней, дыстанцыя паміж "тэхнарамі" і "нармальнымі" хутка скарачаецца. Свет праграмавання ўсё больш падвяргаецца ўздзеянню міжасобасных зносін людзей, якія выраслі ў ізаляванай культуры «батанаў» пачатку тэхнабуму, і менавіта яны сфарміруюць новы свет праграмавання. І нягледзячы на якія-небудзь аргументы адносна сацыяльнай сферы ці пакаленняў, эфектыўнасць у імя капіталізму выявіцца ў культуры кампаній і падыходах да найму: лепшыя кампаніі проста не будуць наймаць тых, хто не зможа ўзаемадзейнічаць з іншымі нейтральна, не кажучы ўжо пра добрыя адносіны.
Што я даведаўся аб негатыве
Калі вы дазваляеце лішку негатыву кіраваць вашым розумам і зносінамі з людзьмі, ператвараючыся ў «таксічнасць», тое гэта небяспечна для прадуктовых каманд і дорага для бізнэсу. Я бачыў незлічоную колькасць праектаў (і чуў пра такія), якія разваліліся і былі цалкам пераробленыя з вялікімі выдаткамі, таму што адзін з распрацоўшчыкаў, якому давяралі, тачыў зуб на тэхналогію, іншага распрацоўніка ці ўвогуле адзіны файл, абраны для прадстаўлення якасці ўсёй кодавай базы. .
Таксама негатыў дэмаралізуе і разбурае адносіны. Я ніколі не забудуся, як калега лаяў мяне за тое, што я паклаў CSS не ў той файл, мяне гэта знервавала і не давала сабрацца з думкамі некалькі дзён. І ў будучыні я наўрад ці дазволю падобнаму чалавеку апынуцца паблізу ад адной з маіх каманд (зрэшты, хто ведае, людзі мяняюцца).
Нарэшце, негатыў .
Мне падаецца, так павінен выглядаць майстар-клас па ўсмешках.
Вядома, гэта не аргумент у карысць таго, каб прамяніцца шчасцем, устаўляць дзесяць мільярдаў смайлаў у кожны pull request ці адправіцца на майстар-клас па ўсмешках (не, ну калі вы менавіта гэтага жадаеце, то не пытанне). Негатыў з'яўляецца вельмі важнай часткай праграмавання (і чалавечага жыцця), сігналізуючы аб якасці, дазваляючы выказаць пачуцці і паспачаваць людзям-братам. Негатыў сведчыць аб праніклівасці і разважлівасці, аб глыбіні праблемы. Я часта заўважаю, што распрацоўшчык дасягнуў новага ўзроўню, калі ён пачынае выказваць недавер у тым, у чым раней быў баязлівы і няўпэўнены. Сваімі меркаваннямі людзі дэманструюць разважлівасць і ўпэўненасць. Нельга адкінуць выраз негатыву, гэта было б па-оруэлаўску.
Аднак негатыў трэба дазаваць і ўраўнаважваць іншымі важнымі чалавечымі якасцямі: спачуваннем, цярпеннем, разуменнем і гумарам. Заўсёды можна сказаць чалавеку, што ён аблажаўся, без крыку і лаянкі. Не трэба недаацэньваць такі падыход: калі табе зусім без эмоцый кажуць, што ты сур'ёзна накасячыў, гэта сапраўды палохае.
У той раз, некалькі гадоў таму, са мной пагаварыў СEO. Мы абмеркавалі бягучае палажэнне праекта, затым ён спытаў, як я сябе адчуваю. Я адказаў, што ўсё нармальна, праект рухаецца, паціху працуем, мабыць, я сёе-тое выпусціў і трэба перагледзець. Ён сказаў, што чуў, як я дзяліўся больш песімістычнымі меркаваннямі з калегамі ў офісе, і што іншыя таксама гэта заўважылі. Ён растлумачыў, што калі ў мяне ёсць сумневы, я магу ў поўнай меры выказаць іх кіраўніцтву, але не "спускаць уніз". Будучы вядучым інжынерам я павінен памятаць, як мае словы дзейнічаюць на іншых, таму што я валодаю вялікім уплывам, нават калі таго не ўсведамляю. І ўсё гэта ён сказаў мне вельмі па-добраму, і ў завяршэнне сказаў, што калі я сапраўды адчуваю такія пачуцці, то мне, верагодна, трэба абдумаць, чаго ж я жадаю для сябе і сваёй кар'еры. Гэта была неверагодна мяккая гутарка ў стылі "вазьмі сябе ў рукі або вымятайся". Я падзякаваў яму за інфармацыю пра тое, як маё стаўленне, якое змянілася за паўгода, незаўважна для мяне ўплывае на іншых.
Гэта быў прыклад цудоўнага, эфектыўнага кіравання і сілы мяккага падыходу. Я зразумеў, што мне толькі здавалася, быццам я цалкам веру ў кампанію і яе здольнасць дасягнуць мэт, а ў рэальнасці казаў і меў зносіны з іншымі зусім інакш. Таксама я зразумеў, што нават адчуваючы скептыцызм у дачыненні да праекту, над якім я працаваў, мне не трэба было паказваць сваё стаўленне калегам і распаўсюджваць песімізм нібы заразу, памяншаючы нашы шанцы на поспех. Замест гэтага я мог агрэсіўна трансьляваць рэальнае становішча свайму кіраўніцтву. І калі б я адчуў, што яны мяне не слухаюць, то мог бы выказаць сваю нязгоду сыходам з кампаніі.
Я атрымаў новую магчымасць, калі заняў пасаду кіраўніка па адзнацы персанала. Будучы былым галоўным інжынерам, я вельмі ўважліва сачу за выразам свайго меркавання аб нашым (пастаянна які паляпшаецца) легасі-кодзе. Каб ухваліць змену, трэба ўяўляць бягучую сітуацыю, але вы ні да чаго не прыйдзеце, калі загразнеце ў стогнах, нападках ці чымсьці падобным. У канчатковым рахунку, я тут для таго, каб выканаць задачу, і не павінен скардзіцца на код, каб зразумець яго, ацаніць ці выправіць.
Фактычна, чым больш я стрымліваю сваю эмацыйную рэакцыю на код, тым лепш разумею, якім ён мог бы стаць, і тым менш замяшанні адчуваю. Калі я лаяўся стрымана («тут павінны быць магчымасці для далейшых паляпшэнняў»), то тым самым цешыў сябе і іншых і не прымаў сітуацыю занадта блізка да сэрца. Я ўсвядоміў, што магу стымуляваць і паніжаць негатыў у іншых, быўшы ідэальна (раздражняльна?) разважлівым («вы маеце рацыю, гэты код даволі дрэнны, але мы яго палепшым»). Я рады таму, наколькі далёка магу прайсці па шляху дзэна.
Па сутнасці, я ўвесь час вучуся і перавучваю важны ўрок: жыццё занадта кароткае, каб пастаянна злавацца і пакутаваць.
Крыніца: habr.com