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

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! Spis treści Przedmowa Wstęp Podziękowania O autorze Część I. Wprowadzenie Rozdział 1. Czym są projekt i architektura? Cel? Studium przypadku Oznaki bałaganu Okiem zarządu Gdzie szukać przyczyny? Wnioski Rozdział 2. Opowieść o dwóch wartościach Zachowanie Architektura Ważniejsza wartość Macierz Eisenhowera Walka o architekturę Część II. Zacznij od podstaw. Paradygmaty oprogramowania Rozdział 3. Przegląd paradygmatów Programowanie strukturalne Programowanie obiektowe Programowanie funkcyjne Coś do przemyślenia Wnioski Rozdział 4. Programowanie strukturalne Dowód Ogłoszenie szkodliwości Dekompozycja funkcyjna Brak formalnych dowodów Metoda naukowa Testy Wnioski Rozdział 5. Programowanie obiektowe Hermetyzacja? Dziedziczenie? Polimorfizm? Moc polimorfizmu Odwrócenie zależności Wnioski Rozdział 6. Programowanie funkcyjne Kwadraty liczb całkowitych Niezmienność i architektura Podział zmienności Strumień zdarzeń Wnioski Część III. Reguły projektowe Rozdział 7. SRP — reguła jednej odpowiedzialności Symptom 1. Przypadkowa duplikacja Symptom 2. Złączenia Rozwiązania Wnioski Rozdział 8. Reguła otwarte-zamknięte Eksperyment myślowy Kontrola kierunku Ukrywanie informacji Wnioski Rozdział 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 Rozdział 10. Zasada rozdzielania interfejsów Zasada ISP i język Zasada ISP i architektura Wnioski Rozdział 11. Zasada odwrócenia zależności Stabilne abstrakcje Fabryki Komponenty konkretne Wnioski Część IV. Zasady komponentów Rozdział 12. Komponenty Krótka historia komponentów Relokacje Konsolidatory Wnioski Rozdział 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 Rozdział 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 Zasada stabilnych abstrakcji Gdzie umieścić reguły wysokiego poziomu? Wprowadzenie do zasady stabilnych abstrakcji Miara abstrakcji Ciąg główny Unikanie stref wykluczenia Odległość od ciągu głównego Wnioski Część V. Architektura Rozdział 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 Rozdział 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 Rozdział 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 Rozdział 18. Anatomia granic Przekraczanie granic Straszliwy monolit Instalowanie komponentów Wątki Procesy lokalne Usługi Wnioski Rozdział 19. Zasady i poziomy Poziomy Wnioski Rozdział 20. Reguły biznesowe Encje Przypadki użycia Modele żądania i odpowiedzi Wnioski Rozdział 21. Krzycząca architektura Motyw architektury Cel architektury A co z siecią WWW? Framework to narzędzie, a nie styl życia Testowanie architektury Wnioski Rozdział 22. Czysta architektura Zasada zależności Przypadki użycia Adaptery interfejsów Frameworki i sterowniki Tylko cztery kręgi? Przekraczanie granic Jakie dane przekraczają granice? Typowy scenariusz Wnioski Rozdział 23. Prezentery i skromne obiekty Wzorzec projektowy skromny obiekt Prezentery i widoki Testowanie i architektura Bramy do baz danych Mapowanie danych Serwisy Wnioski Rozdział 24. Granice częściowe Pomiń ostatni krok Granice jednowymiarowe Fasady Wnioski Rozdział 25. Warstwy i granice Hunt the Wumpus Czysta architektura? Przekraczanie strumieni Dzielenie strumieni Wnioski Rozdział 26. Komponent Main Najważniejszy detal Wnioski Rozdział 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 Rozdział 28. Granice testów Testy jako komponenty systemu Projekt ułatwiający testy API testujące Rozdzielanie strukturalne Bezpieczeństwo Wnioski Rozdział 29. Czysta architektura osadzona Test n-App-stawienia Problem docelowego sprzętu Czysta architektura osadzona umożliwia testowanie Nie przekazuj szczegółów sprzętowych użytkownikom warstwy HAL Programowanie dla interfejsów i możliwości podmiany Warunkowe dyrektywy kompilatora i zasada DRY Wnioski Część VI. Szczegóły Rozdział 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 Rozdział 31. Sieć WWW jest szczegółem Wieczne wahadło Rezultat Wnioski Rozdział 32. Frameworki są szczegółem Autorzy frameworków Małżeństwo asymetryczne Ryzyko Rozwiązanie Teraz ogłaszam was... Wnioski Rozdział 33. Studium przypadku. Sprzedaż filmów Produkt Analiza przypadków użycia Architektura komponentów Zarządzanie zależnościami Wnioski Rozdział 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 Dodatki 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 Skorowidz