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

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

За развивачите што сакаат да градат производи што траат, оваа промена е важна. Кодот е механизмот. Искуството со производот е одговорноста.

Сопственоста започнува пред имплементацијата

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

Овие прашања не се одложувања маскирани како темелност. Тие го спречуваат тимот да испорача технички точен одговор на погрешен проблем.

Пред да изберете пристап, утврдете мала, но корисна дефиниција за успех:

• Кој е засегнат и што се обидува да постигне?
• Кое забележливо однесување треба да се промени за нив?
• Кои ограничувања се важни: приватност, латентност, пристапност, трошок, доверливост или поддршка?
• Како тимот ќе знае дали промената помогнала?
• Што треба да се случи кога очекувана зависност или влез не успее?

Разгледајте барање да им се испрати е-пошта на клиентите откако ќе поднесат формулар. Тесната имплементација е да се повика услуга за е-пошта по зачувувањето на записот. Сопственоста го проширува погледот: дали привремен прекин кај давателот треба да го блокира поднесувањето? Дали дупликатните повторни обиди би можеле да испратат повеќе пораки? Дали на клиентот му треба итна потврда дури и ако известувањето доцни?

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

Размислувајте во животен циклус, не во предавања

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

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

Направете ги операциите дел од функционалноста

„Работи локално“ е рана контролна точка, а не стандард за испорака. За значајни промени, поставете неколку оперативни прашања:

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

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

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

Преземете ги компромисите, не само идеалното решение

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

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

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

Овој пристап ги подобрува и разговорите за производот. Наместо да каже: „Тоа е невозможно“, силен технички партнер може да каже: „Сега можеме да го испорачаме основниот тек на работа, но ажурирањата во реално време би додале сложеност и оперативен ризик. Еве ја помалата верзија, што би исклучувала и што би требало да научиме пред да ја прошириме.“

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

На далечинските тимови им е потребна видлива сопственост

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

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

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

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

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

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

Одржливата испорака е помалку драматична. Таа вклучува мали рутини што го намалуваат идното триење:

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

Овие практики не се бирократија кога се применуваат со расудување. Така тимот ја штити својата способност постојано да испорачува корисна работа.

Кариера изградена врз исходи

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

Почнете мало. На следната задача, разјаснете го наменетиот исход. Идентификувајте една патека на неуспех. Запишете еден компромис. Проверете што се случило по изданието. Со текот на времето, тие навики го менуваат квалитетот и на производот и на разговорите околу него.

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