Formalnie weryfikowane frameworki webowe: Przyszłość trzeba udowodnić, nie tylko przetestować

Kiedy ostatnio byłeś pewny, że twój frontend działa poprawnie? Nie chodzi mi o testy — chodzi o matematyczny dowód, że kod robi dokładnie to, co powinien. Dla większości z nas odpowiedź brzmi: nigdy. Piszemy testy, trzymamy kciuki i wdrażamy z nadzieją, że nic się nie wysypie.

Właśnie dlatego projekt qed wywołuje u mnie takie emocje. To formalnie zweryfikowany framework do budowania interfejsów webowych, napisany w Lean 4.

Dlaczego Lean 4 jest wyjątkowy?

Jeśli nie znasz Leana, wyobraź sobie funkcjonalny język programowania z możliwościami, o których inne języki mogą tylko pomarzyć. Lean 4 powstał w Microsoft Research, a teraz rozwija się jako projekt open-source. Co go wyróżnia?

• Zależne typy — typy mogą zależeć od wartości, nie tylko od kategorii
• Pełna weryfikacja formalna — możliwość matematycznego dowodzenia poprawności kodu
• Metaprogramowanie — kod piszący kod, wbudowane w sam język
• Świetna wydajność — prędkości porównywalne z C

Najważniejszy jest system typów. Kiedy możesz wyrazić właściwości jako typy i potem udowodnić, że te typy zachodzą, nie znajdujesz błędów — eliminujesz całe ich kategorie.

Czym jest qed?

Projekt qed (od łacińskiego „quod erat demonstrandum" — „co było do pokazania") bierze możliwości weryfikacji Leana 4 i przenosi je na grunt budowania interfejsów webowych. To naprawdę nowatorskie podejście.

Tradycyjne frameworki — React, Vue, Svelte — pozwalają pisać kod i mieć nadzieję, że zadziała. Dodajesz testy, uruchamiasz aplikację, szukasz błędów. Problem w tym, że:

• testy nie dowodzą braku błędów
• błędy runtime'u i tak się przebijają
• przypadki brzegowe mnożą się szybciej niż pokrycie testami

Z podejściem formalnej weryfikacji nie piszesz tylko kodu — piszesz twierdzenia o tym kodzie i je dowodzisz. Kompilator staje się asystentem dowodzenia.

Dlaczego to ma znaczenie dla developerów?

Formalna weryfikacja do niedawna żyła w akadamiach i systemach krytycznych — oprogramowanie lotnicze, sterowanie elektrowniami atomowymi, implementacje kryptograficzne. Zwykły webdeveloper? Nigdy tego nie dotykał.

Ale ta przepaść się zmniejsza, a qed jest ważnym krokiem w tym kierunku:

1. Bezpieczeństwo od podstaw — zamiast dorzucać sprawdzenia bezpieczeństwa po napisaniu kodu, dowodzisz, że właściwości bezpieczeństwa zachodzą od początku.

2. Refaktoryzacja bez strachu — kiedy logika jest zweryfikowana, duże zmiany przestają być koszmarem. Dowód mówi ci, co zepsułeś.

3. Dokumentacja jako kod — zweryfikowane właściwości to wykonywalne specyfikacje. Twoje typy i dowody są dokumentacją.

4. Produkcyjna alternatywa dla niszy — Lean 4 dojrzał na tyle, że projekty takie jak qed pokazują, że można go używać w realnych scenariuszach.

Prawdziwa innowacja: zaufanie

To, co naprawdę mnie uderza w qed, to zmiana filozoficzna w myśleniu o jakości oprogramowania.

Standardowy model to „ufaj, ale weryfikuj". Ufasz, że kod działa, potem uruchamiasz testy. Weryfikacja formalna odwraca tę logikę — zaczynasz od zweryfikowanych fundamentów i budujesz w górę. Zaufanie jest matematyczne, nie oparte na nadziei.

Dla aplikacji, gdzie poprawność naprawdę ma znaczenie — dashboardsy finansowe, portale medyczne, systemy uwierzytelniania — to może być przełom.

Co dalej?

Będę szczery: formalnie zweryfikowany webdevelopment nie zastąpi jutro programistów Reacta. Krzywa uczenia się jest stroma, a ekosystem dopiero raczkuje. Ale qed udowadnia, że koncept działa.

W miarę jak systemy typów stają się potężniejsze, a narzędzia do weryfikacji bardziej dostępne, spodziewam się, że te idee będą przenikać do mainstreamu. Widać to już w coraz bardziej wyrafinowanym systemie typów TypeScriptu, w borrow checkerze Rusta, a teraz w projektach takich jak qed.

Pytanie nie brzmi, czy metody formalne wpłyną na codzienny rozwój — tylko jak szybko.

Tymczasem qed warto sprawdzić, jeśli interesuje cię przedni kraniec zweryfikowanego oprogramowania. Może nie pomoże ci wdrożyć następnego startupowego MVP, ale może zmienić sposób, w jaki myślisz o poprawności kodu.

W końcu czy nie byłoby miło udowodnić, że kod działa — zamiast tylko mieć nadzieję?

Co sądzisz o weryfikacji formalnej w webdevie? To przyszłość, czy przerost formy nad treścią dla większości zastosowań? Podziel się myślami poniżej.