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

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

Тоа е разликата помеѓу произведување код и градење одржлива технологија.

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

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

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

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

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

Прегледот на код е циклус на подучување, а не порта за квалитет

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Градете кариери преку доверлива сопственост

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

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

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

Одржливата испорака е тимски спорт

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

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