След като много хора от курса проявиха интерес колко точно динамичен е Python, реших да съставя малко примерче как „динамично“ (т.е. по време на изпълнение) може да си конструираме изцяло нов клас. Наслаждавайте се!
Category Archives: Програмиране
fizzbuzz.py
Ето как бих решил FizzBuzz проблема, в оригиналния му вариант, където дори принтираме, вместо да връщаме речник:
for n in range(1, 101):
if n % 3 == 0 and n % 5 == 0:
print ‘FizzBuzz’
elif n % 3 == 0:
print ‘Fizz’
elif n % 5 == 0:
print ‘Buzz’
else:
print n
if n % 3 == 0 and n % 5 == 0:
print ‘FizzBuzz’
elif n % 3 == 0:
print ‘Fizz’
elif n % 5 == 0:
print ‘Buzz’
else:
print n
Просто, нали? Но да мотивирам това решение:
Софтуерни метафори
Наскоро започна твърде често да ми се налага да обяснявам процеса на разработка на „нетехнически лица“. И тъй като е бая сложно да говориш за рефакторинг, редизайн и итерации на хора, които просто мигат на тези думички, си припомних мъдростта на Стив МакКонъл. В Code Complete имаше цяла глава, посветена на метафори за софтуерното разработване – бе го сравнил с писане на жудожествен текст, градинарство, игра и прочее. Безспорно най-доброто сравнение беше с изграждането на някаква постройка. Наистина, „сградостроенето“ е доста сходно до това което ние правим като програмисти. И на двете места си говорим за „архитектура“ и „инженери“, планирането е адски важно и има огромна разлика между строенето на лятна кухня и небостъргач… Continue reading
Unit тестове #2: Какво да тестваме?
По мои наблюдения, когато хората за първи път се сблъскват с тестовете, нямат голяма идея какво да правят. Или се опитват да покрият абсолютно всеки ред код, прахосвайки много време за ненужни неща, или пък пишат твърде малко тестове и пропускат цялата идея. Както казах по-рано, на мен ми отне месец-два докато разбера защо наистина пиша тестове и доста повече, докато усвоя повече тънкости. Ето ви сбито списъче с неща, които се убедих от първа ръка.
Unit тестове #1
Може би това, което най-често ми се налага да обяснявам на приятели/колеги е какво представляват unit тестовете и защо за бога си усложняваме живота като ги пишем. Наистина, когато за първи път започнах да работя и големия лош TL ми каза да пиша „тестове за кода на проекта“, бая се оцъклих. Дълго време гледах тъпо JUnit апито и се чудих какво по дяволите се иска от мен да направя с него и по какъв начин това ще помогне на проекта. Но както казват, мъдростта идва с времето – след месец-два не просто му бях хванал цаката, но вече въобще не мога да си представя разработката на сериозно приложение от екип, без да се пишат тестове. И понеже това ми е любима тема, ще се опитам да драсна едно „цикълче“ от статийки, които да разясняват идеята – или поне как аз я разбирам.
Функционално програмиране
Ако сте посещавали лекции във ФМИ, несъмнено знаете че съществуват и по-екзотични начини за писане на код от Java и C#. Един от тях е функционалното програмиране. Характерно за него са „функции от по-висок ред“ – такива чиито аргументи или връщани стойности също са функции. Един от първите и най-известни езици за функционално програмиране е LISP. Той предлага някои много елегантни решения на доста проблеми, но едва ли ще се сблъскате с него в днешни дни, освен ако не учите във ФМИ или не пишете макроси за emacs. Въпреки, че едва ли някой пише цели приложения на LISP в днешни дни, някои от идеите на функционалното програмирне са съвсем приложими в „модерните“ езици… Continue reading