Прынцыпы распрацоўкі

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

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

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

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

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

Карыстальніцкія інтэрфейсы нясуць тую ж адказнасць. Dashboard, які патрабуе навучання для разумення — гэта dashboard, які будзе праігнараваны ў крытычны момант. Мы праектуем для аператара, які глядзіць на гэтыя лічбы ў два гадзіны ночы, а не для дэманстрацыйнага асяроддзя.

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

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

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

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

Мы выкарыстоўваем CI/CD, сістэмы тыпаў і лінтары не таму, што гэта модна, а таму што яны робяць наступную змену танней. Мы пішам тэсты на тым узроўні, дзе іх танней падтрымліваць і дзе яны з найбольшай верагоднасцю выявяць рэальныя рэгрэсіі. Мы прафілюем перад аптымізацыяй і аптымізуем перад перапісваннем.

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

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

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

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

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

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

Калі праект завяршаецца, назапашаныя намі веды мы лічым актывам кліента, а не нашым. Дакументацыя, архітэктурныя схемы і runbook — частка кожнай пастаўкі.