cellar

Wizualnie arkusz to siatka komórek, ale to złudzenie tego, co dzieje się pod spodem. Logicznie arkusz to graf skierowany: komórka z formułą zależy od innych komórek, te od kolejnych. Cała inżynieria cellar sprowadza się do tego, żeby ten graf przeliczać poprawnie i tylko w tej części, która naprawdę tego wymaga.

Reszta, czyli parser formuł i funkcje, obudowuje ten jeden mechanizm. Jeśli graf zależności jest zrobiony źle, żaden bogaty język formuł tego nie uratuje, bo arkusz zacznie pokazywać liczby policzone na nieaktualnych danych.

Kiedy zmieniasz jedną wartość, nie możesz przeliczyć wszystkiego, bo to marnotrawstwo, ani przeliczyć w losowej kolejności, bo dostaniesz śmieci. Musisz dotknąć dokładnie tych komórek, które zależą od zmienionej, i zrobić to w kolejności, w której każda liczy się już na aktualnych danych swoich poprzedników.

To jest sedno cellar i jednocześnie miejsce, w którym większe arkusze robią się trudne. Naiwne rozwiązanie, które po każdej zmianie przelicza całą siatkę, działa na dziesięciu komórkach i pada na tysiącu.

Przeliczanie idzie po posortowanym topologicznie grafie zależności. Sortowanie topologiczne ustawia komórki w takim porządku, że zanim policzysz dowolną z nich, wszystkie, od których zależy, są już gotowe. Dzięki temu każda formuła widzi świeże wartości swoich źródeł, a nie ich poprzednią wersję.

To ten sam wzorzec, który decyduje o poprawności systemów buildu i bundlerów. Kolejność nie jest szczegółem, tylko warunkiem tego, że wynik w ogóle ma sens.

Bez tego cykl typu A zależy od B, a B od A zawiesiłby przeliczanie. Dzięki oparciu wszystkiego na jednym grafie ten najgroźniejszy przypadek nie wymaga osobnego kodu, tylko wynika z braku rozwiązania sortowania.

Najciekawsze w cellar jest to, że problem arkusza okazuje się tym samym problemem, który spotkasz w zupełnie innych miejscach. Wszędzie tam, gdzie zmiana jednej wartości ma pociągnąć inne w dobrej kolejności, siedzi graf zależności plus sortowanie topologiczne.