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

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

Почнете со промената, а не со компонентите

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

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

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

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

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

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

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

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

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

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

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

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

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

Направете ја конфигурацијата грижа на производот

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

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

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

Нека практиките за испорака ја обликуваат архитектурата

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

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

1. Додадете ја новата структура без да ги нарушите постојните читања.
2. Распоредете код компатибилен со старите и новите податоци.
3. Мигрирајте или дополнете податоци во набљудливи серии.
4. Овозможете го новото однесување.
5. Отстранете го кодот за компатибилност откако преодот ќе заврши.

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

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

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

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

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

Намалувајте ја сложеноста намерно

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

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

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