Решение на Четвърта задача от Ростислав Георгиев

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

Към профила на Ростислав Георгиев

Резултати

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

Код

REPOSITORY = 'https://github.com/rosti/ruby-retrospective-1'
# Двадесет неща, които научих:
#
# 1. Да си пускам официалния тест преди да качвам задача (Задача 2)
# 2. Да си чета условието на задачата. Така на втора задача съм пропуснал това,
# че трябва да преобразувам жанра и поджанра в тагове.
# 3. Да преглеждам внимателно преди да качвам решение. Така на задача 2 съм качил
# решение на което на едно място има ненужно добавена (по невнимание) @ пред
# една от локалните променливи.
# 4. Enumerable#map е хубаво нещо с което да заменя грозни each конструкции или
# неща, които се повтарят (като strip-ове на отделни елементи от масив)
# 5. Enumerable#all още едно хубаво нещо с което да заменя един от грозните each-ове
# в задача 2.
# 6. then-a в многоредов if е излишен
# 7. Feature Envy code smell (в задача 2)
# 8. obj.kind_of? String е по-добре от колкото obj.class == String
# 9. и въобще не е добре в Ruby да се проверява един обект дали е String.
# В конкретния пример от задача 2 този код може да се счупи ако ни подадът Symbol
# и за това беше по-добре да се провери за Array
# 10. И въобще това е Duck Typing. Няма нужда да проверяваме тип, като можем просто
# да прекараме нещото през един Array() и да го сведем до масив.
# 11. Въпреки, че нямам tuple като в Python, мога да съкратя 3 реда от този код:
#
# some_arr = do_stuff.that_outputs_arr
# @genre = some_arr[0]
# @subgenre = some_arr[1] if some_arr[1]
#
# до този един ред:
# @genre, @subgenre = do_stuff.that_outputs_arr
#
# 12. В Ruby BigDecimal бил типът за работа с числа с голяма прецизност. Ако не беше
# тази подсказка щях да съм му "праснал" един float/double. Въпреки това милиони
# потребители по света си смятат финансите с едно програма за електронни таблици,
# която като й дадеш да сметне 65535+1, тя го изкарва към един милион.
# 13. Трябва да се внимава до какво се оценяват редовете в една функция при връщане. Така
# например можем да съкртим последния ред от следния код, защото той се оценява по
# същия начин както и предпоследния и това го прави излишен:
#
# result = some_stuff
# result << other_stuff if other_stuff
# result
#
# Въпреки това на някои места подобен код не бива да се маха.
#
# 14. По-добре да ползваме по-простия и по-сигурен модел на това да си наредим промоциите
# и купоните в един хеш, отколкото да правим извратени неща от рода на Object.const_get
# 15. for/while и т.н. трябва да се избягват в Ruby, защото са неподходящи в XXI-ви век в
# език като Ruby.
# 16. Модулите са далеч по-приятно нещо, отколкото класове с изцяло статични константи и
# функции (ала Java например)
# 17. and и && имат различни приоритети
# 18. постфиксния синтаксис на if/unless е много хубаво нещо. Позволява съкращаване на кода
# и по-добра разбираемост.
# 19. Неща като attr_* и unless са готини при положение, че ги няма или рядко се срещат в
# другите езици за програмиране
# 20. В повечето случаи проверки за nil са грозни и могат да се заменят с нещо по-добро.

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

Ростислав обнови решението на 13.11.2011 23:26 (преди над 12 години)

+REPOSITORY = 'https://github.com/rosti/ruby-retrospective-1'
+
+# Двадесет неща, които научих:
+#
+# 1. Да си пускам официалния тест преди да качвам задача (Задача 2)
+# 2. Да си чета условието на задачата. Така на втора задача съм пропуснал това,
+# че трябва да преобразувам жанра и поджанра в тагове.
+# 3. Да преглеждам внимателно преди да качвам решение. Така на задача 2 съм качил
+# решение на което на едно място има ненужно добавена (по невнимание) @ пред
+# една от локалните променливи.
+# 4. Enumerable#map е хубаво нещо с което да заменя грозни each конструкции или
+# неща, които се повтарят (като strip-ове на отделни елементи от масив)
+# 5. Enumerable#all още едно хубаво нещо с което да заменя един от грозните each-ове
+# в задача 2.
+# 6. then-a в многоредов if е излишен
+# 7. Feature Envy code smell (в задача 2)
+# 8. obj.kind_of? String е по-добре от колкото obj.class == String
+# 9. и въобще не е добре в Ruby да се проверява един обект дали е String.
+# В конкретния пример от задача 2 този код може да се счупи ако ни подадът Symbol
+# и за това беше по-добре да се провери за Array
+# 10. И въобще това е Duck Typing. Няма нужда да проверяваме тип, като можем просто
+# да прекараме нещото през един Array() и да го сведем до масив.
+# 11. Въпреки, че нямам tuple като в Python, мога да съкратя 3 реда от този код:
+#
+# some_arr = do_stuff.that_outputs_arr
+# @genre = some_arr[0]
+# @subgenre = some_arr[1] if some_arr[1]
+#
+# до този един ред:
+# @genre, @subgenre = do_stuff.that_outputs_arr
+#
+# 12. В Ruby BigDecimal бил типът за работа с числа с голяма прецизност. Ако не беше
+# тази подсказка щях да съм му "праснал" един float/double. Въпреки това милиони
+# потребители по света си смятат финансите с едно програма за електронни таблици,
+# която като й дадеш да сметне 65535+1, тя го изкарва към един милион.
+# 13. Трябва да се внимава до какво се оценяват редовете в една функция при връщане. Така
+# например можем да съкртим последния ред от следния код, защото той се оценява по
+# същия начин както и предпоследния и това го прави излишен:
+#
+# result = some_stuff
+# result << other_stuff if other_stuff
+# result
+#
+# Въпреки това на някои места подобен код не бива да се маха.
+#
+# 14. По-добре да ползваме по-простия и по-сигурен модел на това да си наредим промоциите
+# и купоните в един хеш, отколкото да правим извратени неща от рода на Object.const_get
+# 15. for/while и т.н. трябва да се избягват в Ruby, защото са неподходящи в XXI-ви век в
+# език като Ruby.
+# 16. Модулите са далеч по-приятно нещо, отколкото класове с изцяло статични константи и
+# функции (ала Java например)
+# 17. and и && имат различни приоритети
+# 18. постфиксния синтаксис на if/unless е много хубаво нещо. Позволява съкращаване на кода
+# и по-добра разбираемост.
+# 19. Неща като attr_* и unless са готини при положение, че ги няма или рядко се срещат в
+# другите езици за програмиране
+# 20. В повечето случаи проверки за nil са грозни и могат да се заменят с нещо по-добро.