W jednym z moich ostatnich artykułów pisałam na temat poprawiania czytelności nazw w projekcie. Jednym ze sposobów, o którym pisałam było powiedz jakiego wzorca używasz. Jakiś czas później przeczytałam newsletter od Sandi Metz > “Don’t Name Classes After Patterns. Mostly”. Sandi przedstawia tam inny punkt widzenia na używanie nazw wzorców w nazwach klas, z małym wyjątkiem. Myślę, że to dobry temat by na chwilę się nad tym zastanowić. W programowaniu nie ma jednej złotej zasady, jak tworzyć nazwy. Są wskazówki, jak to robić, ale one maja nam tylko pokazać drogę. Nie są jedynym źródłem prawdy. Każde rozwiązanie ma swoje wady i zalety, dlatego dobrze mieć szerszą perspektywę na problem z jakim się mierzymy.

Jako programiści często rozmawiamy o wysokopoziomowej architekturze. Mam tu na myśli DDD, architekturę heksagonalną i tym podobne. Chcemy wprowadzić choć część tych koncepcji do naszego projektu. I to najlepiej, teraz! Nowa architektura, nowy język programowania, nowy framework. Wpadamy w taką pułapkę nowinek technologicznych. Są one jak narkotyk. Chcemy więcej i więcej. Trochę nie myśląc przy tym o konsekwencjach. Cel jest szczytny. Chcemy mieć nowoczesny, dobrej jakości projekt, który łatwo da się dalej rozwijać. Niestety, trochę gubimy się w tym jak to osiągnąć. Nasz projekt potrzebuje ewolucji, a nie rewolucji. Dążenia małymi kroczkami do dobrej architektury. Jest to istotne, ale trudne do osiągnięcia. Potrzeba tu przede wszystkim cierpliwości i jasnego celu. Dziś zajmę się tematem, który jest właśnie takim małym kroczkiem do zbudowania dobrej architektury. Jest to odpowiednie nazywanie rzeczy

Myślę, że każdy programista, na pewnym etapie rozwoju, chciałby zająć się rozwiązywaniem dużych problemów. Chciałby tworzyć systemy o złożonej strukturze i być tą osobą, która za pomocą swoich rozwiązań zbawi świat. Czułaś się kiedyś w ten sposób? Ja tak, i to nie jeden raz. To zabawne, ale w chwilach, gdy właśnie tak się czuje, chciałabym zmienić całkowicie architekturę aplikacji, oczywiście na lepsze. ;] Zrobić refaktoring to tu, to tam. Byłabym w stanie zrobić to zupełnie sama, bez żadnej pomocy. Już widzę to wspaniałe rozwiązanie w swojej głowie. Jest prawie gotowe do użycia. W takich chwilach zapominam całkowicie, że takie rzeczy nie dzieją się same. O architekturę aplikacji trzeba dbać każdego dnia, w każdej linijce kodu. To jest ciężka praca. O wiele fajniej jest myśleć o integracji z Google Earth Engine, niż o nazwie jakieś mało istotnej zmiennej. Prawda?

Ostatnim razem w artykule Refactoring w Ruby krok po kroku - część 1 przeszłyśmy od kodu proceduralnego do kodu bardziej zorientowanego obiektowo. Tym razem będziemy kontynuować naszą podróż przez refaktoring. Będziemy mówić o małych obiektach zastępujących duże klasy, o kompozycji i o wstrzykiwaniu konkretnych zachowań do obiektów. Zaczynajmy!

Refaktoring jest jednym z moich ulubionych tematów. Uwielbiam porządki w prawdziwym życiu, ale też w kodzie źródłowym. Pracowałam i nadal pracuję nad aplikacjami internetowymi. I wciąż poszukuje odpowiedzi na następujące pytania: Jak pisać dobry kod? Co powoduje, że po pewnym czasie nasz kod staje się brzydki i nieczytelny? Jak radzić sobie z rosnącą złożonością w projektach? Każdego dnia uczę się jak robić dobry refaktoring. Bazuję na zdobytym przeze mnie, jak i przez innych, doświadczeniu. Dziś chciałabym się podzielić z Tobą przykładem refaktoringu zrobionego krok po kroku.

Niedawno miałam sytuację w której pracowałam z różnymi (choć pod pewnymi względami podobnymi) kolekcjami w Ruby. Te kolekcje miały bardzo podobne metody do przeszukiwania względem nazwy. W tym konkretnym przypadku zdecydowałam się na skorzystanie z lambdy. Zobaczcie jak to wyglądało.

Kilka tygodni temu pracowałam nad klasą kontrolera w aplikacji Railsowej. Na pierwszy rzut oka kod wyglądał przyzwoicie. Był całkiem zwięzły, czytelny, nie było się do czego przyczepić. Jednak był w nim pewien błąd, który przy pobieżnym czytaniu mógł zostać przeoczony. Ponieważ i tak musiałam zmienić tę klasę, ze względu na znajdujący się w niej błąd, postanowiłam, że zrobię tam trochę porządków. Pokrótce przedstawię jak to wyglądało.

Tym razem będę zmieniać kody w Ruby. Napisałam małego potworka. I teraz stwierdziłam, że ten kod jest tak straszny, że muszę coś z nim zrobić. Dobrze, ale zacznijmy od początku…

To będzie mój pierwszy wpis o refaktoringu. Uwielbiam refaktoring, więc bierzmy się do pracy. Myślę, że najlepszym sposobem by to zrobić będzie zapisanie na początku fragmentu kodu a później wprowadzenie zmian. Dzisiaj chciałabym zaprezentować Wam kilka linijek kodu w CoffeeScript…