G prawda. Kod napisany perfekcyjnie 10 lat temu, dziś jest uznawany za gówniany i ciężki w utrzymaniu. Miałem aplikację w MFC C++ napisaną zajebiście, zgodnie ze wszystkimi ówczesnymi praktykami jakie tylko można było zastosować.
A to dobre praktyki są czymś zależnym od czasu? 10 lat temu nie znano jeszcze pętli i funkcji, więc kopiowano kod? SRP albo DI były zakazane?
A kiedy GoF opublikowali swoją książkę o wzorcach projektowych? A w jakim języku są przykłady?
Niestety, dziś jest to uznawane za trudne w utrzymaniu i kijem nikt nie chce tego ruszać. Za 10 lat to samo będzie z waszymi wychuchanymi wywzorvowanymi pięknymi aplikacjami w .Net i Javie - nikt tego nie zechce nawet dotknąć. Mogę wam to zagwarantować.
Co do MFC - trudno, żeby np. nowi na rynku programiści chcieli pisać w czymś, co jest starsze od nich, a ponadto istnieją do tego dużo przyjemniejsze alternatywy.
Za 10 lat to samo będzie z waszymi wychuchanymi wywzorvowanymi pięknymi aplikacjami w .Net i Javie - nikt tego nie zechce nawet dotknąć. Mogę wam to zagwarantować.
Problem jest właśnie w tym, że może z 1% aplikacji trzyma się jakichś dobrych praktyk. Większość kodu jest słaba, więc masz rację - za 10 lat nikt nie będzie chciał tego ruszać.
Tak czytam komentarze w stylu 'jak widzę niefajny kod to go zmieniam' i zastanawiam się czy wy pracujecie nad jakimiś malutkimi projektami czy WTF? Pracuję przy bardzo dużym systemie, którego używa mnóstwo firm w Polsce, projekt ma ponad 10 lat - ogólnie są w nim zastosowane wszystkie trendy jakie panowały w programowaniu od 10 lat wstecz do teraz, tzw. 8 - tysięczniki to jeszcze jest w porządku, w wielu miejscach jest znacznie gorzej, wyobraźcie też sobie, że przez te 10 lat logika biznesowa zmieniała się wielokrotnie więc logika w kodzie jest bardzo zagmatwana, nie ma takiej opcji żeby zmieniać niefajny kod bo trzeba by było przepisywać cały moduł :)
Każde podzielenie metody na mniejsze, znalezienie powtórzeń w kodzie i zrobienie z nich metody, oddelegowanie wykonania czegoś do innej klasy - to już zmiana kodu na lepsze. Nie trzeba przepisywać od razu całości. Często jest tak, że jak zaczynasz długą metodę dzielić na mniejsze, to potem okazuje się, że można ich wielokrotnie używać także w innych długich metodach, więc ostatecznie z ośmiotysięcznika robi się 1000 linii w 10 klasach.
Nie doszłoby do takiego syfu, gdyby ludzie stosowali zasadę harcerza zamiast zasady zbitej szyby. Gdyby nie mówili, że nie można nic zrobić dobrze, tylko trzeba przepisać od nowa cały moduł. No i gdyby od początku trzymali się SRP, DRY i kilku wzorców projektowych ograniczających ifologię.
Czasami było tak, że z pozoru aplikacja działała poprawnie i niby wszystko OK a tu na mail przyszło powiadomienie o jakimś błędzie, zastanawiam się tylko czy tego typu rzeczy można by było tak łatwo wykryć testem jednostkowym? Zwłaszcza jeśli chodzi o integrację z zewnętrznymi serwisami do jakiegoś logowania OAuth czy inne tego typu rzeczy.
Jak najbardziej, po prostu przemyśl testy pod kątem różnych błędów, które zewnętrzny serwis może zwrócić. Sam serwis opakuj w jakąś klasę dostępową, a potem ją zamockuj w testach.
