Иван обнови решението на 29.04.2013 11:10 (преди над 11 години)
+REPOSITORY = 'https://github.com/skeleta/python-retrospective.git'
+
+# Двадесет неща, които научих.
+#
+# 1. Добра практика е да съхраняваме данните, с които ще работим, в колекции.
+# По този начин можем да боравим с тях значително по-лесно,
+# избягват множество повторения и кодът става прегледен и четим.(задача 1)
+#
+# 2. Константите е добре да се изнасят извън функции
+# и да се именуват със SCREAMING_SNAKE_CASE.(задача 1)
+#
+# 3. Не знам колко странно звучи това, но нямах абсолютно никаква представа,
+# че можем да ползваме отрицателни индекси. Това е супер яко. В смисъл до
+# сега не съм ги използвал, въпреки че са налични и на други езици.
+#
+# 4. Също така 12 - (True) връща 11. Не се бях замислял да използвам сойностите
+# на True и False в аритметически изчисления.(задача 1)
+#
+# 5. Повторенията в кода са много лошо нещо. Трябва да се избягват.
+# Обикновенно са индикация, че нещо се прави грешно и има по-добър и
+# по-кратък начин да се постигне желаният резултат.(задача 1)
+#
+# 6. Много е важно променливите, функциите, класовете и т.н.
+# да са много добре именувани. Да се избягват съкращения,
+# еднобуквени наименувания, прекалено дълги наименувания и да се избира
+# точно това наименуване, което най-конкретно описва какво прави дадена
+# функция или сойността на дадена променлива(примерно stotinki :))
+# Това прави кода по-четлив.(задача 2)
+#
+# 7. В collections има OrderedDict, който помни реда, по който сме добавили
+# елементи в речника, което помага да се изтрие елемент спрямо това
+# кога той е добавен.(задача 2)
+#
+# 8. Generator Expressions значително намаляват количеството код, затова
+# при възможност е добре да се използват именно те.(задача 2)
+#
+# 9. Вместо странни низове подавани на функции за вътрешна имплементация е
+# добре да се дефинират константи и да се подават тези константи.(задача 3)
+#
+# 10. Форматирането на стрингове(примерно через format()) стилизира кода и
+# му придава добър изглед. Уместно е, когато трябва да изведем стринг с
+# множество променливи в него, да го форматираме
+# по някакъв начин.(задача 3)
+#
+# 11. Методите за вътрешна имплементация, тоест тези, които не са публични,
+# да са с 2 подчертавки(__name__ mangling). Полезното е, че предотвратява
+# това подкласовете случайно да не пренапишат вътрешните методи и атрибути
+# на супер класовете. Естествено не помага, ако два различни класа имат
+# едно и също време.(задача 3)
+#
+# 12. Вместо голямото количество сравнение и повторение за намирането на брятя
+# и сестри е добре да се напрви метод(__get_siblings), който да намира
+# събраятята на даден човек и после да гоползваме
+# в съответните функции.(задача 3)
+#
+# 13. Вместо речник-ът person, който пази всички хора като ключ и съответните
+# данни за тях като стойност, e по-добре да пазим един списък
+# с децата на всеки човек и после да се ровим в него
+# при търсенето на брятя, сестри, деца или събратя.(задача 3)
+#
+# 14. Може да ползваме list comprehension
+# заедно с оператор за сравнение.(задача 3)
+#
+# 15. Също така можем да ползваме list comprehension и при форматирането
+# на низове. Спестяват доста усилия и някой друг ред код.(задача 4)
+#
+# 16. За да се избегнат повторения с множество проверки, е добре
+# да се изнесат всички случай на едно място и да се извършват
+# всички проверки едновременно.(задача 4)
+#
+# 17. Дъндърът __class__ дава достъп до атрибутите на класа.
+# Може да се използва при инициализация на инстанции. Не съм убеден
+# колко е добра тази практика, но по мое мнение може да се ползва,
+# когато имаме статични атрибути на класа и при инациализирането на
+# инстанцията да ползваме именно дъндър метода за достъп до тях.(задача 4)
+#
+# 18. Вместо променлива за това дали имаме победител или не в задача 4
+# и сравняване с много if-ове можем да си направим метод, който да
+# проверява за победител.Този метод може да се използва и при
+# обновяването на състоянието на играта. Тоест добре е всеки един метот
+# на даден клас да се обособи в собствена функция.
+#
+# 19. Преглеждайки решения и коментари, установих, че документация
+# (тоест коментарите с трите двойни кавичвки) е добре да се пише,
+# ако сме направили нещо невероятно или при на пръв поглед неразбираеми
+# функци, методи и т.н. Понеже аз толкова велики и невероятни неща
+# не съм сътворил при подобренията на решенията, не мисля че нещо
+# има нужда от тази документация.
+#
+# 20. По-добре е да се ползва all() при множествени сравнявания,
+# които се очаква да изведът един и същи резултат.(задача 4)
17 . Едва ли искаш да правиш това. Статичните неща можеш да ги достъпваш и през инстанцията.