Oprogramowanie łatwe w utrzymaniu. Pisz kod podatny na przyszłe zmiany - Helion
Tytuł oryginału: Building Maintainable Software, Java Edition: Ten Guidelines for Future-Proof Code
Tłumaczenie: Łukasz Suma
ISBN: 978-83-283-2843-3
stron: 200, Format: 140x208, okładka: miękka
Data wydania: 2016-12-06
Księgarnia: Helion
Cena książki: 39,90 zł
Oprogramowanie po wdrożeniu w środowisku produkcyjnym dalej wymaga opieki programisty. Aktualizacje, dostosowanie do zmian, udoskonalenia i poprawa usterek — te czynności są warunkiem utrzymania systemu w dobrej kondycji. Niestety, jeśli twórca oprogramowania nie przestrzegał pewnych zasad, pielęgnacja kodu jest uciążliwa, nieefektywna, a bywa nawet, że niemożliwa do wykonania. System przestaje działać ze wszystkimi tego konsekwencjami.
Aby tego uniknąć, wystarczy na etapie tworzenia kodu uwzględniać potrzebę jego utrzymywania w przyszłości. Niniejsza książka jest lekturą obowiązkową dla wszystkich, którzy chcą tworzyć kod łatwy w pielęgnacji. Na jej kartach przedstawiono dziesięć wytycznych prowadzących do tego celu. Wytyczne te zostały gruntownie omówione, a ich znaczenie i sposób stosowania w praktyce wyjaśniono, posługując się przykładowymi fragmentami kodu. Kod ten napisano w Javie, jednak książka okaże się przydatna również dla programistów używających innych języków.
W książce przedstawiono następujące zagadnienia:
- pielęgnacja kodu i jej znaczenie dla poprawnego działania systemu,
- pielęgnowalność kodu i sposoby jej oceny,
- dziesięć wytycznych tworzenia kodu łatwego w pielęgnacji,
- wskazówki i wyjaśnienia dotyczące stosowania wytycznych w praktyce,
- typowe obiekcje wobec stosowania wytycznych i argumenty za ich wykorzystaniem.
Profesjonalny programista zawsze pisze kod najwyższej jakości!
Joost Visser jest profesorem na Uniwersytecie im. Radbouda w Nijmegen. Zajmuje się programowaniem generycznym, zieloną informatyką, a także jakością i ewolucją oprogramowania.
Pascal van Eck zajmuje się jakością oprogramowania. Jest autorem ponad 80 publikacji dotyczących bezpieczeństwa IT i metryk oprogramowania.
Rob van der Leek jest konsultantem do spraw jakości oprogramowania. Bierze również udział w tworzeniu narzędzi do analizy programów.
Sylvan Rigal zajmuje się jakością oprogramowania i prowadzi szkolenia z analizy ryzyk bezpieczeństwa programów.
Gijs Wijnholds pracuje nad jakością oprogramowania w administracji publicznej. Jest ekspertem od Haskella i lingwistyki matematycznej.
Osoby które kupowały "Oprogramowanie łatwe w utrzymaniu. Pisz kod podatny na przyszłe zmiany", wybierały także:
- Superinteligencja. Scenariusze, strategie, zagro 66,67 zł, (14,00 zł -79%)
- Poradnik design thinking - czyli jak wykorzysta 48,28 zł, (14,00 zł -71%)
- Kosymulacja. Elastyczne projektowanie i symulacja wielodomenowa 38,39 zł, (11,90 zł -69%)
- F# 4.0 dla zaawansowanych. Wydanie IV 96,45 zł, (29,90 zł -69%)
- Systemy reaktywne. Wzorce projektowe i ich stosowanie 65,31 zł, (20,90 zł -68%)
Spis treści
Oprogramowanie łatwe w utrzymaniu. Pisz kod podatny na przyszłe zmiany -- spis treści
Wstęp (7)
1. Wprowadzenie (21)
- 1.1. Czym jest pielęgnowalność? (22)
- 1.2. Dlaczego pielęgnowalność jest ważna? (23)
- 1.3. Trzy podstawowe zasady, na których oparto wytyczne umieszczone w tej książce (25)
- 1.4. Nieporozumienia związane z pielęgnowalnością (28)
- 1.5. Ocena pielęgnowalności (30)
- 1.6. Przegląd wytycznych dotyczących pielęgnowalności (32)
2. Pisanie krótkich jednostek kodu (35)
- 2.1. Motywacja (38)
- 2.2. Stosowanie wytycznych (39)
- 2.3. Typowe obiekcje wobec pisania krótkich jednostek kodu (47)
- 2.4. Więcej na ten temat (52)
3. Pisanie prostych jednostek kodu (55)
- 3.1. Motywacja (61)
- 3.2. Stosowanie wytycznych (62)
- 3.3. Typowe obiekcje wobec pisania prostych jednostek kodu (67)
- 3.4. Więcej na ten temat (68)
4. Pisanie kodu jeden raz (71)
- 4.1. Motywacja (76)
- 4.2. Stosowanie wytycznych (77)
- 4.3. Typowe obiekcje wobec unikania duplikowania kodu (82)
- 4.4. Więcej na ten temat (86)
5. Ograniczanie wielkości interfejsów jednostek (89)
- 5.1. Motywacja (92)
- 5.2. Stosowanie wytycznych (93)
- 5.3. Typowe obiekcje wobec ograniczania wielkości interfejsów (98)
- 5.4. Więcej na ten temat (99)
6. Separowanie zagadnień w modułach (101)
- 6.1. Motywacja (106)
- 6.2. Stosowanie wytycznych (107)
- 6.3. Typowe obiekcje wobec separowania zagadnień (111)
7. Luźne sprzęganie komponentów architektonicznych (115)
- 7.1. Motywacja (117)
- 7.2. Stosowanie wytycznych (121)
- 7.3. Typowe obiekcje wobec luźnego sprzęgania komponentów (123)
- 7.4. Więcej na ten temat (125)
8. Równoważenie architektury komponentów (129)
- 8.1. Motywacja (130)
- 8.2. Stosowanie wytycznych (133)
- 8.3. Typowe obiekcje wobec równoważenia komponentów (134)
- 8.4. Więcej na ten temat (135)
9. Ograniczanie wielkości bazy kodu (139)
- 9.1. Motywacja (140)
- 9.2. Stosowanie wytycznych (142)
- 9.3. Typowe obiekcje wobec ograniczania wielkości bazy kodu (146)
10. Automatyzowanie testów (151)
- 10.1. Motywacja (153)
- 10.2. Stosowanie wytycznych (155)
- 10.3. Typowe obiekcje wobec automatyzacji testów (167)
- 10.4. Więcej na ten temat (169)
11. Pisanie czystego kodu (171)
- 11.1. Niepozostawianie śladów (171)
- 11.2. Stosowanie wytycznych (172)
- 11.3. Typowe obiekcje wobec pisania czystego kodu (179)
12. Następne kroki (181)
- 12.1. Przejście od wytycznych do praktyki (181)
- 12.2. Wytyczne niskopoziomowe (dotyczące jednostek) mają pierwszeństwo przed wytycznymi wysokopoziomowymi (dotyczącymi komponentów) (182)
- 12.3. Każdy komit się liczy (182)
- 12.4. Najlepsze praktyki w procesie tworzenia oprogramowania są opisane w kolejnej książce (183)
A. Sposób mierzenia pielęgnowalności wykorzystywany przez SIG (185)
Skorowidz (189)