Reguły programowania. Jak pisać lepszy kod - ebook

Młody programista szybko sobie uzmysławia, że opanowanie języka programowania nie oznacza umiejętności pisania dobrego kodu. Zanim się jej nabędzie, trzeba spędzić wiele bezsennych nocy na próbach usunięcia błędów czy rozwiązania innych problemów. Programowanie jest po prostu trudną sztuką. Czy istnieje sposób, aby choć trochę ją ułatwić?

W książce znajdziesz inspirujące spostrzeżenia zarówno dla początkującyc, jak i doświadczonych programistów!

Paul Daugherty, Group Chief Executive of Technology i CTO, Accenture

Właśnie w tym celu powstał ten przewodnik po filozofii oprogramowania. Znajdziesz w nim 21 pragmatycznych reguł, którymi kierują się najlepsi programiści. Dzięki spostrzeżeniom zawartym w książce zmienisz podejście do programowania i szybko się przekonasz, że pozwoli Ci to na pisanie lepszego, czytelniejszego i niezawodnego kodu. Poszczególne reguły zostały zilustrowane jego rzeczywistymi przykładami, ułatwiającymi zrozumienie prezentowanych treści. Ten zajmująco i zabawnie napisany przewodnik nie tylko zainspiruje Cię do programistycznego rozwoju, ale również będzie nieocenioną pomocą przy szkoleniu nowych członków zespołu.

Poznaj reguły, którymi kierują się najlepsi:

• Tak prosty, jak to możliwe, ale nie prostszy
• Pierwsza lekcja optymalizacji: nie optymalizuj
• Błędy są zaraźliwe
• Kod, który nie jest wykonywany, nie działa
• I wiele innych!

Oto świetne wskazówki dla początkujących i subtelne lekcje dla ekspertów!

Mark Cerny, Lead System Architect, PlayStation 4 i 5

Spis treści

Wstęp

Historia reguł

Jak nie zgadzać się z przedstawionymi tu regułami

1. Tak proste, jak to możliwe, lecz nie prostsze

• Pomiar prostoty
• .ale nie prostszy
• Czasami lepiej jest uprościć problem niż rozwiązanie
• Proste algorytmy
• Nie trać z oczu celu
• Jedna reguła, by rządzić innymi

2. Błędy są zaraźliwe

• Nie polegaj na swoich użytkownikach
• Zautomatyzowane testy mogą być kłopotliwe
• Kod bezstanowy jest łatwiejszy do testowania
• Badaj stan, którego nie możesz wyeliminować
• Nie ufaj kodowi wywołującemu
• Dbanie o poprawność kodu

3. Dobra nazwa jest najlepszą dokumentacją

• Nie optymalizuj nazw pod kątem długości
• Nie mieszaj konwencji
• Nie strzelaj sobie samemu w stopę
• Nie zmuszaj mnie do myślenia

4. Uogólnianie wymaga trzech przykładów

• YAGNI
• Oczywisty zarzut wobec tej strategii, w odpowiedzi na który powtórzę to samo
• Pisanie kodu na wyrost to jeszcze pół biedy.
• Nie tak wygląda sukces

5. Pierwsza lekcja optymalizacji: nie optymalizuj

• Pierwsza lekcja optymalizacji
• Druga lekcja optymalizacji
• Sprawdzanie drugiej lekcji optymalizacji
• Stosowanie pięcioetapowego procesu optymalizacji
• Nie ma żadnej trzeciej lekcji optymalizacji

Przerywnik, w którym poprzedni rozdział zostaje poddany krytyce

6. Przeglądy kodu są dobre z trzech powodów

• Przeglądy kodu służą dzieleniu się wiedzą
• Zabronione przeglądy kodu
• Prawdziwa wartość przeglądów kodu
• Przeglądy kodu mają społeczny charakter

7. Eliminuj przypadki niepowodzeń

• Funkcja, która ułatwia strzał w stopę
• Strzelanie sobie w stopę rykoszetem
• Skorzystanie z pomocy kompilatora, by uniknąć strzelania sobie w stopę
• Wyczucie czasu jest kluczowe
• Bardziej skomplikowany przykład
• Uniemożliwianie popełniania błędów związanych z kolejnością
• Stosowanie szablonów zamiast sekwencji wywołań metod
• Skoordynowana kontrola stanu
• Wykrywanie błędów jest dobre, ale jeszcze lepsze jest uniemożliwienie wyrażenia ich w kodzie

8. Kod, który nie jest wykonywany, nie działa

• Krok 1. Prosty początek
• Krok 2. Uogólnienie częstego wzorca
• Krok 3. Dodawanie przebrań
• Krok 4. Przyszła kryska na Matyska
• Kogo obwinić?
• Ograniczenia testowania

9. Pisz kod, który można zwijać

• Tak smakuje niepowodzenie
• Rola pamięci krótkotrwałej
• Gdzie narysować linię?
• Koszt abstrakcji
• Używaj abstrakcji, by ułatwiać zrozumienie kodu
• Znaczenie pamięci długotrwałej
• Wiedza powszechna jest darmowa, nowe koncepcje są kosztowne
• Łącząc wszystko w całość

10. Gromadź złożoność w jednym miejscu

• Prosty przykład
• Ukrywanie szczegółów wewnętrznych
• Rozproszony stan a złożoność
• Zdolny do działania?
• Widać jak przez mgłę
• Ponowne przemyślenie podejścia
• Złożoność w jednym miejscu - proste interakcje

11. Czy to jest dwa razy lepsze?

• Trzy ścieżki ku przyszłości: ignoruj, ulepszaj, refaktoryzuj
• Stopniowa ewolucja czy też ciągła rekonstrukcja
• Prosta zasada
• Radzenie sobie z niejasnymi korzyściami
• Przeróbka jest dobrą okazją do rozwiązywania drobnych problemów

12. Duże zespoły wymagają silnych konwencji

• Konwencje formatowania
• Konwencje użycia języka
• Konwencje rozwiązywania problemów
• Efektywne zespoły myślą podobnie

13. Znajdź kamyk, który wywołał lawinę

• Cykl życia błędu
• Minimalizacja stanu
• Radzenie sobie ze stanem, którego nie można uniknąć
• Radzenie sobie z nieuniknionym opóźnieniem

14. Istnieją cztery rodzaje kodu

• Łatwy problem, proste rozwiązanie
• Łatwy problem, trzy skomplikowane rozwiązania
• Koszt złożoności
• Cztery (choć w zasadzie trzy) rodzaje programistów
• Trudny problem, nieco skomplikowane rozwiązania, które nie działają
• Trudny problem, nieco skomplikowane rozwiązanie
• Trudny problem, łatwe rozwiązanie

15. Wyrwij chwasty

• Identyfikacja chwastów
• Jak w kodzie pojawiają się chwasty?

16. Kiedy rozwiązujesz problem, cofaj się i zaczynaj od wyniku, zamiast iść wprzód i wychodzić od kodu

• Przykład
• Pojawia się irytacja
• Wybór jednej ze stron
• Rozwiązuj problem, podążając wstecz
• A teraz coś zupełnie innego
• Praca poprzez podążanie wprzód lub wstecz

17. Czasami duży problem jest łatwiejszy do rozwiązania

• Przeskok do wniosków
• Znajdowanie czystej drogi do przodu
• Rozpoznanie możliwości

18. Niech Twój kod opowie własną historię

• Nie opowiadaj nieprawdziwych historii
• Upewnij się, że historia będzie mieć sens
• Opowiadanie dobrych historii

19. Przerabiaj równolegle

• Przeszkody na drodze
• Zamiast tego utwórz równoległy system
• Konkretny przykład
• Alokacja korzystająca ze stosu w praktyce
• Chmura na horyzoncie
• Nieco bardziej sprytne konteksty stosu
• Przejście ze starych kontekstów stosu na nowe
• Przygotowania do migracji do klasy StackVector
• Czas migrować
• Rozpoznawanie, kiedy równoległe przerabianie jest dobrą strategią

20. Wykonaj obliczenia

• Automatyzować czy nie automatyzować?
• Poszukaj twardych ograniczeń
• Kiedy obliczenia się zmieniają
• Kiedy problem obliczeń ponownie staje się problemem Worda

21. Czasami będziesz musiał po prostu wbić gwoździe

• Nowy argument
• To nigdy nie jest tylko jeden błąd
• Syreni zew automatyzacji
• Zarządzanie wielkością plików
• Nie ma żadnych skrótów

Wniosek: działaj na własnych zasadach

• Użyj swojego najlepszego osądu
• Przedyskutujcie to między sobą
• Wypisuję się

A. Czytanie kodu C++ dla programistów Pythona

B. Czytanie kodu C++ dla programistów JavaScriptu