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

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

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

Сопственоста е поширока од авторството

Авторството одговара на прашањето: „Кој го напиша ова?“ Сопственоста одговара: „Кој е одговорен ова да продолжи да биде корисно?“ Авторот на барање за повлекување може следниот месец да премине во друг тим. Услугата, работниот тек или корисничкото патување останува.

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

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

Почнете со намерата пред имплементацијата

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

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

• Проблем: На која корисничка, деловна или оперативна тешкотија ѝ се обраќаме?
• Очекуван исход: Што треба да стане полесно, побезбедно, побрзо или посигурно?
• Опсег: Што намерно не се решава во оваа итерација?
• Ограничувања: Кои технички, правни, оперативни или временски ограничувања го обликуваа пристапот?
• Сигнали: Кои докази ќе ни кажат дали промената функционира?
• Сопственик: Кој ќе се погрижи резултатот да биде проценет по објавувањето?

Ова не мора да стане обемен документ. Често е доволен концизен опис на тикет, белешка за дизајнот или образец за барање за повлекување. Целта не е бирократија; туку зачувување на образложението што ја прави кодната база разбирлива.

Направете ги компромисите експлицитни

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

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

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

Користете го прегледот на код како контролна точка за сопственоста

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

Корисни прашања вклучуваат:

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

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

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

Градете производи околу трајни домени

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

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

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

Создавајте предавања што ја задржуваат одговорноста

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

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

Мерете го учењето, не само протокот

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

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

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

Вистинскиот стандард за завршеност

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

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