Пераадольваем тэхнічны доўг

Апублікавана

by — Posted in гік-лікбез, нашы прадукты, праекты, праца каманды, прылады і вэбсэрвісы

Што варта ведаць грамадскім арганізацыям і распрацоўшчыкам пра тэхнічны доўг сваёй лічбавай інфраструктуры

У нейкі момант каманда пачынае буксаваць і працэсы распрацоўкі затарможваюцца або наогул спыняюцця. Што здарылася? З’явіўся тэхнічны доўг.

Што такое “тэхнічны доўг”

У дзейнасці Лічбавай майстэрні (Фаланстэра) накопліваўся такі аб’ём працы ў кодзе (і не толькі), дзе прыходзіцца шмат часу прысвячаць на пераробліванне зробленага, каб рухацца далей. Феномен, які паказвае “непатрэбную” працу, якую прыйдзецца камандзе зрабіць, называецца Тэхнічны доўг.

Тэхнічны доўг характаразуецца не толькі тым, што (1) неабходна выдзеліць сілы і час на выпраўленне і аптымізацыю (рэфактарынг) зробленага, але і таго, што (2) называецца выдаткі часу на тое, што наогул рабіць не трэба было.

У якіх выпадках ён узнікае

У Вікіпедыі або сайце Рэфактарынг.гуру прапанаваны даволі шырокі спіс прычынаў узнікнення тэхнічнага доўга. Я пералічу, тое з чым мы сутыкнуліся:

  1. Недахоп ведаў. Гэта пытанне, з якім мы сутыкнуліся на ітэрацыі Doika 1.2. Такі доўг бачны па коду. Напрыклад, захаванне пераменных (шляхі да файлаў) у саміх метадах класаў, або яўная задача лічбавых метрык унутры вылічаючага алгарытма.
  2. Адсутнасць тэхнічных стандартаў. Напрыклад, калі код пішуць розным стылем, або наогул без стыля, праз нейкі час такі код складана зразумець. Прыклад – сайт Лічбавай майстэрні, дзе частка html-коду ў нас выканана розмымі падыходамі (БАМ + іншыя), а стылі аформлены, як звычайным css, так і sass.
  3. Паралельная распрацоўка. Узнікае калі распрацоўшчыкі імкнуцца ўнесці адразу шмат зменаў. Такая сітуацыя можа выклікаць цяжкаць знайсці праблему ў кодзе не толькі іншым удзельнікам праекта, але і самаму аўтару. У нас такое перыядычна здараецца ў Doika.
  4. Недахоп дакументацыі. Гэты момант пагаршае ўваход новых людзей у праект, яны выдаткоўваюць шмат часу і толькі з-за кепска апісанай дакументацыі. Або пачынаюць кодзіць у сваім стылі таму што не ведаюць, дзе дакументацыя ляжыць. Гэта наш сённяшні выклік у Doika 1.3.
  5. Гэта жорсткая звязка кампанентаў сістэмы. Код і класы былі заточаны на вельмі вузкую задачу і код ніяк не ўлічваў патэнцыйную маштабуемасць. Прыклад Doika пры пераходзе з ітэрацыі 1.2 да ітэрацыі 1.3. Без рэфактарынга гэты пераход стаў наогул немагчымы.

Вядома, пералічаныя прычыны не вычырпваюць усе паставы ўзнікнення тэхнічнага доўга. Існуюць яшчэ гарачыя апошнія змены, недахоп разумення працэсаў распрацоўкі, неталенавітае тэхнічнае лідэрства, адсутнасць аўтатэставання, адсутнасць першаснага дызайну архітэктуры, ціск дэдлайнаў, недахоп супрацы распрацоўшчыкаў.

У прынцыпе ўсе гэтыя прычыны лёгка пераносяцца на нетэхнічныя задачы. Напрыклад, “паралельная праца”, “недахоп дакументацыі”, “адсутнасць стандартаў”, “недахоп ведаў”, “вузкая спецыялізацыя”, “неталенавітае лідэрства”, “адсутнасць пілатавання”, “недахоп супрацы ўдзельнікаў праекта” і інш.

Якія наступствы тэхнічнага доўгу

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

Якія яшчэ эфекты я назіраў:

  • Разбор чужой працы, як правіла, часам складаная і нецікавая задача. Часам узнікае думка, зрабіць усё нанова, а гэта вяртанне напачатак па сутнасці. Гэта асабліва балючы момант для таго, хто пісаў першы код (напрыклад, Doika версіі 1.2).
  • Паўторнае выкананне задачы, або задача, якая не стварае нешта новае дэматывуе каманду. Гэта бачна па пракрасцінацыі, якая свірэпствавала ў другой палове года.
  • Часам больш цікавыя задачы могуць адцягваць увагу. Напрыклад, у Doika стварэнне ўсталёўшчыка адцягнула каманду ад рэфактранга версіі 1.2.

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

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

Рэбут

Рэбут (Reboot) – гэта назва праекта мадэрнізацыі сайта Фаланстэра, мэта якога адаптаваць выгляд, больш зручны для нас і наведвальнікаў, і прывесці кантэнт да актуальнага стану.

Яго мы пачалі ў пачатку 2018 года. Але з-за несабранасці каманды і ўзросшых прыярытэтаў іншых задач прыйшлося напачатку красавіка адкласці. З кастрычніка 2018 года мы ўзнавілі гэта пачынанне. Зараз мы спрабуем яго давесці да розума.

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

Па-другое (недахоп ведаў), з-за таго, што мы працуем з пачынаючымі распрацоўшчыкамі ўзнікла праца над задачай без разумення архітэктуры. Тут маецца на ўвазе спецыфічная вёрстка пад рухавік сайта. Такім чынам, каманда правяла каля 2х месяцаў, ствараючы старонкі, якія з вялікай верагоднасцю забяруць у іх яшчэ вялікі кавалак часу пры адаптацыі на рухавік Drupal.

Трэці не менш значны момант (недахоп супрацы распрацоўшчыкаў і дакументацыі) заключаўся ў тым, што каманда патраціла вялікі кавалак часу на ўсталёўку асяродку, з-за двух вядучых фактараў. Першы фактар – гэта не было апісання як устанаўліваць асяродак распрацоўкі, які ў спалучэнні з недахопам ведаў заняў 2 месяцы часу каманды. Другая не менш значная прычына – гэта тое, што каманда вельмі слаба камунікавала па задачы, і нават пры вырашэнні адным чалавекам усталёўкі, іншыя змагаліся з такім жа выклікам ледзь не самастойна, або запытваючы маёй дапамогі ў скранім выпадку, але не ў іншых калег па цэху.

Doika

Doika – гэта дзейнасць каманды Фаланстэра па стварэнню і інтэграцыі ў жыцці беларускіх грамадскіх арганізацый новага спосабу прыёму ахвяраванняў на сваіх сайтах праз банкаўскія карткі.

Я апісваў, як развіваўся праект Doika да лета 2018. Але нашы асноўныя выпрабаванні ляглі на пачатак восені, калі мы вырашылі рэалізаваць некалькі новых фунцый (напрыклад, рэкурэнтныя плацяжы) і зрабіць рэфактарынг версіі 1.2. З гэтага часу пачало прыходзіць глыбокае разуменне, што ёсць тэхнічны доўг. Тым больш адбываліся падзеі, якія вельмі яскрава дэманстравалі камандзе гэту з’яву.

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

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

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

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

Зараз буду нумараваць этапы, на якіх інкрыментальна накопліваўся тэхнічны доўг.

  1. Фронтэнд распрацоўшчык вырашае дадаць фронтэнд адмінкі і кліентскай часткі адным “цяжкім” камітам на сотні радкоў. Дадаюцца кампаненты якіх наогул не патрэбна дадаваць, або якія узяты з бэклога праекта для наступных ітэрацый.
  2. Я падымаю пытанне, як нам працягваць распрацоўку ў такім выпадку. Каманда пачынае абмяркоўваць, што такое наогул опенсорс і працэс распрацоўкі.
  3. Далей, каманда траціць цэлую сустрэчу, каб абгрунтаваць новы падыход да сінхраніхацыі дадзеных у праекце ў сувязі і замацоўвае яго правіламі.
  4. Узнікае пытанне тэствання, і дызайнерка пагаджаецца, што неабходна прапісаць у ішшус на гітхабе крытэры для тэставання.
  5. Праз тыдзень пры размове з фронтэнд распрацоўшчыкам, вырашаем прыбарць непатрэбныя функцыі.
  6. Яшчэ праз тыдзень да каманды далучаюцца новыя людзі і пачынаюць тэставаць.
  7. Бліжэй да новага (2019) года мы прыходзім да высновы, што вядзенне версійнасці знешняга выгляду, патрабуе зашмат чалавечых выдаткаў і наогул мала эфектыўна з-за гэтага.
  8. Фронтэндзер запавольвае адкат візуальных кампанентаў, а тэсціроўшыца тым часам робіць тэсты, як на фічы, якіх не павінна быць наогул.
  9. Узнікае дыскусія, як арганізаваць праект для таго, каб увесь створаны вэрхал уладкаваць і зрабіць зразумелым для новых людзей і распрацоўшчыкаў.
  10. Паралельна гэтай складанасці адсутнасць дакументыцыі па устаноўцы блакуе іншых людзей далучыцца да распрацоўкі…

На схеме я адлюстраваў вышэй апісаныя падзеі. Вядома у гадзінах не пралічваючы час, але можна сказаць што кожны крок займаў 5-7 дзён.

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

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

Другая. Паралельная распрацоўка. Гэта жаданне зрабіць адразу шмат зменаў распрацоўшчыкамі ў тым ліку адступленне ад дамоўленай дакументацыі. Дададзены быў адразу шэраг старонак пасутнасці 90% адмінкі і кліентскай часткі.

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

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

Мы канешне сустракаліся штотыдзень, але гэтага было недастаткова, каб вырашыць скапіўшыйся вузел задач. Як заўважаў вышэй, заўсёды больш цікавыя і жаданыя задачы зацягвалі ўдзельнікаў і забіралі час сустрэч. Сустрэчы звычайна працягваліся каля 2-3 гадзін, але ключавыя людзі там прысутнічалі каля 1 – 1,5 гадзін. Гэта вельмі малы перыяд часу для вырашэння складанай каманднай задачы, а на іншых пляцоўках абмеркаванне амаль адсутнічала.

Як жыць далей?

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

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

Фота: Юля Сакалоўская, Света Ермаковіч, скрыны ўзяты з праектных дошак.

Дзяліся:


ryzomych
рухавік і заснавальнік Фаланстэра. Цікаўлюся сацыятэхнікай, лічбавымі правамі і роварамі.

6 думак пра “Пераадольваем тэхнічны доўг

  1. Вельмі круты і моцны аналіз! Брава!
    Нарэшце я зразумела, што адбывалася ўсе гэтыя месяцы.. А тое толькі павярхозна ўсведамляла.

    П.С. Ты падпісаў Насцю як аўтарку фоткі, але на апошняй яна сама есць )))

    1. дзякуй за ацэнку. найбольш складанае у гэтым працэсе падлік часу. асабліва калі прыкіпаеш да нейкага звыклага спосабу і лічыш што інвестыцыі часу апраданы таму што большасці каманды і камандзе, часам складана прызнаць свае памылкі.

      па фоткам выправіў. значыць твае і Юлі

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

    Дзякуй за вялікі аналіз яшчэ раз!

    1. Вітаю,

      Можна твае словы скапірую у наш канал па doika? =) залатыя

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

      1. Канешне капіруй) Кожная інфа як па мне карысна і мае сваё месца, так что сустрэча на 100 адсоткаў была карыснай. Рабіць больш сустэч, адзначаць і разам працаваць над цікавымі тэмамі.

        1. ага, дзякуй. канешне буду запрашаць на Doika сустрэчы.

          дарэчы, заўжыў твой друпал сшытак. крута!

Пакінуць адказ

Ваш адрас электроннай пошты не будзе апублікаваны. Неабходныя палі пазначаны як *