Решение на Пета задача от Емануела Моллова

Обратно към всички решения

Към профила на Емануела Моллова

Резултати

  • 6 точки от тестове
  • 3 бонус точки
  • 9 точки общо
  • 0 успешни тест(а)
  • 0 неуспешни тест(а)

Код

REPOSITORY = 'http://github.com/EmanuelaMollova/ruby-retrospective-3'
# Двадесет неща, които научих.
#
# 1. Да се обръща повече внимание на именуването и да се проверяват в речник
# търсените думи, ако не сме сигурни (знаменател е denominator, не denumerator).
# 2. Винаги да се търси ситуация, в която кодът ни няма да работи както очакваме.
# 3. Като аргумент на map, reduce, select, ... може да се подава и име на метод,
# вместо блок.
# 4. В Ruby има много полезни и интересни методи - почти винаги може да се намери
# някой, който да ни свърши работа (например each_with_object, all?, chars и
# др.), вместо да го пишем сами.
# 5. По-четимо е, ако присвояването на променливите е на отделни редове, а не с
# паралелно присвояване.
# 6. Splat аргументът позволява по-елегантни решения на някои проблеми.
# 7. Да се избягва изполването на мутиращи методи - в повечето случаи е по-добре
# да се използва map без мутиращ метод, отколкото each с мутиращ.
# 8. Всеки клас трябва да е отговорен само за едно нещо и в него не трябва да има
# методи, които не са свързани с това нещо. (Single responsibility)
# 9. Когато има повече класови методи, се използва class << self.
# 10. За намиране колко елемента в масив отговарят на дадено условие, може да се
# използва count, вместо select и size.
# 11. Трябва да се внимава да няма излишно дублиране на код. (DRY)
# 12. За имплементиране на each освен { |item| yield(item) }, може да се използва
# и &block.
# 13. Да не се дава повече достъп, отколкото е нужно - ако може е по-добре да се
# използва само attr_reader или attr_writer, вместо attr_accessor.
# 14. Хубаво е да се използва freeze за константи, ако искаме да сме сигурни, че
# няма да се променят.
# 15. Heredoc е полезен, когато имаме дълги низове.
# 16. Ако телата на няколко метода са почти еднакви и имат само малки разлики,
# общата част може да се отдели в друг метод, или да се използва define_method.
# 17. За предпочитане е да се използва public_send пред send, когато ще трябва
# да се викат само публични методи.
# 18. На send/public_send може да се подаде направо масив от името и аргументите,
# използвайки splat.
# 19. Стриктното спазване на конвенции и стил е много важно.
# 20. Писането на тестове е много полезно - спестява време от ръчно тестване,
# помага за откриване на бъгове и гарантира, че като правим промени няма да
# развалим нещо, което преди е работело.

История (1 версия и 1 коментар)

Емануела обнови решението на 22.01.2014 03:35 (преди около 10 години)

+REPOSITORY = 'http://github.com/EmanuelaMollova/ruby-retrospective-3'
+
+# Двадесет неща, които научих.
+#
+# 1. Да се обръща повече внимание на именуването и да се проверяват в речник
+# търсените думи, ако не сме сигурни (знаменател е denominator, не denumerator).
+# 2. Винаги да се търси ситуация, в която кодът ни няма да работи както очакваме.
+# 3. Като аргумент на map, reduce, select, ... може да се подава и име на метод,
+# вместо блок.
+# 4. В Ruby има много полезни и интересни методи - почти винаги може да се намери
+# някой, който да ни свърши работа (например each_with_object, all?, chars и
+# др.), вместо да го пишем сами.
+# 5. По-четимо е, ако присвояването на променливите е на отделни редове, а не с
+# паралелно присвояване.
+# 6. Splat аргументът позволява по-елегантни решения на някои проблеми.
+# 7. Да се избягва изполването на мутиращи методи - в повечето случаи е по-добре
+# да се използва map без мутиращ метод, отколкото each с мутиращ.
+# 8. Всеки клас трябва да е отговорен само за едно нещо и в него не трябва да има
+# методи, които не са свързани с това нещо. (Single responsibility)
+# 9. Когато има повече класови методи, се използва class << self.
+# 10. За намиране колко елемента в масив отговарят на дадено условие, може да се
+# използва count, вместо select и size.
+# 11. Трябва да се внимава да няма излишно дублиране на код. (DRY)
+# 12. За имплементиране на each освен { |item| yield(item) }, може да се използва
+# и &block.
+# 13. Да не се дава повече достъп, отколкото е нужно - ако може е по-добре да се
+# използва само attr_reader или attr_writer, вместо attr_accessor.
+# 14. Хубаво е да се използва freeze за константи, ако искаме да сме сигурни, че
+# няма да се променят.
+# 15. Heredoc е полезен, когато имаме дълги низове.
+# 16. Ако телата на няколко метода са почти еднакви и имат само малки разлики,
+# общата част може да се отдели в друг метод, или да се използва define_method.
+# 17. За предпочитане е да се използва public_send пред send, когато ще трябва
+# да се викат само публични методи.
+# 18. На send/public_send може да се подаде направо масив от името и аргументите,
+# използвайки splat.
+# 19. Стриктното спазване на конвенции и стил е много важно.
+# 20. Писането на тестове е много полезно - спестява време от ръчно тестване,
+# помага за откриване на бъгове и гарантира, че като правим промени няма да
+# развалим нещо, което преди е работело.
wow
  Much рефакторинг

     such решения
   so git log
          wow

С други думи, много добре. Бележки:

  • Изпуснала си интервал след запетаята на ред 3 в трета задача: attr_reader :width,:height :)
  • Аз все пак бих изнесъл HTML кода в константи, а не бих го държал в метода render на HTML-рендерера, за по-добра четимост и по-добра скорост. Когато низът се дефинира в метода, при всяко извикване на този метод, тези низове се създават и впоследствие се garbage collect-ват. Ако ще викаш този render метод многократно, твоята имплементация не е много оптимална. В тази задача това е без значение, но го казвам, за да го имаш предвид принципно.