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