Zasady architektury w rozwoju mobilnym: czym są, jakie są rodzaje i jak stosować

Zasady SOLID

Zasady architektoniczne — to fundament wysokiej jakości kodu. SOLID to akronim wprowadzony przez Roberta Martina („Wujek Bob") opisujący pięć zasad projektowania obiektowego. Przestrzeganie SOLID sprawia, że kod jest bardziej elastyczny, testowalny i odporny na zmiany. Naruszanie zasad architektonicznych jest jedną z głównych przyczyn długu technicznego.

Przyjrzyjmy się każdej zasadzie. Single Responsibility Principle (SRP) — każda klasa powinna mieć tylko jeden powód do zmiany. Open/Closed Principle (OCP) — klasy są otwarte na rozszerzenia, ale zamknięte na modyfikacje. Liskov Substitution Principle (LSP) — obiekty typów pochodnych powinny móc zastępować obiekty typu bazowego bez naruszania logiki. Interface Segregation Principle (ISP) — wiele wyspecjalizowanych interfejsów jest lepszych niż jeden ogólny. Dependency Inversion Principle (DIP) — zależność od abstrakcji, a nie od konkretnych implementacji.

Według analizy SonarQube (2025), naruszenie zasad SOLID występuje w 68% projektów komercyjnych. Najczęstsze problemy to naruszenie SRP (35%) i ISP (22%). W IT Sectr wdrażamy SOLID na etapie przeglądu architektury — pomaga to zidentyfikować problemy, zanim przerodzą się w dług techniczny.

Single Responsibility Principle (SRP)

SRP (Zasada Jednej Odpowiedzialności) — najważniejsza i jednocześnie najczęściej naruszana zasada SOLID. Mówi: klasa powinna mieć tylko jeden powód do zmiany. Jeśli klasa robi zbyt wiele, trudno ją testować, modyfikować i rozumieć.

Typowe naruszenie to klasa, która jednocześnie przetwarza dane, zapisuje je w bazie danych i wysyła powiadomienia e-mail. Poniższy przykład pokazuje naruszenie SRP w Kotlin i jak je naprawić.

// Naruszenie SRP — klasa robi trzy różne rzeczy
class UserService {
    fun registerUser(email: String, name: String) {
        // 1. Walidacja danych
        if (!email.contains("@")) throw IllegalArgumentException("Invalid email")
        
        // 2. Zapis do bazy
        val user = User(email, name)
        database.save(user)
        
        // 3. Wysłanie powiadomienia
        emailService.sendWelcomeEmail(email, name)
    }
}

// Naprawa — podział na trzy klasy
class UserRegistrationService {
    fun register(email: String, name: String) {
        UserValidator().validate(email)
        val user = User(email, name)
        UserRepository().save(user)
        NotificationService().sendWelcome(user)
    }
}

W poprawionej wersji każda klasa odpowiada za swoje własne zadanie: UserValidator — za walidację, UserRepository — za zapis, NotificationService — za powiadomienia. To sprawia, że kod jest testowalny i wielokrotnego użytku — możesz wymienić implementację bazy danych bez zmiany logiki walidacji.

GRASP i Prawo Demeter

GRASP (General Responsibility Assignment Software Patterns) — dziewięć zasad architektonicznych dotyczących przydzielania odpowiedzialności między obiektami, opisanych przez Craiga Larmana. W przeciwieństwie do SOLID, GRASP odpowiada na pytanie „która klasa powinna zawierać tę metodę?". Kluczowe wzorce: Information Expert, Creator, Controller, Low Coupling, High Cohesion, Polymorphism, Pure Fabrication, Indirection, Protected Variations.

Prawo Demeter (LoD, zasada minimalnego powiązania) — prosta reguła: obiekt powinien komunikować się tylko z bezpośrednimi sąsiadami. Nie należy pisać a.getB().getC().doSomething() — to tworzy silne powiązanie między klasami. LoD poprawia możliwość ponownego użycia i upraszcza testowanie.

W IT Sectr sprawdzamy zgodność z LoD podczas przeglądu kodu. Jeśli metoda „przechodzi" przez trzy lub więcej obiektów, to sygnał, że architektura wymaga uproszczenia. Naruszenie LoD to jeden z najczęstszych Code Smell w dużych projektach.

DRY / KISS / YAGNI

DRY (Don't Repeat Yourself), KISS (Keep It Simple, Stupid) i YAGNI (You Ain't Gonna Need It) — trzy podstawowe zasady architektoniczne znane każdemu programiście. Pomimo swojej prostoty, naruszenia zdarzają się stale.

DRY — nie powielaj kodu. Jeśli ta sama logika pojawia się w dwóch miejscach, wydobądź ją do wspólnej metody lub klasy. Powielanie jest głównym źródłem błędów: poprawka w jednym miejscu jest zapominana w innym. DRY nie oznacza, że nie możesz mieć podobnego kodu — ważne jest, aby logika biznesowa się nie powtarzała.

KISS — im prościej, tym lepiej. Złożone rozwiązania z wieloma abstrakcjami i dziedziczeniem są często przesadzone. Zacznij od prostego rozwiązania i komplikuj je tylko w razie potrzeby. YAGNI — nie pisz kodu dla funkcjonalności, która może być potrzebna „kiedyś później". Prowadzi to do rozdęcia bazy kodu i zwiększenia złożoności konserwacji.

DRY — Don't Repeat Yourself

DRY — to nie tylko brak kopiuj-wklej. To zasada, zgodnie z którą każdy fragment wiedzy lub logiki powinien mieć pojedynczą, jednoznaczną reprezentację w systemie. Powielanie może być jawne (skopiowany kod) i niejawne (ta sama logika w różnych warstwach).

W IT Sectr używamy metryk analizy kodu do wykrywania powielania. Narzędzia takie jak SonarQube i Detekt pokazują procent powielonego kodu. Wartość powyżej 5% jest powodem do refaktoryzacji. Należy jednak pamiętać: DRY nie powinien być osiągany kosztem błędnych abstrakcji — czasami lepiej zostawić dwa podobne fragmenty kodu tak jak są, jeśli ich połączenie skomplikowałoby zrozumienie.

Separation of Concerns i Modularność

Separation of Concerns (SoC) — zasada architektoniczna, w której system jest podzielony na niezależne części (concerns), każda rozwiązująca własne zadanie. Klasycznym przykładem jest podział na warstwy: prezentacja, logika biznesowa, dostęp do danych. Każda warstwa zależy tylko od warstwy poniżej.

Modularność — stopień, w jakim system może być podzielony na moduły. Moduł to logicznie powiązana grupa klas z dobrze zdefiniowanym interfejsem. Moduły powinny być luźno powiązane (low coupling) i silnie spójne (high cohesion).

Spójność vs Powiązanie

Spójność (Cohesion) — miara tego, jak bardzo elementy w ramach jednego modułu są ze sobą powiązane. Wysoka spójność jest dobra: klasa robi jedną rzecz i robi ją dobrze. Niskie powiązanie (Low coupling) — miara tego, jak bardzo moduły są od siebie niezależne. Niskie powiązanie jest dobre: zmiana jednego modułu nie psuje innych.

Idealna architektura to wysoka spójność i niskie powiązanie. W praktyce oznacza to: klasa zawiera metody pracujące na tych samych danych (spójność) i zależy tylko od abstrakcji, a nie od konkretnych implementacji (powiązanie). Brak równowagi prowadzi do „Obiektów Boga" lub „kodu spaghetti".

Dług techniczny i Code Smell

Dług techniczny (Technical Debt) — metafora wprowadzona przez Warda Cunninghama opisująca „odsetki", które zespół płaci za nieoptymalne decyzje architektoniczne i naruszanie zasad architektonicznych. Podobnie jak dług finansowy, dług techniczny może być zamierzony (zdecydowaliśmy się zrobić szybko, przerobimy później) i niezamierzony (zła architektura z powodu braku doświadczenia).

Code Smell — powierzchowne oznaki głębokich problemów w kodzie. Termin spopularyzował Martin Fowler w książce „Refactoring". Typowe Code Smell: długie metody, duże klasy, długie łańcuchy wywołań, powielanie kodu, nadmierne używanie komentarzy (zamiast jasnego kodu).

W IT Sectr dług techniczny jest śledzony w Jira jako osobne zadania. Każdy sprint przeznaczamy 20% czasu na refaktoryzację i spłatę długu. Systematyczna praca z długiem technicznym to jedyny sposób, aby uniknąć sytuacji, w której dodanie nowej funkcji zajmuje więcej czasu niż jej opracowanie od zera.