mirror of
https://github.com/MaSzyna-EU07/maszyna.git
synced 2026-11-08 14:59:43 +01:00
24 lines
2.8 KiB
Markdown
24 lines
2.8 KiB
Markdown
# 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.
|