maszyna/pr-reviews/PR-239.md

Review PR #239 — Refactor/mover long functions

Autor: @jerrrrycho · base: master · 103 pliki, +13168/−3871 · 67 commitów https://github.com/MaSzyna-EU07/maszyna/pull/239

Werdykt: Request changes — rebase, opis, kolejność ze stosem AI/hamulców

Przegląd wyrywkowy (rozmiar). Skupiłem się na strukturze zmian i na ryzyku dla innych PR-ów.

Podsumowanie

Rozbicie długich funkcji TMoverParameters (RunCommand, TractionForce, UpdatePipePressure, IncMainCtrl/DecMainCtrl, bateria…) i części hamulce.cpp na nazwane metody (RunBrakeCommand, SeriesMotorTractionForce, UpdateMainValve, DieselElectricForce…). Zmiana czysto strukturalna — pod S3776/S134.

Uwagi blokujące

1. Diff zawiera infrastrukturę testów, która jest już na master. tests/unit/golden.cpp, test_controls.cpp, COVERAGE.md, dane tests/unit/data/fiz/* itd. (~8 tys. linii) pokazują się jako „dodane”, bo trafiły na master innym PR-em (squash). Po rebase na aktualny master zostanie właściwy przyrost: Mover.cpp, MOVER.h, hamulce.cpp i ewentualne zmiany testów. Bez tego nie da się rzetelnie zrecenzować.
2. Brak opisu. Dla refaktoru tej skali proszę o: listę rozbitych funkcji, zapewnienie „bez zmian zachowania” i — kluczowe — wynik testów golden (Unit tests: N/N passed, bez regeneracji golden). Golden traces to tu jedyna siatka bezpieczeństwa; jeśli jakiś ślad trzeba było zregenerować, to znak zmiany zachowania i musi być opisany.
3. Kolizja ze stosem #187 → #262 → #263 → #264 → #265 (wszystkie zmieniają Mover.cpp::BrakeForceR, hamulce.h, Oerlikon_ESt) oraz z #259/#260 (MOVER.h). Przeniesienie kodu do nowych funkcji sprawi, że tamte łatki się nie nałożą. Trzeba ustalić kolejność z maintainerami; moja propozycja: najpierw mniejsze PR-y z poprawkami zachowania, potem ten refaktor (refaktor łatwiej powtórzyć niż przepisać poprawki fizyki).

Pozostałe uwagi (z MOVER.h)

4. Sygnatury Run*Command(…, bool &OK) zwracające też bool. Dwa kanały wyniku (zwracany „obsłużono” i wyjściowy OK) są mylące. Rozważyć std::optional<bool> (brak = komenda nie z tej grupy) albo mały struct.
5. Duplikacja power() const / non-const. Można zaimplementować wersję non-const przez const_cast z wersji const (wzorzec Meyersa) albo zostawić jedną const + osobny setter.
6. Nowe metody prywatne czy publiczne? Większość pomocników (UpdateMainValve, DieselElectricShuntForce…) powinna być private — sprawdzić, że nie powiększają publicznego API TMoverParameters.
7. Parametry wyjściowe przez referencję (double &dtrans, double &dmoment, double &tempUmax) — przy okazji refaktoru warto zwracać struct (czytelność, Sonar).
8. 67 commitów — przy merge squash albo uporządkowanie historii.