Oprogramowanie łatwe w utrzymaniu

Table of contents

1. Wstęp
   1. Temat tej książki — wytyczne umożliwiające budowanie oprogramowania łatwego w utrzymaniu
   2. Dlaczego należy przeczytać tę książkę
   3. Kto powinien przeczytać tę książkę
   4. Czym nie jest ta książka
   5. Następna książka
   6. O Software Improvement Group
   7. O tym wydaniu
   8. Podobne książki
   9. Konwencje użyte w tej książce
   10. Ogólne nazwy elementów kodu źródłowego
   11. Używanie przykładowego kodu
   12. Podziękowania
2. Rozdział 1. Wprowadzenie
   1. 1.1. Czym jest pielęgnowalność?
      1. Cztery rodzaje działań związanych z pielęgnowaniem oprogramowania
   2. 1.2. Dlaczego pielęgnowalność jest ważna?
      1. Pielęgnowalność ma znaczący wpływ na biznes
      2. Pielęgnowalność ma decydujące znaczenie dla innych charakterystyk jakości
   3. 1.3. Trzy podstawowe zasady, na których oparto wytyczne umieszczone w tej książce
      1. Zasada 1. Pielęgnowalność zyskuje najbardziej dzięki prostym wytycznym
      2. Zasada 2. Pielęgnowalność nie wynika z refleksji i liczy się każdy składnik
      3. Zasada 3. Niektóre naruszenia są gorsze od innych
   4. 1.4. Nieporozumienia związane z pielęgnowalnością
      1. Nieporozumienie: Pielęgnowalność jest zależna od języka programowania
      2. Nieporozumienie: Pielęgnowalność jest zależna od branży
      3. Nieporozumienie: Pielęgnowalność jest tym samym, co brak błędów
      4. Nieporozumienie: Pielęgnowalność ma charakter zerojedynkowy
   5. 1.5. Ocena pielęgnowalności
   6. 1.6. Przegląd wytycznych dotyczących pielęgnowalności
3. Rozdział 2. Pisanie krótkich jednostek kodu
   1. 2.1. Motywacja
      1. Krótkie jednostki łatwiej jest testować
      2. Krótkie jednostki łatwiej jest analizować
      3. Krótkie jednostki łatwiej jest wykorzystywać ponownie
   2. 2.2. Stosowanie wytycznych
      1. Pisanie nowej jednostki
      2. Rozszerzanie jednostki o nową funkcjonalność
      3. Zastosowanie technik refaktorowania w celu zapewnienia zgodności z wytycznymi
         1. Technika refaktorowania: wyodrębnienie metody
         2. Technika refaktorowania: zastąpienie metody obiektem metody
   3. 2.3. Typowe obiekcje wobec pisania krótkich jednostek kodu
      1. Obiekcja: Zwiększenie liczby jednostek pogarsza wydajność działania
      2. Obiekcja: Kod trudniej czytać, gdy jest rozproszony
      3. Obiekcja: Wytyczne nakłaniają do stosowania niewłaściwego formatowania
      4. Obiekcja: Niektórych jednostek nie da się podzielić
      5. Obiekcja: Nie ma żadnej widocznej zalety dzielenia jednostek
   4. 2.4. Więcej na ten temat
4. Rozdział 3. Pisanie prostych jednostek kodu
   1. 3.1. Motywacja
      1. Proste jednostki łatwiej jest modyfikować
      2. Proste jednostki łatwiej jest testować
   2. 3.2. Stosowanie wytycznych
      1. Radzenie sobie z łańcuchami warunków
      2. Radzenie sobie z zagnieżdżeniami
   3. 3.3. Typowe obiekcje wobec pisania prostych jednostek kodu
      1. Obiekcja: Wysoka złożoność jest nie do uniknięcia
      2. Obiekcja: Podział metod wcale nie redukuje złożoności kodu
   4. 3.4. Więcej na ten temat
5. Rozdział 4. Pisanie kodu jeden raz
   1. Rodzaje duplikacji
   2. 4.1. Motywacja
      1. Powielony kod trudniej jest analizować
      2. Powielony kod trudniej jest modyfikować
   3. 4.2. Stosowanie wytycznych
      1. Technika refaktorowania: wyodrębnienie nadklasy
   4. 4.3. Typowe obiekcje wobec unikania duplikowania kodu
      1. Obiekcja: Kopiowanie z innej bazy kodu powinno być dozwolone
      2. Obiekcja: Nieznacznie różniące się wersje — i wynikająca z nich duplikacja — są nie do uniknięcia
      3. Obiekcja: Kod nigdy nie ulegnie zmianie
      4. Obiekcja: Duplikaty całych plików powinny być dozwolone jako kopie zapasowe
      5. Obiekcja: Testy jednostkowe stanowią skuteczne zabezpieczenie
      6. Obiekcja: Duplikacja w literałach znakowych jest nieuchronna i nieszkodliwa
   5. 4.4. Więcej na ten temat
6. Rozdział 5. Ograniczanie wielkości interfejsów jednostek
   1. 5.1. Motywacja
      1. Niewielkie interfejsy łatwiej jest rozumieć i ponownie wykorzystywać
      2. Metody z niewielkimi interfejsami łatwiej jest modyfikować
   2. 5.2. Stosowanie wytycznych
   3. 5.3. Typowe obiekcje wobec ograniczania wielkości interfejsów
      1. Obiekcja: Obiekty parametrów mają duże interfejsy
      2. Obiekcja: Refaktorowanie dużych interfejsów wcale nie poprawia sytuacji
      3. Obiekcja: Frameworki i biblioteki narzucają interfejsy z długimi listami parametrów
   4. 5.4. Więcej na ten temat
7. Rozdział 6. Separowanie zagadnień w modułach
   1. 6.1. Motywacja
      1. Niewielkie, luźno sprzężone moduły umożliwiają programistom pracę nad izolowanymi częściami bazy kodu
      2. Niewielkie, luźno sprzężone moduły ułatwiają nawigację w bazie kodu
      3. Niewielkie, luźno sprzężone moduły uniemożliwiają powstawanie obszarów zabronionych dla nowych programistów
   2. 6.2. Stosowanie wytycznych
      1. Podział klas w celu rozdzielenia zagadnień
      2. Ukrywanie specjalistycznej implementacji za interfejsami
      3. Zastępowanie własnego kodu bibliotekami lub frameworkami zewnętrznymi
   3. 6.3. Typowe obiekcje wobec separowania zagadnień
      1. Obiekcja: Luźne sprzężenie kłóci się z ponownym wykorzystaniem
      2. Obiekcja: Interfejsy języka Java nie służą jedynie do zapewniania luźnego sprzężenia
      3. Obiekcja: Wysoka liczba wywołań klas narzędziowych jest nie do uniknięcia
      4. Obiekcja: Nie wszystkie rozwiązania zapewniające luźne sprzężenie zwiększają pielęgnowalność
8. Rozdział 7. Luźne sprzęganie komponentów architektonicznych
   1. 7.1. Motywacja
      1. Niska zależność między komponentami umożliwia izolowane pielęgnowanie
      2. Niska zależność między komponentami zapewnia separację odpowiedzialności związanych z pielęgnacją
      3. Niska zależność między komponentami ułatwia testowanie
   2. 7.2. Stosowanie wytycznych
      1. Wzorzec projektowy fabryki abstrakcyjnej
   3. 7.3. Typowe obiekcje wobec luźnego sprzęgania komponentów
      1. Obiekcja: Zależności komponentów nie da się naprawić, ponieważ komponenty są splecione
      2. Obiekcja: Nie ma czasu na naprawy
      3. Obiekcja: Przepustowość jest wymagana
   4. 7.4. Więcej na ten temat
9. Rozdział 8. Równoważenie architektury komponentów
   1. 8.1. Motywacja
      1. Dobra równowaga komponentów ułatwia znajdowanie i analizowanie kodu
      2. Dobra równowaga komponentów zapewnia lepszą izolację skutków pielęgnacji
      3. Dobra równowaga komponentów zapewnia separację odpowiedzialności związanych z pielęgnacją
   2. 8.2. Stosowanie wytycznych
      1. Decydowanie na odpowiednim poziomie koncepcyjnym o łączeniu funkcjonalności w komponenty
      2. Wyjaśnienie dziedzin systemu i konsekwentne stosowanie się do nich
   3. 8.3. Typowe obiekcje wobec równoważenia komponentów
      1. Obiekcja: Nierównowaga komponentów sprawdza się całkiem dobrze
      2. Obiekcja: Splątanie pogarsza równowagę komponentów
   4. 8.4. Więcej na ten temat
10. Rozdział 9. Ograniczanie wielkości bazy kodu
    1. 9.1. Motywacja
       1. Projekt, którego baza kodu mocno się rozrasta, niesie ze sobą większe ryzyko porażki
       2. Wielkie bazy kodu trudniej jest pielęgnować
       3. Wielkie systemy mają większą gęstość defektów
    2. 9.2. Stosowanie wytycznych
       1. Środki funkcjonalne
       2. Środki techniczne
    3. 9.3. Typowe obiekcje wobec ograniczania wielkości bazy kodu
       1. Obiekcja: Zmniejszenie wielkości bazy kodu jest utrudniane przez miary produktywności
       2. Obiekcja: Zmniejszenie wielkości bazy kodu jest utrudniane przez język programowania
       3. Obiekcja: Złożoność systemu wymusza kopiowanie kodu
       4. Obiekcja: Podział bazy kodu jest niemożliwy z uwagi na architekturę platformy
       5. Obiekcja: Podział bazy kodu prowadzi do duplikacji
       6. Obiekcja: Podział bazy kodu jest niemożliwy z powodu ciasnego sprzężenia
11. Rozdział 10. Automatyzowanie testów
    1. 10.1. Motywacja
       1. Testy automatyczne sprawiają, że testowanie jest powtarzalne
       2. Testy automatyczne sprawiają, że programowanie jest wydajne
       3. Testy automatyczne sprawiają, że kod jest przewidywalny
       4. Testy dokumentują kod, który jest im poddany
       5. Pisanie testów sprawia, że tworzy się lepszy kod
    2. 10.2. Stosowanie wytycznych
       1. Rozpoczęcie pracy z testami w jUnit
       2. Ogólne reguły pisania dobrych testów jednostkowych
       3. Mierzenie pokrycia w celu określenia, czy zapewniona została wystarczająca ilość testów
    3. 10.3. Typowe obiekcje wobec automatyzacji testów
       1. Obiekcja: Nadal istnieje potrzeba testów manualnych
       2. Obiekcja: Nie wolno mi pisać testów jednostkowych
       3. Obiekcja: Dlaczego należy inwestować w testy jednostkowe, gdy bieżące pokrycie jest niskie?
    4. 10.4. Więcej na ten temat
12. Rozdział 11. Pisanie czystego kodu
    1. 11.1. Niepozostawianie śladów
    2. 11.2. Stosowanie wytycznych
       1. Reguła 1. Nie pozostawiaj za sobą zapachów kodu na poziomie jednostki
       2. Reguła 2. Nie pozostawiaj za sobą złych komentarzy
       3. Reguła 3. Nie pozostawiaj za sobą kodu w komentarzach
       4. Reguła 4. Nie pozostawiaj za sobą martwego kodu
          1. Nieosiągalny kod w metodach
          2. Nieużywane metody prywatne
          3. Kod w komentarzach
       5. Reguła 5. Nie pozostawiaj za sobą długich nazw identyfikatorów
       6. Reguła 6. Nie pozostawiaj za sobą magicznych stałych
       7. Reguła 7. Nie pozostawiaj za sobą źle obsłużonych wyjątków
    3. 11.3. Typowe obiekcje wobec pisania czystego kodu
       1. Obiekcja: Komentarze stanowią naszą dokumentację
       2. Obiekcja: Obsługa wyjątków powoduje zwiększenie ilości kodu
       3. Obiekcja: Dlaczego wytycznych dotyczących programowania jest tylko tyle?
13. Rozdział 12. Następne kroki
    1. 12.1. Przejście od wytycznych do praktyki
    2. 12.2. Wytyczne niskopoziomowe (dotyczące jednostek) mają pierwszeństwo przed wytycznymi wysokopoziomowymi (dotyczącymi komponentów)
    3. 12.3. Każdy komit się liczy
    4. 12.4. Najlepsze praktyki w procesie tworzenia oprogramowania są opisane w kolejnej książce
14. Dodatek A Sposób mierzenia pielęgnowalności wykorzystywany przez SIG
    1. O autorach
    2. Kolofon