Програмиране с Ruby

Курс във Факултета по Математика и Информатика към СУ

Решение на Пета задача от Кирчо Кирев

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

Към профила на Кирчо Кирев

Код

REPOSITORY = 'https://github.com/KirchoKirev/ruby-retrospective-2'
# Двадесет неща, които научих.
# 1. Влагането на методи работи по различен начин в Ruby (вложеният метод няма
# достъп до променливите след scope gate-a и става инстанционнен).
# 2. Enumerable свежда използването на each до минимум и намалява инцидентната сложност.
# 3. Използвам литерален синтаксис където е възможно. Upto e за предпочитане
# пред Range.
# 4. Започнах да отделям повече внимание върху форматиране на кода и адекватно
# именоване на променливи и методи. Научих, че ако не мога да измисля добро
# име, трябва да променя нещо.
# 5. Не е приемливо да връщам обекти със странични ефекти като резултат (стария хеш
# в group_values).
# 6. Използването на symbol to_proc прави кода по-четим. Нещо кратко не винаги е четимо.
# 7. Няма смисъл да подавам lambda като единствен аргумент, когато мога да подам блок.
# 8. Запознах се с Single Resposibility Principle, KISS, DRY, основните симптоми
# на code smell.
# 9. По-добре е да изпускам скоби, освен в случаите на дефиниция на метод или наличието
# на warning. Спрях да достъпвам полетата през accessor, когато няма причина за това.
#10. Използвах interpreter pattern и разбрах колко са полезни design patters като цяло.
# Запознах се с The Expression Problem и какви ползи/недостатъци има всеки от подходите.
#11. Започнах да правя TDD. Red (писане на тест, който не минава), green (решение,
# покриващо теста), refactor и всичко това на много малки стъпки.
#12. Когато многократно създавам един и същ обект, е по-четимо да си дефинирам класов
# метод, който да прави това (Number.zero/one в задача 3).
#13. Наличието на много повтарящ се код подсказва, че има по-добро решение (повтарящият се
# simplify във всеки derive => derive и derivative методи премахващи повторението).
#14. Големият брой класове/методи не е проблем, щом прави кода по-разбираем.
#15. Няма смисъл заради малка оптимизация да пиша по-сложен код, който затруднява четенето.
#16. Наличието на отделен модул/хеш за регулярни изрази е удобно. Интерполацията в регулярен
# израз е прегледна и може да ми спести наличието на много повтарящ се код.
#17. Когато пиша сложен регулярен израз, е добре да го разделям на няколко по-прости части.
#18. Именованите групи са по-подходящи в сложни изрази, защото са лесни за проследяване в
# сравнение с номерираните. Правят кода с една идея по-ясен.
#19. Define_method + each са удобни за дефиниране на няколко сходни метода наведнъж.
#20. Дефинирането на private методи, които обработват подаден текст в задача 4, беше
# по-добра идея в сравнение с няколко модула, които знаят за класа Filter и работят
# с полетата му.

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

Кирчо обнови решението на 29.12.2012 14:08 (преди над 11 години)

+REPOSITORY = 'https://github.com/KirchoKirev/ruby-retrospective-2'
+
+# Двадесет неща, които научих.
+# 1. Влагането на методи работи по различен начин в Ruby (вложеният метод няма
+# достъп до променливите след scope gate-a и става инстанционнен).
+# 2. Enumerable свежда използването на each до минимум и намалява инцидентната сложност.
+# 3. Използвам литерален синтаксис където е възможно. Upto e за предпочитане
+# пред Range.
+# 4. Започнах да отделям повече внимание върху форматиране на кода и адекватно
+# именоване на променливи и методи. Научих, че ако не мога да измисля добро
+# име, трябва да променя нещо.
+# 5. Не е приемливо да връщам обекти със странични ефекти като резултат (стария хеш
+# в group_values).
+# 6. Използването на symbol to_proc прави кода по-четим. Нещо кратко не винаги е четимо.
+# 7. Няма смисъл да подавам lambda като единствен аргумент, когато мога да подам блок.
+# 8. Запознах се с Single Resposibility Principle, KISS, DRY, основните симптоми
+# на code smell.
+# 9. По-добре е да изпускам скоби, освен в случаите на дефиниция на метод или наличието
+# на warning. Спрях да достъпвам полетата през accessor, когато няма причина за това.
+#10. Използвах interpreter pattern и разбрах колко са полезни design patters като цяло.
+# Запознах се с The Expression Problem и какви ползи/недостатъци има всеки от подходите.
+#11. Започнах да правя TDD. Red (писане на тест, който не минава), green (решение,
+# покриващо теста), refactor и всичко това на много малки стъпки.
+#12. Когато многократно създавам един и същ обект, е по-четимо да си дефинирам класов
+# метод, който да прави това (Number.zero/one в задача 3).
+#13. Наличието на много повтарящ се код подсказва, че има по-добро решение (повтарящият се
+# simplify във всеки derive => derive и derivative методи премахващи повторението).
+#14. Големият брой класове/методи не е проблем, щом прави кода по-разбираем.
+#15. Няма смисъл заради малка оптимизация да пиша по-сложен код, който затруднява четенето.
+#16. Наличието на отделен модул/хеш за регулярни изрази е удобно. Интерполацията в регулярен
+# израз е прегледна и може да ми спести наличието на много повтарящ се код.
+#17. Когато пиша сложен регулярен израз, е добре да го разделям на няколко по-прости части.
+#18. Именованите групи са по-подходящи в сложни изрази, защото са лесни за проследяване в
+# сравнение с номерираните. Правят кода с една идея по-ясен.
+#19. Define_method + each са удобни за дефиниране на няколко сходни метода наведнъж.
+#20. Дефинирането на private методи, които обработват подаден текст в задача 4, беше
+# по-добра идея в сравнение с няколко модула, които знаят за класа Filter и работят
+# с полетата му.