M

Zobacz 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

Reguły programowania. Jak pisać lepszy kod -- spis treści

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