«Праектаваць нельга пісаць код» — пастаў коску правільна

Восьмае кола пекла

Падчас свайго доўгага працоўнага шляху даводзілася назіраць безліч розных падыходаў да арганізацыі працы: і зручных, і хаатычных, і правераных, і такіх, зь якіх быццам пісалі акадэмічнае азначэньне антыпатэрнаў. Але лідарам у гэтым рэйтынгу, на маю думку, будзе той, празь які праходзіць літаральна кожны распрацоўшчык у пачатку свайго шляху — асабліва калі працуе над праектамі адзін і вучыцца ўсяму «інтуітыўна». На першы погляд гэтая пасьлядоўнасьць можа падавацца бясшкоднай. Але д'ябал, як вядома, у дробязях.

Выглядае гэта не надта мудрагеліста. Да распрацоўшчыка паступае адносна аб'ёмістая задача, апісаньне гучыць прыкладна як «зрабіць каб было добра і працавала» — і пара словаў аб характары працы. Бонусам звычайна ідзе «трэба каб было ўчора», «ды што там складанага?» і «а чаму так доўга?». Тут жа ў лоб патрабуецца эстымэйт — і каб ён быў у межах аптымістычнай адзнакі, але безь страты якасьці, і каб да працы прыступіць у тую ж хвіліну, бо ўсё тэрмінова-тэрмінова. А далей — па накатанай: часу мала, трэба сьпяшацца. З чаго пачаць? Правільна — пачаць пісаць код. Усё, чарговае кола пекла адчынена і гатовае прымаць наведвальнікаў.

Што далей? А далей — мітусьлівае праграмаваньне, потым перапісваньне напісанага, бо нешта непрадугледжана было, потым раптоўная зьмена патрабаваньняў ад бізнэсу (зь чаго б раптам?). Праект пачынае выглядаць настолькі агідна, што сам распрацоўшчык губляе запал — але цешыць сябе думкай: «гэта МВП, потым адрэфактару». Гэтага «потым» не здарыцца ніколі, бо задачы працягваюць сыпацца адна за адной, няма калі вачэй адвесьці — і ўсё глыбей закопваешся пад нагрувашчваньні наступстваў няўдалых рашэньняў. Кволыя спробы выратаваньня называюцца «рэфактарынгам», але па факце гэта проста перапісваньне з нуля асабліва непрыгожых кавалкаў.

Пасьля? Пасьля праект альбо са скрыпам рэлізіцца, альбо проста ціхенька памірае. А ўжо рэлізнуты праект распрацоўшчык абыходзіць як мага далей і сапартаваць яго зусім не імкнецца. Аднак кажа: «атрымалася не вельмі, але вось наступным разам я напішу куды лепшы код і ўсё зробіцца лепей, такога болей не паўторыцца!» Прыходзіць той наступны раз... І разам зь ім «трэба было ўчора» і «чаму так доўга?». Кола замкнулася.

Чаму не выдаюць інструкцыю да жыцьця?

Як так адбываецца? Напэўна ж не ад жаданьня распрацоўшчыка раз за разам прайсьціся па тых жа граблях. Я б хутчэй назваў гэта цяжарам абставінаў.

Не кожны трапляе ва ўтульны асяродак, дзе вучаць правільным падыходам і цярпліва тлумачаць, што і для чаго будзе карысна. Даволі часта — і мой выпадак у тым ліку — пачынаючы проста апынаецца пасярод агрэсіўнай пустэчы і мусіць неяк зь нечага сабраць механізм, на якім можна перасоўвацца і выжываць. Без інструкцыі і без падказак. Паасобныя дэталі прыкладаюцца адна да адной, нейкае спалучэньне раптам спрацоўвае — запамінаеш, робіш яшчэ такога кшталту. І вось гэтая іржавая, крывая і касая штука пачынае неяк ехаць. Добра ці не — сам не ацэніш, праўдзівую зьнешнюю адзнаку таксама не так проста атрымаць. Але ж едзе! А ўсё, што не патрапіла ў гэты функцыянуючы «арганізм», аўтаматычна маркіруецца як непатрэбнае.

Калі ты зь юнацтва апантаны праграмаваньнем, уся энэргія ідзе ў бок кода: ён назапашваецца, прыкручваецца, прыклейваецца на сінюю ізастужку да ўласнага досьведу. І як вынік — толькі ў ім вышуквацца шляхі да вырашэньня праблем: каб яшчэ ідэальней пісаць код, каб яшчэ дасканалей расстаўляць дужкі ў патрэбных месцах, магчыма нават дойдзе да ўжываньня патэрнаў праектаваньня. Але калі ў канструкцыі недастае іньшых важных дэталяў — зварочваць гэтая машына будзе кожны раз не туды.

Якія дэталі трапляюць на сьметніцу раз за разам? Праектаваньне архітэктуры і дакумэнтацыя, лагірваньне і клопат аб тых, хто прыйдзе потым (нават калі гэта будзеш ты сам празь паўгады) — тое, што ў сьціслым графіку бясконцых дэдлайнаў адкідваецца як перашкода ці марная страта часу. Аргументацыя простая, як лапаць: тут і на напісаньне кода часу няма, якое ўжо там...

Аднак тут прыходзіць у галаву аналёгія. Калі спраецыраваць усё гэта на аўтамабільную вытворчасьць, атрымаецца прыкладна так: «нам патрэбна новая мадэль аўтамабілю, і як мага хутчэй!» — і нейкі абстрактны вытворца бярэ ў рукі напільнік і пачынае выпільваць дэталі зь металу ці таго, што патрапілася пад руку, спадзеючыся, што ў нейкі момант плёнам такой працы стане патрабаваная мадэль. Гучыць дзіка? Дык чаму пры распрацоўцы складаных інфармацыйных сістэм гэта лічыцца нармальным і нават рацыянальным?

Кагнітыўныя пасткі і пад чым яны хаваюцца

З майго пункту гледжаньня код — гэта проста інструмэнт ці матэрыял. Спосабы яго арганізацыі ведаць карысна, але гэта як уменьне трымаць малаток і цьвік: раз навучыўся — і проста карыстаешся. Часам зьяўляюцца больш дасканалыя інструмэнты, можна паглядаць, хто прыдумаў як надзейней трымаць цьвік, каб не ляснуць сабе па пальцу. Але каб пабудаваць будынак, аднаго ўменьня лупіць малатком недастаткова. Трэба ведаць, якія матэрыялы лепш злучаюцца паміж сабой, колькі вытрымаюць вагі, дзе ўжываецца бетон, а дзе шкло. Спраектаваць тое, чаго яшчэ не існуе, прадумаць якая будзе выніковая архітэктура, завезьці на будоўлю ўсе патрэбныя матэрыялы. Каб узяўшы ў рукі першую цагліну не мітусіцца па пляцоўцы не ведаючы куды яна павінна легчы, а весьці будоўлю рацыянальна і паэтапна.

Па маім назіраньні пры абдуманым разьмеркаваньні часу само напісаньне коду складае не болей за 30% ад усяго аб'ёму працы над праектам, а то і меньш. Калі ёсьць дастатковая кваліфікацыя — гэтую частку можна ў нейкай ступені аўтаматызаваць (але калі ёсьць кваліфікацыя — вайбкодэры, гэта не пра вас). І брацца за гэта варта толькі ў самы апошні момант, калі ўжо дастаткова дэталізавана ўяўляеш, што атрымаецца — тады напісаньне кода становіцца амаль мэханічным, і якраз у такім выпадку ён выходзіць простым і чыстым. Можна запярэчыць: «атрымліваецца, трэба яшчэ дадаткова ў два разы больш часу на нейкае там праектаваньне звыш таго, што даецца на распрацоўку!» Але залежнасьць тут не лінейная. Напісаньне кода па ўжо прапрацаваных спэцыфікацыях займае ў выніку ў некалькі разоў менш часу. А калі дадаць сюды час, змарнаваны на перапісваньні, на прадзіраньне скрозь няўдалыя спробы і на падтрымку, якая становіцца бы крыж, які ніхто не хоча несьці, — суадносіны атрымаюцца зусім іншыя. Спачатку доўга думаем — потым хутка пішам. А «у мяне няма часу думаць — трэба пісаць код» — гэта: спачатку хутка пішам, потым хутка перапісваем, потым яшчэ хутчэй перапісваем перапісанае, потым...

Справа тут не ў дысцыпліне ці кваліфікацыі. Ёсьць канкрэтныя псыхалягічныя механізмы, якія штурхаюць у бок «код адразу» — і іх карысна ведаць па імёнах.

Памылка планаваньня. Мы сыстэматычна недаацэньваем час на задачы і пераацэньваем сваю здольнасьць выкарыстаць яго прадуктыўна. «Напішу хутка, потым дапрацую» — гэта не самаўпэўненасьць, гэта прадказальнае кагнітыўнае скажэньне, даасьледаванае і вядомае як planning fallacy. Лячэньне простае: да пачатку працы выпісаць усе дапушчэньні, на якіх трымаецца план. Калі іх больш за тры — архітэктура яшчэ не прапрацаваная.

Зрух да дзеяньня. Мозг успрымае відавочнае дзеяньне — пісаць код — як прагрэс, а абдумваньне — як бяздзейнасьць. Асабліва ва ўмовах дэдлайну. Гэта эвалюцыйны механізм: хто марудзіць, той не есьць. Але ў праграмаваньні марудзіць на этапе праектаваньня — гэта інвестыцыя, не слабасьць. Лячэньне: зрабіць «думаньне» відавочным артэфактам. Дыяграма, дакумэнт, схема — гэта прадукт, не пусты час.

Ілюзія разуменьня. Нам здаецца, што мы разумеем задачу, бо можам апісаць яе ў агульных рысах. Але пакуль не знайшліся памежныя выпадкі, не выпісаліся ўсе залежнасьці, не задаліся пытаньнем «а што калі...» — гэта ілюзія. Распрацоўшчык думае: «зразумела, трэба зрабіць Х» — але Х гэта слова, а не рашэньне. Просты тэст: ці магу я ўжо намаляваць sequence diagram? Калі не — задача яшчэ не зразуметая.

Хібнасьць патанулых выдаткаў — у адваротны бок. Калі ты пачаў пісаць код, становіцца цяжэй прызнаць, што архітэктура памылковая. Ужо напісаны код цісне: «я ўжо столькі зрабіў, не выкідваць жа». Але менавіта гэты код і варта кінуць (часьцей за ўсё) — ён збудаваны на памылковых здагадках, і чым раней гэта адбудзецца, тым танней. Лячэньне: успрымаць код, напісаны да фазы праектаваньня, як «нататкі для сябе», а не як актыў.

Самаўпэўненасьць. «Я ўжо рабіў нешта падобнае» — і ў памяці ўсплываюць толькі паспяховыя выпадкі. Памылкі мінулых праектаў не ўспрымаюцца як узор, які паўторыцца. Лячэньне: перад пачаткам новага праекту — пяць хвілін на пытаньне: «дзе ў апошні раз мне прыйшлося перапісваць, і чаму?»

У нас быў план...

Альбо мы хочам, каб ён быў. Што ж рабіць? Самае першае — задаваць пытаньні. Калі здаецца, што ты ўжо зразумеў як павінна працаваць сістэма, пра якую толькі што пачуў — табе здаецца. Пазнаваньне агульных рысаў зьбівае зь панталыку і загоньвае ў вугал, калі даходзіш да рэалізацыі дэталяў. І там ужо толькі гадаць, што мелася на ўвазе.

Ніякіх эстымэйтаў — пакуль не відаць хаця б буйнымі мазкамі карты шляху цалкам. Надзіва часта аказваецца, што той, хто ставіць задачу, сам да канца не разумее, як гэты функцыянал павінен выглядаць і працаваць, хто і для чаго будзе зь ім узаемадзейнічаць. Фармулёўка «ну зрабі прыкладна гэтак жа, як вунь там» — і потым акажацца, што зроблена не тое і не так.

Каб такога не здарылася — трэба ўзяць час на фармуляваньне патрэбных пытаньняў, на ўдакладненьне, ці разумеюць усе аднолькава, пра які функцыянал гаворка і для чаго ён патрэбны. Вусныя дамоўленасьці зь часам скажаюцца, пошук сярод паведамленьняў чатаў — справа няўдзячная. Усё гэта фіксаваць дакумэнтальна.

Напісаць тэкстам і намаляваць дыяграму — гэта, па-першае, застанецца як дакумэнтацыя, а па-другое, дазволіць разгледзець тое, што робіш, пад рознымі вугламі і заўважыць хібы, якія маглі застацца па-за абмеркаваньнем. Графічнае адлюстраваньне часам працуе лепш за тэкст, навучыцца карыстацца гэтым інструмэнтам нескладана — карысьці бясконца.

Сабраць усё ў HLD — быццам стратэгічную мапу свайго войску, якое выступае на шлях перамогі над пастаўленай задачай. Калі на гэтай мапе ёсьць белыя плямы альбо стрэлкі, якія вядуць ніадкуль нікуды — праца над ёй няскончаная. Аднак над тымі часткамі, у якіх можна быць упэўненым, можна ўжо весьці распрацоўку далей. І наступным крокам будзе SDD: калі мы ведаем, што гэта за кампанэнт, якая яго адказнасьць і ў якіх выпадках ён будзе выкарыстоўвацца — тут ужо можна дэталізаваць да дыяграм паслядоўнасьцяў. І на гэтым этапе таксама выявіцца, чаго не хапае.

Калі падыходзіць да высьвятленьня дэталяў і фармуляваньня пытаньняў досыць адказна, можна мінімізаваць раптоўныя зьмены курсу ў бізнэс-логіцы — якія якраз і адбываюцца часьцей з-за таго, што нешта было непрадугледжана са старту. Усё гэта на першы погляд можа падавацца складаным і марудным. Але варта ўспомніць, як код пісаўся ў пачатку шляху — і параўнаць, як пішацца цяпер. Гэта трэніруецца і разьвіваецца.

Праект зь гісторыяй

Асобны выпадак — праект, які «неяк рабіўся, зараз нейк працуе, сапорту шмат не трэба, ну бываюць зрэдку задачы». Па маім назіраньні — задач «зрэдку» набягае за гады на адчувальны прамежак часу. І кожная такая задача робіцца нібыта зь нуля: зь чыстага аркуша разьбіраешся ў праекце, успамінаеш як там і што працуе, якія залежнасьці, што чапаць, а каля чаго лепей нават і не дыхаць. Мінорны фікс ператвараецца кожны раз у невялікую прыгоду — і не заўсёды зь шчасьлівым канцом. А калі сыходзіць распрацоўшчык, які зьяўляецца адзіным носьбітам ведаў па праекце — зусім гамон.

А варта было б у нейкі момант перастаць адразу кідацца ў код і пачаць — хаця б у межах адной задачы — усё прадумваць зь фіксаваньнем ходу думак у апісаньне і дыяграмы. Зь часам большая частка функцыяналу была б апісаная, і далейшая распрацоўка і падтрымка маглі б абапірацца на ўжо пройдзеныя крокі — паступова скарачаючы і час на рэалізацыю, і белыя плямы на мапе.

А ці не шмат я хачу?

Усё гэта добра перакладаецца з тэорыі на практыку ў вялікіх камандах, дзе распрацоўшчык займаецца тым, чым умее лепш за ўсё — распрацоўвае. А архітэктурай займаюцца іншыя людзі. І прадуктам ёсьць каму заняцца. А ці падыйдзе гэта таму, хто і швец, і жнец, і на дудзе грэц у адной асобе?

Я лічу — якраз для яго гэта выратаваньне. Каб разарваць гэтае кола і не абыходзіць бокам свае старыя праекты. Гэта галоўная інвестыцыя ў доўгае жыцьцё прадукту і яго стабільнае функцыянаваньне — каб потым не было падставы казаць «ну вось у наступны раз зраблю нармальна».

Не абавязкова спрабаваць дадаць сабе адразу ўсе інструмэнты. Дастаткова пачаць зь невялікага кроку — напрыклад, вылучаць межы кампанэнтаў і дакумэнтаваць гэта. Ужо адно гэта дазволіць бачыць, як можна падзяліць функцыянал на часткі, якія будуць адпавядаць SOLID. Далей — паспрабаваць візуалізаваць сувязі між кампанэнтамі. Тут ужо відаць, дзе пустыя месцы і што варта абмяркоўваць дадаткова. А код? Код і штучны інтэлект хутка піша. Не спаборнічаць жа зь ім у хуткасьці 🤣

Да новых сустрэч. Каб у вашым самаходзе жыцьця ўсе неабходныя дэталі былі на сваіх месцах.

P.S. Усе супадзеньні не супадзеньні, калі хто пазнаў сябе - то гэта ён і ёсьць.