Czysta architektura. Struktura i design oprogramowania. Przewodnik dla profesjonalistów (E-book) Katowice

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 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 O autorze: Robert C. Martin (Wujek Bob) jest programistą od 1970 roku. Jest uznanym mówcą na konferencjach całego świata. Napisał między innymi książki Mistrz czystego kodu. Kodeks postępowania profesjonalnych programistów (Helion, 2013) oraz UML for Java Programmers (Prentice Hall, 2003). Oprócz tego Martin opublikował setki artykułów, rozpraw i wpisów na blogach. Działał jako redaktor naczelny magazynu „The C++ Report” i był pierwszym przewodniczącym organizacji Agile Alliance. Założył i prowadzi międzynarodową firmę Object Mentor Inc., skupiającą doświadczonych programistów i menedżerów specjalizujących się we wspomaganiu firm w realizacji trudnych projektów.