Clean Code w Ruby                 czyli kod musi być CZYSTY!LRUG 3.07.2012                         © Rafał "RaVbaker" Piek...
Kim jestem?•   programista od 8 lat•   znam Ruby/Rails od ponad    5 lat - WorkingWithRails•   ostatnio pracowałem    w po...
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...
Zgadzacie się?
Dlaczego warto?
Agenda• zasada skautów   • obiekty i struktury                     danych• znaczące nazwy                   • obsługa błęd...
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:    controll...
Funkcje• Celem jest aby opowiadały historię systemu• Podstawową regułą jest aby były małe -  mieściły się na jednym (małym...
• Nazwy opisowe i wyjaśniające co się dzieje  z argumentami: include_teardown_page()  check_password(user_name, password)•...
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ń     zakome...
• nie używaj komentarza kiedy możesz to    wyjaśnić kodem:    x = 10 # assigns number 10 to variable x•   komentarze nie n...
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()• o...
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•...
zasada F.I.R.S.T.• Szybkie (Fast)• Niezależne (Independent)• Powtarzalne (Repeatable)• Samokontrolujące się (Self-Validati...
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-specific language
z: single-page-applications-with-coffeescript-polish © Andrzej Krzywda
Dzięki za uwagęmało? Prezentacja Uncle Boba o Clean Code w Ruby
Upcoming SlideShare
Loading in …5
×

Clean code w Ruby

2,724 views

Published on

Czysty kod w Ruby. Prezentacja na LRUG 3.07.2012.

Published in: Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,724
On SlideShare
0
From Embeds
0
Number of Embeds
18
Actions
Shares
0
Downloads
3
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Clean code w Ruby

  1. 1. Clean Code w Ruby czyli kod musi być CZYSTY!LRUG 3.07.2012 © Rafał "RaVbaker" Piekarski
  2. 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. 3. Skąd ten cały szum?
  4. 4. Co to jest czysty kod?• prosty• elegancki• wydajny• czytelny• bez powtórzeń (DRY)• łatwy w rozbudowie• jak dobrze napisana proza
  5. 5. Zgadzacie się?
  6. 6. Dlaczego warto?
  7. 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. 8. Zostaw kod czystszym niż go zastałeś.
  9. 9. Znaczące nazwy
  10. 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. 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. 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. 13. Komentarze Nie komentuj złego kodu - popraw go. Brian w. Kernighan i P. J. Plaugher
  14. 14. 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 #####
  15. 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. 16. Formatowanie Bądź konsekwentny!
  17. 17. Obiekty i struktury danych
  18. 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. 19. ActiveRecord• to struktura danych!• do zasad biznesowych powinny być tworzone osobne obiekty!
  20. 20. Obsługa błędów
  21. 21. • wyjątki zamiast kodów powrotu• osobne klasy wyjątków dla różnych potrzeb• nie zwracamy nil• nie przekazujemy nil
  22. 22. Testowanie
  23. 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. 24. zasada F.I.R.S.T.• Szybkie (Fast)• Niezależne (Independent)• Powtarzalne (Repeatable)• Samokontrolujące się (Self-Validating)• O czasie (Timely)
  25. 25. Klasy• Powinny być małe!• SRP - Zasada pojedyńczej odpowiedzialności• Organizuj zmiany
  26. 26. Systemy• separowanie (rozcięcie) problemów• DCI - Data Context Interaction• DSL - Domain-specific language
  27. 27. z: single-page-applications-with-coffeescript-polish © Andrzej Krzywda
  28. 28. Dzięki za uwagęmało? Prezentacja Uncle Boba o Clean Code w Ruby

×