W przypadku pojawienia się nowej kolumny z ocenami przewidywanymi reszta tabelki się rozjeżdża.

Widzę że czasami korzystać z klas a czasami nie. Kod najlepiej gdy jest hermetyczny, wtedy jest bardziej odporny na czynniki zewnętrzne. Masz trochę za dużo odpowiedzialności per plik. Jak dla mnie to np. tworzenie zmiennej globalnej i wykorzystanej jej w kilku też globalnych metodach jest pogwałceniem bezpieczeństwa. Po to są argumenty i parametry, aby hermetyzować kod.

DDD i CQRS

Też kod napisany w pełni obiektowo jest dużo łatwiej testować. Też, aby sobie ułatwić sprawę pisz klasy DTO oraz klasy Domen.
Domena to taka najbardziej podstawowa klasa w całym projekcie. Ona ma zdefiniowane najbardziej podstawowe struktury. Domeny określają jakie podstawowe zasoby są podstępne w ramach projektu. Ja najczęściej Domen używam jako Encji. Domeny przechowują stan aplikacji. Ten stan można czytać (np. z bazy danych) albo zmieniać (zmieniać czyli tworzyć, edytować i usuwać). Gdy stan Domeny się zmienia wtedy mechanizmy nasłuchujące tych zmian wykonują swoją logikę (to może być cokolwiek, ale generalnie chodzi mi o Eventy Domenowe).... Przestawiłem ci mały skrawek z koncepcji DDD. Ogólnie to polecam zacząć tworzyć kod według zasady CQRS. To się sprawdza i na frontend i na backend i w gamedev. Ten CQRS jest też dobrym wstępem w koncepcję DDD. To też jest czymś co lepiej samemu znaleźć, bo każdemu przypasuje inne źródło. co CQRS jest w miarę prosty do zrozumienia to jednak całe DDD wymaga wiele praktyki i wracania do koncepcji (trzeba nie raz kilka razy to samo przeczytać).
Oczywiście za tym się też kryje stosowanie SOLID, KISS, DRY, YAGNI chociaż nigdy nie da się spełnić w 100% zasad programowania. Czasami względem jednej klasy te zasady potrafią się ze sobą kłócić, wtedy wybierz co będzie lepsze w danej sytuacji.

Testy

W całym kodzie nie znalazłem testów (albo jestem ślepy). Są one konieczne do utrzymania kodu w swoim założeniu. Najlepiej jest tak testować wszystkie klasy, wtedy będziesz wiedzieć czy pewne zmiany nie wpływają na działanie reszty kodu. Testy to wykażą i będzie ci o miliard razy łatwiej naprawić błędy. Jeśli pewne założenia się zmienią to warto przyjrzeć się testom i je też zmienić.

Unit test

Jednym ze sposobem testowania jest pisanie unit testów, generalnie to jest kod do sprawdzania kodu.

Scenariusze testowe - testy manualne

To jest ciekawy sposób testów, bo trzeba się naklikać aby coś przetestować. Scenariusze testowe mają ci pomóc określić w co poklikać i jaki ma być oczekiwany efekt. Możesz np. najpierw napisać scenariusze, a potem unit testy. Scenariusze testowe to po prostu pewne opowiadanie np.

Jako (anonimowy) UŻYTKOWNIK edytuję sposób liczenia średniej na taki, a taki i oczekuję, że średnia wyjdzie tyle, tyle

Oczywiście sam będziesz lepiej wiedzieć jak to sobie opisać.

gherkin

Scenariusze testowe można pisać w gherkin i później to można przekonwertować na kod za pomocą jakiegoś automatu.

Witam mam problem ponieważ Opera oraz Chrome nie chce załadować wtyczki. Wyświetla komunikat że brakuje mu pliku manifestu

Wybacz, ale musiałem gdy to zobaczyłem:

Wiem, że uciążliwe może być ciągłe szukanie w plikach gdzie miejsca debugowania, ale możesz po prostu zrobić własną funkcję do logowania, która będzie używać console.log (albo możesz nawet spróbować przeciążyć console.log) i dodać w środku if, którym sprawdzasz środowisko rozszerzenia czy jest DEV czy jest PROD (można użyć pewnego rodzaju enum). Jeśli jest to DEV no to logi działają, a jeśli PROD no to pomija logowanie i ju. Wtedy gdy się zapomnisz to zmienisz tylko środowisko z DEV na PROD i po problemie będzie

console.logi mogą być użyte do kradnięcia danych przez np. inne wtyczki (chociaż sposobów pewnie jest więcej).