Na youtube pojawiła się niedawno playlista (a właściwie to 3), w której to dwóch seniorów poprawia słaby kod prostego programu analizując popełnione tam błędy. Szczególnie zaciekawił mnie ten filmik, gdzie wypowiadają się na temat DRY:
Sam nie wiem co o tym myśleć, a szczególnie o fragmencie, gdzie przedstawiany jest przykład z przedziałem dat. Co o tym sądzicie?
daj timestamp, nie kazdy ma czas caly filmik ogladac.
Generalnie dobrze mówią, szukanie duplikacji na siłę nie ma sensu, a DRY nie jest ważniejsze od SRP czy OCP. (A właściwie jest wręcz przeciwnie.)
Mamy jakiś stary kod, który działa, jest zamknięty w jakiejś klasie, więc często bezpieczniej go nie ruszać, a do nowej sytuacji napisać nową klasę. W ten sposób nie zepsujemy starego ficzera.
Oni raczej przestrzegają przed czymś takim jak frameworkowe podejście do budowania aplikacji, gdzie wszystko ma być zależne od jakiegoś generycznego utilsa z masą przełączników. W ekstremalnych sytuacjach okazuje się, że nie rozszerzamy feature tylko utils bo tak jest łatwiej. Często bywa, że programiści tłumaczą sobie coś jakąś zasadą jak np. DRY ale w rzeczywistości nie dostrzegają jakie problemy w szerszym kontekście będą powodować ich decyzje.
Większość zasad w informatyce to nie są święte prawa tylko dobre rady. Nawet zasady SOLID są wewnętrznie sprzeczne. Pisze o tym Uncle Bob (chyba) w Czystej Architekturze
Przede wszystkim przestrzegają przed czymś co się zowie spekulatywnym programowaniem, wprowadzaniem za szybko abstrakcji za pomocą próby przewidywania przyszłości, a mało który programista potrafi przewidywać przyszłość. Drugą koncepcją którą poruszają jest przypadkowa duplikacja, gdzie kod wygląda bardzo podobnie, jednak może w przyszłości się zmieniać zupełnie w inny sposób.
Nie oglądałem następnych odcinków póki co, ale to nie wygląda na przypadkową duplikację, ale żeby to stwierdzić potrzebujemy odsunąć w czasie tą decyzję o wprowadzeniu abstrakcji i zebrać więcej wiedzy, ten koncept wywodzący się z agile zowie się kruszeniem wiedzy (po angielsku lepiej brzmi knowledge crunching).
Nawet jak za szybko wprowadzimy abstrakcję do czegoś co się okazało przypadkową duplikacją, to należy pamiętać że zawsze możemy się z niej wycofać robiąc ctrl+c ctrl+v zamiast dodawać do niej ifologię.
Trzeci koncept o którym mówią to nazewnictwo i podział, ten kod kompletnie nie przekazuje intencji i nie da się go czytać jak prozy, a to jest znacznie ważniejsze niż jakieś powtarzanie i abstrakcje.
Bardzo dobry kurs, warto obejrzeć :).
dobry kanał, znacie jeszcze jakieś o podobnym kontencie?
Przewidywanie przyszłości ma niewiele wspólnego z wprowadzeniem abstrakcji. Poza tym wielu myli abstrakcję z przekierowaniem.
Abstrakcje się stosuje kiedy ma ona sens i kiedy jej wprowadzenie upraszcza projekt tu i teraz. Dobry programista potrafi tworzyć sensowne abstrakcje nawet jeśli mają tylko jedno użycie, a słaby często właśnie tworzy bezładna kupę błota, nawet jeśli użyć jest N. Abstrakcja to jest podstawowe narzędzie walki ze złożonością. Większość dużych projektów staje się trudna do rozwoju przez niedobór abstrakcji, a nie nadmiar. Ewentualnie przez mocno cieknące abstrakcje.
Konkretny przykład - jest sobie indeks bazy danych. Indeks to taka struktura, która mapuje klucze na offsety we właściwym pliku danych. Indeks jest pewnego rodzaju abstrakcja, bo zachowuje pewne niezmienniki niezależnie od tego jakie typy danych indeksuje. Np. należy spodziewać się, że offset odczytany z indeksu będzie mniejszy niz rozmiar pliku danych (indeks jak i plik są niemutowalne).
Teraz ktoś wymyślił, że z jednego serwera na drugi serwer prześle kawałek pliku z danymi oraz indeks. No ale po pokawałkowaniu pliku danych offsety w indeksie przestają się zgadzać z plikiem danych, bo dane się przesunęły. Więc co zrobił programista uber-senior z 20 lat doświadczenia? Dołożył flagę "plik był kopiowany od offsetu X do offsetu Y" i w miejscu użycia offsetu z indeksu (tj. po odpytaniu indeksu) dopisał kod poprawiający offset, tak aby nadal był w zakresie.
I tak całą abstrakcję indeksu szlag trafił. I nie ważne, że indeks jest użyty na razie jeden raz, nie ma duplikacji kodu i kod działa. Teraz jednak przy każdym nowym użyciu musisz wiedzieć, czy był kopiowany czy nie. Odkładanie poprawiania takich baboli do drugiego lub trzeciego użycia (tak, bo wtedy wyszłaby dopiero duplikacja kodu) to bardzo poważny błąd. Mniej w kodzie taki jeden wtf na każde 3 klasy i powodzenia w utrzymaniu go.
Ciekawy kanał. Imho brakuje na polskim YT kanałów z materiałami gdzie prowadzący pracuje na kodzie.
Większość to filmiki pod tytułem jak zostać programistą.
Polecam jeszcze kanał Przemka Bykowskiego, dla osób z niewielkim doświadczeniem można w praktyce zobaczyć wykorzystanie różnych fajnych technologii również na konkretnych przykładach.