Wspólna biblioteka klas dla wielu botów: co zyskuję i co za to płacę
W skrócie: pisząc kolejnego bota, nie piszę od nowa lota, limitu dziennego, blokady po stratach ani raportu z testu. Biorę klasę z wspólnej biblioteki. Zysk jest oczywisty: jedna poprawka naprawia wszystkie boty i każdy zachowuje się tak samo. Koszt jest mniej oczywisty: ta sama poprawka zmienia też zachowanie botów, które już działają na kontach.
Jak to u mnie wygląda
Biblioteka to folder z plikami nagłówkowymi .mqh, którym dołączam z każdego bota. Jest w niej obecnie ponad 90 takich
plików: wykonanie zleceń z lotem liczonym z ryzyka w dolarach, bezpiecznik ryzyka, limity dzienne, symulator
wyzwania prop, filtry, trailing, zapis raportu z testu i wiele innych. Każdy plik ma w nagłówku opis i szybki start.
Obok jest plik indeksu z jedną linią na plik, w którym szukam najpierw, zanim cokolwiek napiszę. To ważniejsze, niż
się wydaje: biblioteka, której nikt nie potrafi przeszukać, zamienia się w kopiowanie kodu pod inną nazwą.
Bot jest przez to cienką powłoką. Ma własne wejścia, własną logikę sygnału i wiąże klasy w OnInit. Reszta,
czyli wszystko, co nie jest samym pomysłem na wejście, siedzi w bibliotece.
Co zyskuję
- Lot liczony w jednym miejscu. Jedna klasa zna wartość punktu, krok lota i bezpiecznik minimalnego lota, więc nie mam trzydziestu własnych wzorów z trzydziestoma własnymi błędami.
- Poprawka raz, korzyść wszędzie. Gdy wykryłem, że blokada dzienna powinna liczyć tylko własne transakcje bota (przy kilku botach na jednym koncie), zmieniłem klasę raz.
- Porównywalność. Skoro wszystkie boty zapisują raport testu tą samą klasą, wyniki trafiają do jednej bazy w tym samym formacie.
- Mniej kodu do przeczytania przy audycie bota.
Co płacę
Najdroższa zasada: zmiana w bibliotece, która zmienia zachowanie, wymusza podbicie wersji każdego bota, który tę klasę dołącza. W listopadzie 2026 poprawka blokady dziennej dotknęła około 36 botów. Do 7 listopada podbiłem wersję 28 z nich, a resztę zostawiłem do najbliższej edycji, bo każde podbicie to osobna kompilacja, wpis w historii zmian i wdrożenie na konto. To jest rachunek, który zwykle ukrywa się przed oczami przy zachwycie nad wspólną klasą.
Drugi koszt to kolizje. Klasa, która deklaruje własne wejścia, pęka przy bocie, który ma wejścia o tych samych
nazwach. Dla takich klas używam makra wyłączającego ich wejścia i przepisuję wartości w OnInit. Zdarza się też,
że klasa sama nie czyta wejść bota. Raz uruchomiłem siatkę testów trailingu i dostałem 25 identycznych wyników,
bo klasa startowała w trybie “wyłączony”, a ja nie przepisałem jej pól.
Trzeci koszt to ostrożność przy wspólnych plikach: zmiana “tylko w jednym miejscu” rusza każdy bot naraz. Dlatego po zmianie klasy współdzielonej kompiluję kilka botów o różnej budowie, a przy zmianach wpływających na wejścia robię porównanie wyniku przed i po.
Kiedy nie warto
Do wspólnej klasy wkładam rzecz dopiero wtedy, gdy użył jej drugi bot. Pierwszy raz piszę lokalnie. Pomysł na wyjście, który i tak nie pobije bazy, nie powinien wprowadzać zmian do biblioteki, bo każda taka zmiana ma swój koszt w botach na kontach.
Checklista
- Przed nową klasą szukam w indeksie biblioteki, bo może już istnieje.
- Nowy plik w bibliotece dostaje linię w indeksie w tym samym commicie.
- Zmiana zmieniająca zachowanie = lista botów, które ją dołączają, i plan podbicia wersji.
- Klasa z własnymi wejściami ma wariant bez wejść dla botów, które mają je same.
- Po zmianie kompiluję boty o różnej budowie, nie jeden.
Powiązane
- Wersjonowanie EA i changelog
- Kompilacja z linii poleceń
- Break-even, partial i trailing
- Pojęcia z artykułu: słowniczek, skorowidz
Ostrzeżenie: handel CFD i forex wiąże się z wysokim ryzykiem utraty kapitału. Artykuł ma charakter edukacyjny i nie jest rekomendacją inwestycyjną.