Reguły programowania. Jak pisać lepszy kod - Chris Zimmerman

Opis produktu: Reguły programowania. Jak pisać lepszy kod - Chris Zimmerman

Książka będąca esencją doświadczeń i spostrzeżeń, którymi kierują się najlepsi programiści. Dzięki tej publikacji dowiesz się jak skutecznie ułatwić proces tworzenia wysokiej jakości kodu. Autor opierając się na swojej wiedzy i praktyce, prezentuje 21 pragmatycznych reguł, które są kluczowe dla efektywnego i niezawodnego programowania. Zawarte w książce zasady nie tylko pomagają w pisaniu lepszego kodu, ale również zmieniają podejście do procesu programowania. Autor podkreśla, że skuteczne programowanie wymaga nie tylko znajomości języka programowania, ale także umiejętności logicznego myślenia, rozwiązywania problemów i komunikacji. Dlatego też każda reguła jest opatrzona praktycznymi wskazówkami, które pomogą Ci rozwijać te kluczowe umiejętności.

Reguły programowania. Jak pisać lepszy kod - Chris Zimmerman.

Książka, która prezentuje 21 reguł stosowanych przez najlepszych programistów.

Dla kogo jest ta książka?

Ta publikacja jest świetnym wyborem nie tylko dla początkujących. Zawiera ona również porady dla doświadczonych programistów, którzy chcą doskonalić swoje umiejętności i podejście do pracy. Dzięki temu jest to lektura odpowiednia dla wszystkich, którzy pragną rozwijać się w sztuce programowania.

O Autorze

Chris Zimmerman, jeden z założycieli Sucker Punch Productions - studia gier wideo istniejącego od 1997 roku, przewodził zespołowi programistów przez 25 lat, pracując nad wieloma tytułami, w tym przełomową grą "Ghost of Tsushima" z 2020 roku. Przed przejściem na emeryturę w celu napisania tej książki, skupiał się na pisaniu kodu, zarządzaniu zespołem i projektowaniu rozgrywki w tworzonych grach.

Informacje o książce

• Tytuł oryginału: The Rules of Programming: How to Write Better Code
• Autor: Chris Zimmerman
• Tłumaczenie: Piotr Rajca
• ISBN: 978-83-289-0130-8
• Rok wydania: 2023
• Format: 165 x 235 mm
• Oprawa: miękka
• Liczba stron: 312
• Wydawca: Helion S.A.

Książka ułatwi Ci proces tworzenia wysokiej jakości kodu.

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