Мартин обнови решението на 27.04.2013 19:18 (преди над 11 години)
+REPOSITORY = 'https://github.com/martin-marinov/python-retrospective'
+
+# Двадесет неща, които научих.
+#
+# 1. По-добре е да изнасяме литерали, константи извън кода.
+# 2. Когато искаме да модифицираме една функция, да и придадем допълнително значение,
+# е хубаво да помислим дали декоратор би ни свършил добра работа, а не да внесем функцията в
+# самата функция.
+# 3. Хубаво е функциите и изобщо всяка единица код, която върши някаква дейност,
+# да върши едно единствено нещо и да го върши добре(Unix principles)
+# 4. С декоратори кодът е много по-красив.
+# 5. Хубаво е когато даден метод няма нужда от знанието за инстанцията, от която е извикан,
+# тогава той да бъде класови метод.
+# 6. Ако няма нужда от знанието за класа, в който е дефиниран, тогава той може да бъде
+# изкаран отвън като обикновена функция, или пък(при нужда) дефиниран като статичен метод
+# 7. Трябва да разделяме кода си на самостоятелни, смислени единици, които отговарят за
+# определено нещо. Кодът трябва да бъде структуриран красиво.
+# 8. DRY(Don't Repeat Yourself) е важен принцип в Пайтън(и не само)
+# 9. Изключенията не са достатъчно важни, за да пренебрегват правилата(във връзка с имената
+# на функциите в unittest модула)
+# 10.Не винаги най-краткият код е най-красив/разбираем.
+# 11.Дефинирането на scope на променливите в Пайтън помага на хората, които четат кода ни,
+# дефинира интерфейс, въпреки че може винаги да бъде заобиколен този scope.
+# 12.Все пак, ако може нещо да се напише по-кратко, запазвайки яснотата на кода, е добра практика
+# 13.Трябва да сме наясно с API-то, което Пайтън ни предоставя - от една страна другите ще разбират много
+# по-бързо и лесно какво правим, от друга страна сами ние ще го правим по-бързо
+# 14.Не само валидно за Пайтън, но все пак - трябва да се обмислят всички възможни ситуации
+# и corner cases, пишейки решение на задачката. Пропуска главоблъсканицата...
+# 15.Добра идея е писането на тестове преди самото решение, също помага за главоблъсканица.
+# 16.Една задача може да има няколко добри решения - хубаво е да ги знаем всичките :)
+# 17.isinstance често не е хубаво нещо, но често когато искаш да валидираш някакъв вход,
+# най-вероятно е правилно решение
+# 18.functools.wraps върши доста добра работа при декораторите.
+# 19.Няма нужда да wrap-вам функция в друга функция, за да върна генератор, тъй като наличието
+# на yield в самата функция ми връща генератор
+# 20.Трябва да пишем кода си така, че четейки го, с лекота да разбираме какво прави,
+# дори без да четем документацията. Това е силата на Пайтън.
Виждам 8 неща, които са твърде общи и философски. Може би вярни, но далеч не по темата. Not cool.