Az alapítónk saját munkájából. A FlagZen az alapítónk nyílt forráskódú projektje, amelyet 2026-ban indított az ügyfélmunka mellett. Nem anonimizált: minden sora olvasható a GitHubon.

Történetek Korábbi munka, 2026

Feltétel nélkül

Feature flagek interfészként és osztályként, hogy a hívás helyén látszódjon, mit csinál a kód, a többit pedig a fordító ellenőrizze

Írta: Megjelent:

A feature flagek általában szétszórt if-else blokkokban vannak a kódban, olyan szöveges kulcsokkal, amelyeket senki sem ellenőriz. A FlagZen projektet azért készítettem, hogy ezeket eltüntessem szem elől: a flag egy interfész lesz, minden variánsa egy osztály, a megfelelőt pedig generált kód választja ki. A flaget használó kód egyetlen metódust hív meg, a feltételek pedig rejtve maradnak. Amit lehet, azt a fordító ellenőrzi. Nyílt forráskódú, az 1.1.0-s verzió elérhető Maven Centralon. Nem tudok róla, hogy élesben bárki használná.

Az ötlet
a flag egy interfész, minden variánsa egy osztály
Fordításkor ellenőrizve
a variánsok értéke, típusa és az ismétlődő értékek
Állapot
nyílt forráskódú, 1.1.0, még nincs éles felhasználója

Előzmények

A feature flageket szinte mindenhol ugyanúgy használják. Valahol a kódban egy if lekérdezi a flag providertől egy szöveges kulcs értékét, a két ágban pedig a régi és az új viselkedés van. Egy fontos flag sok helyen felbukkan, mindenhol a saját if-jével. Ha a flaget kivezetik, mindegyiket meg kell keresni. Ha valaki elgépeli a kulcsot, semmi sem jelzi a hibát, amíg le nem fut a rossz ág.

A feltételek ráadásul elrejtik a kód szándékát, és engem ez zavart a leginkább. Ahhoz, hogy megértsük, mit csinál egy kódrészlet, előbb ki kell bogozni, melyik ág fut le, az üzleti logika pedig elbújik a flag-ellenőrzések között. Senki sem kérte, hogy ezt megoldjam, a feature flagek enélkül is működnek. De írtam már arról, hogyan lehet a feltételes szerkezeteket polimorfizmussal kiváltani egy switch-case-ről szóló cikksorozatban, és feltettem magamnak a kérdést: miért lennének kivételek a feature flagek?

A megoldás

A FlagZen egy dispatch réteg a csapat által már használt flag provider fölött, amilyen például a LaunchDarkly, az OpenFeature vagy a Togglz. Nem kezel flageket, targetálást vagy A/B tesztelést, ez továbbra is a provider dolga. A projekttel együtt érkező, környezeti változókra épülő és hasonló providerek csak kényelmi megoldások, nem teljes értékű flag providerek.

A flag egy feature-ként megjelölt Java-interfész, minden variánsa pedig egy osztály, amely megvalósítja. Fordításkor egy annotation processor legenerálja azt a kódot, amely lekérdezi a providertől az aktuális értéket, és meghívja a hozzá tartozó osztályt. A flaget használó kód kap egy példányt, és meghívja rajta a metódust. Nincs if, amit ki kellene bogozni, és ha a flag értéke megváltozik, már a következő hívás az új variánst éri el, újraindítás nélkül.

Mivel a flagek és a variánsaik típusok, a fordító ellenőrizni tudja őket. Ha egy variáns értéke vagy típusa nem illik a feature-höz, a build sikertelen. Ugyanez történik két azonos értékű variánsnál is. Egy nem használt variánsra figyelmeztetést kapunk. Egy flag kivezetése az interfészének törlését jelenti, és a fordító megmutat minden helyet, amely még használja.

Eredmények

A FlagZen nyílt forráskódú, Apache 2.0 licenccel. Az 1.1.0-s verzió elérhető a Maven Centralon, Spring Boot-, OpenFeature-, LaunchDarkly- és Togglz-adapterrel. Tudomásom szerint élesben még senki sem használja, és a fejlesztés folytatódik. Ez kutatás és törekvés a feature flagek olyan írásmódjára, amelyet a saját kódbázisaimban is szívesen látnék, és amelyet bárki kipróbálhat.

A tanulság

Amit a fordító ellenőrizni tud, azt érdemes vele ellenőriztetni. Egy fordításkor elkapott hibát sokkal olcsóbb kijavítani, mint egy olyat, amely eljut a felhasználóig, és neki is gondot okoz. Ezért is részesítem előnyben az erősen típusos nyelveket.

És ne féljünk megkérdőjelezni, amit mindig is egy adott módon csináltunk. Ha soha nem kérdőjelezzük meg a szokásainkat, még a működőket sem, nem születik semmi új.

Hol rejtik el a feltételek a szándékot a kódjukban?

Egy rövid beszélgetés arról, hol nehezíti meg a kódjuk felépítése a változtatásokat. Javaslattal távoznak arról, hol érdemes kezdeni.

Időpontot foglalok További részletek