Повеќето тимови велат дека сакаат сопственост. Она што често го мислат е дека некој треба да се вклучи кога тикетот е нејасен, изданието не успее или клиентот ќе го пронајде граничниот случај што никој не го планирал.

Вистинската сопственост почнува порано. Таа е навика да се проектира за следното прашање пред тоа да стане прекин. Тоа е антиципативна архитектура: градење производи, системи и тимски практики што можат да набљудуваат што се случува, безбедно да реагираат и да се подобруваат без да бараат херојство.

Ова не е повик да се предвиди секое идно барање. Таквиот пристап создава прекумерно инженерски платформи и бавна испорака. Целта е попрактична: да се направат важните непознати видливи, веројатните промени прифатливи и на луѓето најблиски до работата да им се даде доволно контекст за да постапуваат добро.

Архитектурата е производ на одлуки, а не на дијаграми

Архитектурниот дијаграм може да опише услуги, бази на податоци, редици и интеграции. Сам по себе не може да покаже дали производот е способен да учи. Тоа зависи од одлуките вградени во системот: што запишува, како се справува со неуспех, каде се наоѓаат неговите правила и колку лесно тимот може да тестира претпоставка.

Разгледајте тек на наплата. Тимот може да го третира како фиксна низа што или успева или враќа грешка. Или може да го третира како површина за учење. Вториот пристап ги разликува неуспесите на давателот на плаќања од грешките при валидација, бележи значајни настани околу напуштањето, зачувува доволно контекст за поддршката да истражи и му овозможува на тимот да ги промени пораките или однесувањето при повторен обид без да го препишува целиот тек.

И двете верзии може да изгледаат завршени на денот на пуштање. Само една му дава на тимот сигурен начин да разбере што доживуваат клиентите по пуштањето.

Проектирајте за прашањата за кои знаете дека ќе пристигнат

Антиципативната архитектура почнува со едноставна вежба: прашајте што ќе треба да знае тимот кога реалноста не се согласува со планот. Одговорите насочуваат скромни, но вредни избори во дизајнот.

• Можеме ли да кажеме што се случило? Користете структурирани логови, релевантни деловни настани и идентификатори за корелација што поврзуваат корисничко дејство со надолна работа.
• Можеме ли безбедно да го промениме однесувањето? Каде што е соодветно, држете ги променливите деловни правила и конфигурацијата одделно од длабоко поврзаните детали на имплементацијата.
• Можеме ли да закрепнеме? Дефинирајте временски ограничувања, повторни обиди, идемпотентност и јасни состојби на неуспех за операции што преминуваат ненадежни граници.
• Можеме ли да ја потврдиме промената? Автоматизирајте ги критичните патеки и направете ги повратните информации од распоредувањето видливи за луѓето што ја прават промената.
• Може ли нов член на тимот да го разбере компромисот? Запишувајте ги значајните одлуки со концизен јазик, вклучувајќи го контекстот и цената на нивното повторно разгледување.

Ова не се само оперативни грижи. Тие се грижи за производот. На клиентот не му е важно дали неуспешното дејство произлегло од доцнење во редица, истечен токен или недостапна зависност. Му е важно дали производот чесно го објаснува проблемот и му дава безбеден пат напред.

Вградете повратни јамки во системот за испорака

Производот учи само толку брзо колку што дозволува неговиот систем за испорака. Ако на развивачот му требаат неколку одобренија за да го провери однесувањето во продукција, ако распоредувањата се ретки и стресни или ако повратните информации од клиентите стигнуваат до инженерите недели подоцна без контекст, корисните сигнали избледуваат пред да можат да обликуваат одлука.

Доброто техничко лидерство ја намалува таа оддалеченост. Создава јамка: наведете претпоставка, пуштете мала промена, набљудувајте го однесувањето, разговарајте за резултатот и приспособете се. Јамката треба да биде доволно дисциплинирана за да ги заштити клиентите и доволно лесна за тимовите навистина да ја користат.

Изберете сигнали што поддржуваат одлука

Инструментацијата станува шум кога постои само затоа што мерењето изгледа одговорно. Пред да додадете настан или контролна табла, именувајте ја одлуката што ќе ја поддржи. На пример: „Ако корисниците постојано не успеваат на овој чекор на верификација, дали треба да ги подобриме упатствата, да го смениме правилото за валидација или да истражиме неуспех на интеграција?“

Ова врамување ги спречува тимовите да собираат бесконечни податоци, а сепак да немаат одговори. Исто така поттикнува заеднички јазик меѓу производот, дизајнот, поддршката и инженерството. Корисен сигнал е оној што му помага на некого да одлучи што да направи следно.

Направете го неуспехот првокласно корисничко патување

Оддалечените услуги откажуваат. Задачите се извршуваат двапати. Клиентите се исклучуваат. Систем што претпоставува успех ги принудува своите корисници и оператори да ја поднесат цената на тие реалности.

За задача во заднина што создава извештај, отпорниот дизајн може да зачува барање со стабилен идентификатор, да го обработи асинхроно, да прикаже јасен статус и да дозволи повторен обид што не создава дупликати. Деталите на имплементацијата ќе се разликуваат според производот, но принципот останува: дефинирајте што значи делумно завршено дејство пред продукцијата да го дефинира тоа за вас.

requested -> processing -> completed
                    |
                    v
                  failed

Тој мал модел на состојби создава простор за чесни интерфејси, работни текови за поддршка и сигурно закрепнување. Тој е многу повреден од преправањето дека секоја операција е моментална и сигурна.

На сопственоста ѝ требаат граници, а не сезнаење

Сопственоста понекогаш погрешно се разбира како лична одговорност за сè. Тоа е неодржливо, особено во дистрибуирани тимови. Поттикнува тесни грла, скриена работа и верување дека посветената личност секогаш треба да биде достапна.

Здравата сопственост е експлицитна. Тимот знае кои исходи ги поседува, кои системи може да ги промени, како да ескалира ризици и каде почнува одговорноста на друг тим. Истата јасност треба да постои и во кодот. Јасните интерфејси, документираните очекувања за услугите и стабилните договори се технички облици на соработка со почит.

За оддалечените тимови, писмената комуникација е дел од архитектурата. Краток запис за одлука може да спречи подоцнежна дебата да се реконструира преку историјата на разговорите. Прирачник за постапување може стресниот инцидент да го претвори во повторлив одговор. Добро напишано барање за повлекување може да објасни зошто наизглед едноставна промена има потреба од патека за миграција или ознака за функционалност.

Ништо од ова не го заменува разговорот. Го прави разговорот потраен и поинклузивен низ временските зони.

Практична почетна точка за следната функционалност

Не ви е потребна архитектонска иницијатива за да работите на овој начин. Почнете во следниот разговор за планирање. Пред имплементацијата, прашајте:

1. Кој исход за клиентот се обидуваме да го подобриме?
2. Каква претпоставка правиме за однесувањето или побарувачката?
3. Што може да не успее на границите на оваа функционалност?
4. Како ќе препознаеме успех, збунетост или деградација?
5. Која е најмалата обратлива верзија што можеме да ја пуштиме?
6. Кој ќе го разгледа резултатот и кога?

Потоа направете ги одговорите видливи во работата. Додадете ја потребната набљудливост, изберете безбедна патека за враќање или закрепнување и оставете кратко објаснување за следната личност. Резултатот не е повеќе процес заради самиот процес. Тој е помалку повторно откривање, помалку паника и помалку кревки успеси.

Трајната предност е брзината на учење

Производите ретко пропаѓаат затоа што тимот не замислил совршена иднина. Тие имаат тешкотии затоа што тимот не може да види што се случува, не може да реагира без страв или не може да ги пренесе одлуките понатаму додека луѓето и приоритетите се менуваат.

Антиципативната архитектура ѝ дава конкретна форма на сопственоста. Таа бара од развивачите да размислуваат надвор од тековниот тикет, од лидерите да направат простор за повратни информации и од тимовите да ја третираат оперативната јасност како дел од корисничкото искуство.

Најдобрите системи не се оние што тврдат дека можат да се справат со секоја иднина. Тие се оние што им помагаат на способните луѓе да забележат, разберат и подобрат што носи иднината.