Kiedy gruboziarnisty kod jest lepszy?

Prawdziwy przykład z prawdziwego projektu. Gostek miał zrobić dyskową strukturę danych odpowiadającą za wyszukiwanie jakichś danych po id oraz id po czymś tam innym. Struktura miała być oszczędna pamieciowo, więc w grę wchodziła jakaś kompresja, pakowanie bitów i takie tam - ogólnie nietrywialna sprawa. Jak dostałem pierwsza wersję do CR to nie było żadnej dokumentacji a cała metoda do dodawania danych do owej struktury to był taki blob na kilkadziesiat linii, niby nie taki długi ale dużo się działo - z jednej strony używający innych klas, a z drugiej strony robiący niskopoziomowo jakieś write do strumieni opakowanych w inne strumienie (jakieś writery itp). Pamiętam, że zanim się zorientowałem, że gościu pisze do TRZECH różnych plików i one mają różną funkcję, bo np jeden pozwala wyszukać A na podstawie B, a drugi B na podstawie A to minęło naprawdę sporo czasu. A wystarczyło to rozbić na trzy osobne kawałki kodu. Jak to rozbilem na te trzy osobne metody to się okazało że ten kod nie jest wcale taki skomplikowany.

Dlatego uważam że rzeczy, które są ze sobą słabo związane powinny być wydzielane do osobnych metod / funkcji, tak aby ilość kontekstu potrzebnego do analizy pojedynczej funkcji była jak najmniejsza.

No i w sumie bardziej mi przeszkadza jak kod korzysta z bardzo dużej liczby zmiennych niż jak sam w sobie jest długi. Miałem parę razy do przeczytania funkcje na raptem 20 linii a stanu było tak dużo że analiza działania zajmowała godziny a nie minuty. Z drugiej strony bezstanowy długi i płaski tasiemiec nie musi wcale być trudny w odbiorze.

Niestety to jest trochę takie zagadnienie gdzie dużo zależy od wyczucia i zmysłu estetyki piszącego ;)

Jako że w pewnym momencie pojawił się tutaj temat wydajności lambdy, funkcje itp. to podrzucam fragment wpisu z bloga StackOverflowa nt. ich codebase

One of the most noncontroversial good practices in the industry is automated tests. We don’t write a lot of these because our code doesn’t follow standard decoupling practices; while those principles make for easy to maintain code for a team, they add extra steps during runtime, and allocate more memory. It’s not much on any given transaction, but over thousands per second, it adds up. Things like polymorphism and dependency injection have been replaced with static fields and service locators. Those are harder to replace for automated testing, but save us some precious allocations in our hot paths

Similarly, we don’t write unit tests for every new feature. The thing that hinders our ability to unit test is precisely the focus on static structures. Static methods and properties are global, harder to replace at runtime, and therefore, harder to “stub” or “mock.” Those capabilities are very important for proper isolated unit testing. If we cannot mock a database connection, for instance, we cannot write tests that don’t have access to the database. With our code base, you won’t be able to easily do test driven development or similar practices that the industry seems to love.

That does not mean we believe a strong testing culture is a bad practice. Many of us have actually enjoyed working under test-first approaches before. But it’s no silver bullet: your software is not going to crash and burn if you don’t write your tests first, and the presence of tests alone does not mean you won’t have maintainability issues.

Best practices can slow your application down

To jest słaby argument, bo dobry kompilator potrafi połączyć wiele małych metod w większe - inlining to jedna z podstawowych optymalizacji. Przy okazji może wyrzucić niepotrzebne alokacje, niepotrzebne obiekty tymczasowe itp. Jeśli mamy też gdzieś wywołanie wirtualne / przez wskaźnik / ifa tylko po to aby w testach kod poszedł inna drogą np do mocka to w docelowej binarce nie zostanie po tym śladu. Oczywiście warto sprawdzić najpierw czy Twój kompilator/runtime to umie, bo nie każdy pisze w C++/Rust.

@Krolik:

Nie jest słaby, bo przecież sam napisałeś bo nie każdy pisze w C++/Rust. oraz mówimy o pewnie wielu latach do tyłu, jednakże współczesne kompilatory też mają wiele room for improvement