Решение на Пета задача от Илиян Бобев

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

Към профила на Илиян Бобев

Резултати

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

Код

REPOSITORY = 'http://github.com/bobev18/ruby-retrospective-3'
# Двадесет неща, които научих.
#
# 1. TDD помага - ако бях го ползвал нямаше да ми failne единия от тестовете.
# 2. Това не е Python - self може да се изпусне
# 3. Трябва да се знае добре речника на Ruby - има много "дребни" методи, които
# правят кода много по-четим:
# pred, remainder, nonzero?, nil?, chars, empty?
# 4. Трябва да се възползвам напълно от методите на `Enumerable` с _with_ в името.
# 5. Следването на "функционален" стил при измислянето на алгоритмите е предпочитано.
# 6. flatten може да взима аргумент.
# 7. Често skeptic ограниченията дават по-голямата част от сложността на заданието.
# Но и четимостта на кода дава по-голямата част от стойнотта му.
# 8. `Enumerable` е мощен инструмент.
# 9. възможността да се връща lambda/proc като резултат на метод е мощен инструмент.
# 10. Константите е добре да са вътре в именуваното пространство, а не да замърсяват
# глобалното такова.
# 11. Не трябва да се прекалява с класовите методи - те трябва да се ползват когато
# не зависят от състоянието на обекта.
# 12. Дефинирането на <=> метод и include-ване на `Comparable` в класа, позволява
# директно да се сравняват обекти от този клас.
# 13. Дефинирането на DSL е добре да се направи чрез `instance_eval &block`, за да не
# се замърсява глобалното именувано пространство.
# 14. Бизнес логиката на приложенията трябва да се реализира независимо/капсулирано
# от реализацията на входа и изхода.
# 15. there is no '!=' method, there is only '=='. you should send '==' and not/! the result:
# ! a.send('==', 2)
# 16. Да не прекалявам с мета програмирането.
# 17. Да правя много класове с малко методи, вместо няколко с множество методи.
# 18. ООП е базирано на клетките в биологията.
# 19.
# 20. Да не подценявам времето нужно за refactoring.

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

Илиян обнови решението на 22.01.2014 15:46 (преди над 10 години)

+REPOSITORY = 'http://github.com/bobev18/ruby-retrospective-3'
+
+# Двадесет неща, които научих.
+#
+# 1. TDD помага - ако бях го ползвал нямаше да ми failne единия от тестовете.
+# 2. Това не е Python - self може да се изпусне
+# 3. Трябва да се знае добре речника на Ruby - има много "дребни" методи, които
+# правят кода много по-четим:
+# pred, remainder, nonzero?, nil?, chars, empty?
+# 4. Трябва да се възползвам напълно от методите на `Enumerable` с _with_ в името.
+# 5. Следването на "функционален" стил при измислянето на алгоритмите е предпочитано.
+# 6. flatten може да взима аргумент.
+# 7. Често skeptic ограниченията дават по-голямата част от сложността на заданието.
+# Но и четимостта на кода дава по-голямата част от стойнотта му.
+# 8. `Enumerable` е мощен инструмент.
+# 9. възможността да се връща lambda/proc като резултат на метод е мощен инструмент.
+# 10. Константите е добре да са вътре в именуваното пространство, а не да замърсяват
+# глобалното такова.
+# 11. Не трябва да се прекалява с класовите методи - те трябва да се ползват когато
+# не зависят от състоянието на обекта.
+# 12. Дефинирането на <=> метод и include-ване на `Comparable` в класа, позволява
+# директно да се сравняват обекти от този клас.
+# 13. Дефинирането на DSL е добре да се направи чрез `instance_eval &block`, за да не
+# се замърсява глобалното именувано пространство.
+# 14. Бизнес логиката на приложенията трябва да се реализира независимо/капсулирано
+# от реализацията на входа и изхода.
+# 15. there is no '!=' method, there is only '=='. you should send '==' and not/! the result:
+# ! a.send('==', 2)
+
+#
+#
+#

Илиян обнови решението на 22.01.2014 17:29 (преди над 10 години)

REPOSITORY = 'http://github.com/bobev18/ruby-retrospective-3'
# Двадесет неща, които научих.
#
# 1. TDD помага - ако бях го ползвал нямаше да ми failne единия от тестовете.
# 2. Това не е Python - self може да се изпусне
# 3. Трябва да се знае добре речника на Ruby - има много "дребни" методи, които
# правят кода много по-четим:
# pred, remainder, nonzero?, nil?, chars, empty?
# 4. Трябва да се възползвам напълно от методите на `Enumerable` с _with_ в името.
# 5. Следването на "функционален" стил при измислянето на алгоритмите е предпочитано.
# 6. flatten може да взима аргумент.
# 7. Често skeptic ограниченията дават по-голямата част от сложността на заданието.
# Но и четимостта на кода дава по-голямата част от стойнотта му.
# 8. `Enumerable` е мощен инструмент.
# 9. възможността да се връща lambda/proc като резултат на метод е мощен инструмент.
# 10. Константите е добре да са вътре в именуваното пространство, а не да замърсяват
# глобалното такова.
# 11. Не трябва да се прекалява с класовите методи - те трябва да се ползват когато
# не зависят от състоянието на обекта.
# 12. Дефинирането на <=> метод и include-ване на `Comparable` в класа, позволява
# директно да се сравняват обекти от този клас.
# 13. Дефинирането на DSL е добре да се направи чрез `instance_eval &block`, за да не
# се замърсява глобалното именувано пространство.
# 14. Бизнес логиката на приложенията трябва да се реализира независимо/капсулирано
# от реализацията на входа и изхода.
# 15. there is no '!=' method, there is only '=='. you should send '==' and not/! the result:
# ! a.send('==', 2)
-#
-#
+# 16. Да не прекалявам с мета програмирането.
-#
+# 17. Да правя много класове с малко методи, вместо няколко с множество методи.
+# 18. ООП е базирано на клетките в биологията.
+# 19.
+# 20. Да не подценявам времето нужно за refactoring.