Czysty kod w Ruby. Prezentacja na LRUG 3.07.2012.

1. Clean Code w Ruby
czyli kod musi być CZYSTY!
LRUG 3.07.2012 © Rafał "RaVbaker" Piekarski

2. Kim jestem?
• programista od 8 lat
• znam Ruby/Rails od ponad
5 lat - WorkingWithRails
• ostatnio pracowałem
w porównywarce Nokaut.pl
• github: ravbaker
• twitter: @ravbaker

3. Skąd ten cały szum?

4. Co to jest czysty kod?
• prosty
• elegancki
• wydajny
• czytelny
• bez powtórzeń (DRY)
• łatwy w rozbudowie
• jak dobrze napisana proza

5. Zgadzacie się?

6. Dlaczego warto?

7. Agenda
• zasada skautów • obiekty i struktury
danych
• znaczące nazwy
• obsługa błędów
• funkcje
• testy jednostkowe
• komentarze
• klasy
• formatowanie
• systemy

8. Zostaw kod czystszym
niż go zastałeś.

9. Znaczące nazwy

10. • jeśli nazwa wymaga komenarza nie jest dobrą
nazwą: d, af_objects, the_list, a2
• unikaj dezinformacji:
controller_for_efficient_handling_of_strings vs.
controller_for_efficient_storage_of_strings
• tworzenie nazw które można wymówić: time_ymdhis
• rzeczowniki (lub wyrażenia rzeczownikowe) dla klas i
czasowniki (lub wyrażenia czasownikowe) dla metod:
AddressParser, Manager, Processor
delete_page, save, wait_until
• nie dodawać nadmiarowego kontekstu:
LSBAccountAddress

11. Funkcje
• Celem jest aby opowiadały historię systemu
• Podstawową regułą jest aby były małe -
mieściły się na jednym (małym) ekranie
• Powinny robić jedną rzecz!
• Zasada zstępująca i nie mieszanie
poziomów abstrakcji
• Nie powtarzaj się! (DRY)

12. • Nazwy opisowe i wyjaśniające co się dzieje
z argumentami: include_teardown_page()
check_password(user_name, password)
• Idealna liczba argumentów to... "zero"
• Więcej niż 3 argumenty nie powinno
być nigdy używane
• Argumenty-flagi są okropne: render(is_suite)
lepiej render_for_suite() i render_for_single_test()
• Unikaj efektów ubocznych

13. Komentarze
Nie komentuj złego kodu - popraw go.
Brian w. Kernighan i P. J. Plaugher

14. Dobre komentarze Złe komentarze
Publiczne API zamknięcia bloków i tagów
wyjaśnienie zamierzeń zakomentowany kod
ostrzeżenia przed
nadmiarowe komentarze
konsekwencjami
komentarze niepublicznych
prawdziwe listy TODO
metod
znaczniki pozycji:
# #### Action #####

15. • nie używaj komentarza kiedy możesz to
wyjaśnić kodem:
x = 10 # assigns number 10 to variable x
• komentarze nie naprawią złego kodu
• licz się z tym, że komentarze mogą zawierać
kłamstwa
• celem komentarzy jest wyjaśnić kod,
który nie wyjaśnia się sam

16. Formatowanie
Bądź konsekwentny!

17. Obiekty i struktury danych

18. Prawo demeter
głosi, że metoda f() klasy C powinna
wywoływać tylko metody z:
•C
• obiektu utworzonego przez f()
• obiektu przekazanego jako argument do f()
• obiektu umieszczonego w zmiennej
instancyjnej klasy C

19. ActiveRecord
• to struktura danych!
• do zasad biznesowych powinny być
tworzone osobne obiekty!

20. Obsługa błędów

21. • wyjątki zamiast kodów powrotu
• osobne klasy wyjątków dla różnych potrzeb
• nie zwracamy nil
• nie przekazujemy nil

22. Testowanie

23. • testy i kod produkcyjny pisany razem!
• staraj się aby testy były czytelne
• testy są tak samo ważne jak kod
produkcyjny
• pamiętaj, mając testy łatwiej refaktorować
• jedna asercja lub koncept na test *

24. zasada F.I.R.S.T.
• Szybkie (Fast)
• Niezależne (Independent)
• Powtarzalne (Repeatable)
• Samokontrolujące się (Self-Validating)
• O czasie (Timely)

25. Klasy
• Powinny być małe!
• SRP - Zasada pojedyńczej odpowiedzialności
• Organizuj zmiany

26. Systemy
• separowanie (rozcięcie) problemów
• DCI - Data Context Interaction
• DSL - Domain-specific language

27. z: single-page-applications-with-coffeescript-polish © Andrzej Krzywda

28. Dzięki za uwagę
mało? Prezentacja Uncle Boba o Clean Code w Ruby