Здравко обнови решението на 14.11.2011 16:01 (преди около 13 години)
+REPOSITORY = 'https://github.com/zstoychev/ruby-retrospective-1'
+
+# 1. Документацията трябва да се чете внимателно.
+# 2. Поставяне на незадължителен self пред член на класа не спомага към
+# четимостта.
+# 3. Често each може да бъде заменен от много по-подходящ метод от Enumerable.
+# 4. Брой елементи от съвкупност, за които е изпълнено условие = count.
+# 5. Когато на всеки елемент от съвкупност по някакво правило се съпоставя
+# елемент, с цел да се получи съвкупност от новите елементи, се използва map.
+# 6. Използването на немутиращи операции е за предпочитане пред мутиращи,
+# когато е възможно. Мутиращите чупят функционалната парадигма и правят
+# четенето и писането по-трудни.
+# 7. Операторът * извиква Array() върху аргумента си. Едно от местата, в които
+# може да бъде използван, е в литерала [] за образуване на част от
+# елементите на получения от литерала масив, използвайки елементите на
+# върнатия от Array() масив.
+# 8. Дизайнът около по-ефективни структури вместо за по-добър и лесно изменяем
+# код често е лош.
+# 9. Близки класове е добре да бъдат изнесени в един модул.
+# 10. Всеки клас трябва да има една ясна цел.
+# 11. Когато имаме повече методи в клас, които зависят само от част от данните
+# на обектите на класа, може би е добре да се отделят заедно с данните в
+# отделен клас.
+# 12. Трябва да се намират подходящи начини за избягване повторение на код.
+# Един възможен е повтарящият код да се отдели на едно подходящо място
+# (например метод), а различния да бъде отделен в подходящи класове и да
+# бъде достъпван чрез полиморфизъм.
+# 13. Промяната на дадена част от кода трябва да води до необходимост от
+# промяна във възможно най-малко места.
+# 14. Неща, за които е доста вероятно да бъдат променени, или за които е
+# възможно да възникне нужда от различни версии, е добре да се изнесат на
+# отделно място с подходящ интерфейс.
+# 15. Дълги вериги от извиквания често са признак за лош дизайн на класовете.
+# Понякога подходящо решение е делегация.
+# 16. Прекалено дългите редове се четат по-лесно когато бъдат разделени на
+# отделни изрази, всеки от който се присвои на променливи с подходящи
+# имена. Ако това разделяне не е възможно то най-вероятно има дълги вериги
+# или друг лош дизайн.
+# 17. Когато един метод е дълъг и сложен, то вероятно върши няколко неща, всеки
+# от което е по-добре да бъде изведено в отделен метод. Така биха могли дори
+# да се обособят методи, които са подходящи за извеждане в отделен клас.
+# 18. Съвкупност от ламбди е трудно за четене. Често могат да се заменят с case
+# или разделяне в подходящи класове.
+# 19. За проверка на предусловия е по-ясно, когато е възможно, да се провери дали
+# те са изпълнени, а не дали не са изпълнени, тоест с
+# unless условие1 and условие2...
+# 20. Сложни операции върху обект, зависещи само от неговото състояние, може да e
+# добре да бъдат изнесени като метод на обекта с ясно име. Това би позволило
+# и по-голяма независимост на реализацията. Например item.discounted? вместо
+# item.discount > 0.