Reguły programowania. Jak pisać lepszy kod Jelenia Góra

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: Spis treściWstęp Historia reguł Jak nie zgadzać się z przedstawionymi tu regułami 1. Tak proste, jak to możliwe, lecz nie prostszePomiar 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źliweNie 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ówYAGNI 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 optymalizujPierwsza 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ówPrzeglą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łaKrok 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 miejscuProsty 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 konwencjiKonwencje 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 chwastyIdentyfikacja 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 koduPrzykł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ązaniaPrzeskok 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ównoleglePrzeszkody 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 obliczeniaAutomatyzować 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ździeNowy 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 PythonaB. Czytanie kodu C++ dla programistów JavaScriptu O autorze: Chris Zimmerman jest jednym z założycieli studia gier wideo Sucker Punch Productions, które powstało w 1997 roku i kierował jego zespołem programistów w ciągu 25 lat udanej pracy nad wieloma grami wideo, w tym najważniejszą z nich, wydaną w roku 2020 grą Ghost of Tsushima. Przed częściowym wycofaniem się na emeryturę w celu napisania tej książki, Chris dzielił swój czas pomiędzy pisaniem kodu, zarządzaniem zespołem programistów oraz projektowaniem rozgrywek w tworzonych grach.