Czysta architektura. Struktura i design oprogramowania. Przewodnik dla profesjonalistów - ebook

Pierwsze linie kodu powstawały pół wieku temu. Komputery, na które tworzono te programy, w bardzo niewielkim stopniu przypominały współczesne maszyny. Niezależnie od upływu lat, postępu technologii i powstawania wymyślnych narzędzi, języków programowania czy frameworków pewne zasady tworzenia kodu pozostają niezmienne. Są takie same jak w czasie, gdy Alan Turing pisał pierwszy kod maszynowy w 1946 roku. Respektowanie tych zasad to warunek, że uzyska się oprogramowanie o czystej architekturze, czyli poprawne strukturalnie, łatwe w utrzymaniu i rozwijaniu, a przede wszystkim działające zgodnie z oczekiwaniami.

W tej książce w sposób jasny i bardzo interesujący przedstawiono uniwersalne zasady architektury oprogramowania wraz z szeregiem wskazówek dotyczących stosowania tych reguł w praktyce. Wyczerpująco zaprezentowano tu dostępne rozwiązania i wyjaśniono, dlaczego są one tak istotne dla sukcesu przedsięwzięcia. Publikacja jest wypełniona bardzo praktycznymi rozwiązaniami problemów, z którymi musi się mierzyć wielu programistów. Szczególnie cenne są uwagi dotyczące zapobiegania częstemu problemowi, jakim jest stopniowa utrata jakości kodu w miarę postępu projektu. Ta książka obowiązkowo powinna się znaleźć w podręcznej biblioteczce każdego architekta oprogramowania, analityka systemowego, projektanta i menedżera!

Z książki dowiesz się:

• Do czego muszą dążyć architekci oprogramowania i w jaki sposób mogą osiągać te cele
• Jak brzmią najważniejsze zasady projektowania oprogramowania związane z adresowaniem funkcji, separacją komponentów i zarządzaniem danymi
• W jaki sposób paradygmaty oprogramowania wzmagają dyscyplinę pracy
• Co podczas tworzenia oprogramowania jest więcej, a co jest mniej ważne
• W jaki sposób implementować optymalne struktury dla sieci WWW, baz danych, konsoli i aplikacji osadzonych

Czysta architektura - doskonały kod!

• Przedmowa
• Wstęp
• Podziękowania
• O autorze
• I Wprowadzenie
• 1. Czym są projekt i architektura?
  • Cel?
  • Studium przypadku
    • Oznaki bałaganu
    • Okiem zarządu
    • Gdzie szukać przyczyny?
  • Wnioski
• 2. Opowieść o dwóch wartościach
  • Zachowanie
  • Architektura
  • Ważniejsza wartość
  • Macierz Eisenhowera
  • Walka o architekturę
• II Zacznij od podstaw. Paradygmaty oprogramowania
• 3. Przegląd paradygmatów
  • Programowanie strukturalne
  • Programowanie obiektowe
  • Programowanie funkcyjne
  • Coś do przemyślenia
  • Wnioski
• 4. Programowanie strukturalne
  • Dowód
  • Ogłoszenie szkodliwości
  • Dekompozycja funkcyjna
  • Brak formalnych dowodów
  • Metoda naukowa
  • Testy
  • Wnioski
• 5. Programowanie obiektowe
  • Hermetyzacja?
  • Dziedziczenie?
  • Polimorfizm?
    • Moc polimorfizmu
    • Odwrócenie zależności
  • Wnioski
• 6. Programowanie funkcyjne
  • Kwadraty liczb całkowitych
  • Niezmienność i architektura
  • Podział zmienności
  • Strumień zdarzeń
  • Wnioski
• III Reguły projektowe
• 7. SRP reguła jednej odpowiedzialności
  • Symptom 1. Przypadkowa duplikacja
  • Symptom 2. Złączenia
  • Rozwiązania
  • Wnioski
• 8. Reguła otwarte-zamknięte
  • Eksperyment myślowy
  • Kontrola kierunku
  • Ukrywanie informacji
  • Wnioski
• 9. Zasada podstawień Barbary Liskov
  • Jak używać dziedziczenia?
  • Problem z kwadratem i prostokątem
  • Zasada LSP i architektura
  • Przykład naruszenia zasady LSP
  • Wnioski
• 10. Zasada rozdzielania interfejsów
  • Zasada ISP i język
  • Zasada ISP i architektura
  • Wnioski
• 11. Zasada odwrócenia zależności
  • Stabilne abstrakcje
  • Fabryki
  • Komponenty konkretne
  • Wnioski
• IV Zasady komponentów
• 12. Komponenty
  • Krótka historia komponentów
  • Relokacje
  • Konsolidatory
  • Wnioski
• 13. Spójność komponentów
  • Zasada Reuse (Release Equivalence Principle)
  • Zasada Common Closure Principle
    • Podobieństwo do zasady SRP
  • Zasada Common Reuse Principle
    • Związki z zasadą ISP
  • Diagram napięć dla zasad spójności komponentów
  • Wnioski
• 14. Łączenie komponentów
  • Zasada zależności niecyklicznych
    • Cotygodniowa kompilacja
    • Eliminowanie zależności cyklicznych
    • Efekty powstania cykli w grafie zależności komponentów
    • Usuwanie cykli
    • Drgania
  • Projekt typu top-down
  • Zasada stabilnych zależności
    • Stabilność
    • Miara stabilności
    • Nie wszystkie komponenty powinny być stabilne
      • Komponenty abstrakcyjne
  • Zasada stabilnych abstrakcji
    • Gdzie umieścić reguły wysokiego poziomu?
    • Wprowadzenie do zasady stabilnych abstrakcji
    • Miara abstrakcji
    • Ciąg główny
      • Strefa bólu
      • Strefa bezużyteczności
    • Unikanie stref wykluczenia
    • Odległość od ciągu głównego
  • Wnioski
• V Architektura
• 15. Czym jest architektura?
  • Rozwój systemu
  • Wdrożenia
  • Działanie
  • Konserwacja
  • Zachowywanie dostępnych opcji
  • Niezależność od urządzenia
  • Spam
  • Adresowanie fizyczne
  • Wnioski
• 16. Niezależność
  • Przypadki użycia
  • Działanie
  • Rozwój
  • Wdrożenia
  • Otwarte opcje
  • Oddzielanie warstw
  • Rozdzielanie przypadków użycia
  • Tryby rozdzielania
  • Możliwość niezależnego rozwijania
  • Niezależne wdrożenia
  • Duplikacja
  • Tryby rozdzielania (ponownie)
  • Wnioski
• 17. Granice. Wyznaczanie linii
  • Dwie smutne historie
  • FitNesse
  • Jakie linie rysować i kiedy to robić?
  • A co z wejściem i wyjściem?
  • Architektura wtyczek
  • A jednak wtyczki
  • Wnioski
• 18. Anatomia granic
  • Przekraczanie granic
  • Straszliwy monolit
  • Instalowanie komponentów
  • Wątki
  • Procesy lokalne
  • Usługi
  • Wnioski
• 19. Zasady i poziomy
  • Poziomy
  • Wnioski
• 20. Reguły biznesowe
  • Encje
  • Przypadki użycia
  • Modele żądania i odpowiedzi
  • Wnioski
• 21. Krzycząca architektura
  • Motyw architektury
  • Cel architektury
  • A co z siecią WWW?
  • Framework to narzędzie, a nie styl życia
  • Testowanie architektury
  • Wnioski
• 22. Czysta architektura
  • Zasada zależności
    • Encje
    • Przypadki użycia
    • Adaptery interfejsów
    • Frameworki i sterowniki
    • Tylko cztery kręgi?
    • Przekraczanie granic
    • Jakie dane przekraczają granice?
  • Typowy scenariusz
  • Wnioski
• 23. Prezentery i skromne obiekty
  • Wzorzec projektowy skromny obiekt
  • Prezentery i widoki
  • Testowanie i architektura
  • Bramy do baz danych
  • Mapowanie danych
  • Serwisy
  • Wnioski
• 24. Granice częściowe
  • Pomiń ostatni krok
  • Granice jednowymiarowe
  • Fasady
  • Wnioski
• 25. Warstwy i granice
  • Hunt the Wumpus
  • Czysta architektura?
  • Przekraczanie strumieni
  • Dzielenie strumieni
  • Wnioski
• 26. Komponent Main
  • Najważniejszy detal
  • Wnioski
• 27. Serwisy, duże i małe
  • Architektura serwisów?
  • Zalety serwisów?
    • Czy rzeczywiście separują?
    • Czy rzeczywiście pozwalają na niezależny rozwój i wdrożenia?
  • Problem z kotkami
  • Pomogą nam obiekty
  • Serwisy bazujące na komponentach
  • Sprawy ogólnosystemowe
  • Wnioski
• 28. Granice testów
  • Testy jako komponenty systemu
  • Projekt ułatwiający testy
  • API testujące
    • Rozdzielanie strukturalne
    • Bezpieczeństwo
  • Wnioski
• 29. Czysta architektura osadzona
  • Test n-App-stawienia
  • Problem docelowego sprzętu
    • Czysta architektura osadzona umożliwia testowanie
      • Warstwy
      • Sprzęt jest szczegółem
    • Nie przekazuj szczegółów sprzętowych użytkownikom warstwy HAL
      • Procesor jest szczegółem
      • System operacyjny jest szczegółem
    • Programowanie dla interfejsów i możliwości podmiany
    • Warunkowe dyrektywy kompilatora i zasada DRY
  • Wnioski
• VI Szczegóły
• 30. Baza danych jest szczegółem
  • Relacyjne bazy danych
  • Dlaczego systemy baz danych są takie powszechne?
  • A gdyby nie było dysków?
  • Szczegóły
  • A co z wydajnością?
  • Anegdota
  • Wnioski
• 31. Sieć WWW jest szczegółem
  • Wieczne wahadło
  • Rezultat
  • Wnioski
• 32. Frameworki są szczegółem
  • Autorzy frameworków
  • Małżeństwo asymetryczne
  • Ryzyko
  • Rozwiązanie
  • Teraz ogłaszam was
  • Wnioski
• 33. Studium przypadku. Sprzedaż filmów
  • Produkt
  • Analiza przypadków użycia
  • Architektura komponentów
  • Zarządzanie zależnościami
  • Wnioski
• 34. Zaginiony rozdział
  • Pakowanie w warstwy
  • Pakowanie według funkcji
  • Porty i adaptery
  • Pakowanie według komponentów
  • Diabeł tkwi w szczegółach implementacji
  • Organizacja a hermetyzacja
  • Inne sposoby rozdzielania
  • Wnioski. Zaginiona porada
• VII Dodatki
• A Archeologia architektury
  • System księgowości Union
  • Cięcie laserowe
  • Monitorowanie odlewów aluminium
  • 4-TEL
  • Komputer SAC
    • Wysyłanie serwisantów
    • Architektura
    • Wielkie przeprojektowanie
    • Europa
    • Wnioski
  • Język C
    • C
  • BOSS
  • pCCU
    • Pomyłka w planach
  • DLU/DRU
    • Architektura
  • VRS
    • Nazwa
    • Architektura
    • Wnioski
  • Elektroniczny recepcjonista
    • Śmierć recepcjonisty
  • System wysyłania serwisantów
  • Clear Communications
    • Wstęp
    • Wujek Bob
    • Telefon
  • ROSE
    • Nieustające dyskusje
    • pod innymi nazwami
  • Egzamin na architekta
  • Wnioski
• Posłowie