mirror of
https://github.com/MaSzyna-EU07/maszyna.git
synced 2026-11-13 03:07:40 +01:00
fix: the bugs and vulnerabilities SonarCloud reports on PR #216
This commit is contained in:
23
pr-reviews/PR-239.md
Normal file
23
pr-reviews/PR-239.md
Normal file
@@ -0,0 +1,23 @@
|
||||
# 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.
|
||||
Reference in New Issue
Block a user