Tai, kad kuriu pats, nereiškia mažesnių lūkesčių.

TIESIOGINĖ ATSAKOMYBĖ

Nepriklausomybė vertinga tada, kai sutrumpina atstumą tarp sprendimo ir žmogaus, kuris už jį atsako.

Naudinga founder-built dalis nėra mažesnis žmonių skaičius. Naudinga tai, kad produkto tikslas, įgyvendinimas ir atsakomybė lieka arti vienas kito. Jei architektūros sprendimas sukuria blogą gedimo scenarijų, nėra kito skyriaus, kuriam galima jį permesti. Tai skatina sprendimus laikyti paaiškinamus, dokumentuoti svarbius kompromisus ir neprisikurti sudėtingumo, kurio vėliau niekas nenori valdyti.

NE UŽUOJAUTOS ARGUMENTAS

Tai, kad PerkRule nepriklausomas, nėra prašymas sumažinti kartelę patikimumui ar suderinamumui.

Parduotuvei nerūpi, kiek žmonių rašė kodą, kai sugenda checkout. Todėl founder-built identitetas čia yra priežastis didesnei disciplinai, o ne pasiteisinimas. Svetainė turi gebėti parodyti, kas įgyvendinta, kas dar neaišku, kas ištestuota ir kas liko backlog'e. Jei teiginys tokio konkretumo neatlaiko, geriau susilpninti teiginį, o ne lūkesčius.

NEMATOMAS DARBAS IRGI YRA FUNKCIJA

Darbas aplink matomą funkciją yra produkto dalis, net jei jo niekada nepamatysi screenshot'e.

Taisyklių konstruktorius gali atrodyti puikiai, bet pavojingesnis darbas slepiasi po juo: migracijos, stale schema elgesys, cache invalidation, rollback po dalinio persistence, deterministinė tvarka, paieškos ribos, request re-entry ir saugus gedimas, kai integracija elgiasi netikėtai. PerkRule šiuos dalykus laiko produkto darbu todėl, kad reali parduotuvė juos pajus net jei administravimo UI apie juos nieko nerodys.

IŠLEISTI SU AIŠKIOMIS RIBOMIS

Mažesnis produktas gali būti ambicingas, jei aiškiai pasako, ko dar neišsprendė.

Tikslas nėra paskelbti universalų suderinamumą prieš ištestuojant realias aplinkas. Build Ledger punktai lieka laukimo būsenoje, kol jų inžinerija neegzistuoja; žinomos rizikos gali likti įvardytos backlog'e; neišbaigti atvejai lieka nepalaikomi vietoj tyliai sugalvoto approximation. Patikimumas atsiranda tada, kai produkto riba matoma ir sąmoningai plečiama.

Inžinerija prieš launch teatrą

Produktas išleidžiamas tada, kai branduolys paruoštas, o ne todėl, kad atėjo marketingo data.

Klaidos lieka atsekamos

Kai sprendimas blogas, atsakomybė aiški ir pataisymui nereikia keliauti per organizacijos schemą.

Svarbūs sprendimai turi įrodymus

Inžinerijos užrašai paaiškina, kodėl produktas elgiasi būtent taip, užuot slėpę viską po šūkiais.

BRANDO STANDARTAS

Produktas 001 turi įrodyti pakartojamą programinės įrangos kūrimo būdą, o ne amžinai užrakinti PerkRule prie kuponų.

Akcijų variklis yra pirmoji vieta, kur tikrinamas PerkRule standartas: natyvi nuosavybė, kai platforma jau turi gerą modelį, ribotas runtime elgesys, skaidrios komercinės sąlygos, vieši inžinerijos užrašai ir tiesioginė atsakomybė. Būsimi produktai neprivalės būti panašūs į kuponų variklį, bet turės paveldėti šiuos lūkesčius, o ne tik logotipą.

KODĖL PRADĖTI ČIA

WooCommerce akcijos yra geras bandymų laukas, nes paprastos funkcijos greitai atsiremia į tikrą commerce sudėtingumą.

Kuponas gali sąveikauti su kliento būsena, geografija, mokėjimu, pristatymu, kitais kuponais, individual-use apribojimais, totals, skirtingais checkout paviršiais ir trečiųjų šalių integracijomis. Tai gera vieta patikrinti, ar brandas gali tvarkyti netvarkingas ribas neslėpdamas jų po gražiu UI. Jei disciplina veikia čia, ji tampa stipresniu pagrindu tam, ką kada nors spręs Produktas 002.