Clean code w Ruby

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

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

Skąd ten cały szum?

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

Zgadzacie się?

Dlaczego warto?

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

Zostaw kod czystszym niż go zastałeś.

Znaczące nazwy

• jeśli nazwa wymaga komenarza nie jest dobrą nazwą: d, af_objects, the_list, a2• unikaj dezinformacji: controller_for_efﬁcient_handling_of_strings vs. controller_for_efﬁcient_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

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)

• 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-ﬂagi są okropne: render(is_suite) lepiej render_for_suite() i render_for_single_test()• Unikaj efektów ubocznych

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

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

• 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

Formatowanie Bądź konsekwentny!

Obiekty i struktury danych

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

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

Obsługa błędów

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

Testowanie

• 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 *

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

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

Systemy• separowanie (rozcięcie) problemów• DCI - Data Context Interaction• DSL - Domain-speciﬁc language

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

Clean code w Ruby

by Rafal Piekarski on Jul 03, 2012

Accessibility

Categories

Upload Details

Usage Rights

2 Embeds 4

Statistics

Clean code w Ruby Presentation Transcript

http://www.linkedin.com	3
https://si0.twimg.com	1