Страхът и тестовете

Една от причините за неписане на тестове е страхът. Страх, да не счупим нещо -- често променям кода, за да мога изобщо да го хвана под "тестовия микроскоп". Страх, да не би да влошим състоянието на кода в резултат от тестовете.

Има една вълшебна пръчица, която може да ни спаси от страха. Повечето програмисти й казват "система за управление на версиите", source control system, version control system или нещо подобно. Ето рецептата: научаваме се да работим с клиента на системата. Толкова добре, че дори и насън да можем да го вършим. Взимане на последна версия на файл, взимане на предишна версия, разклоняване, споделяне на файлове.

Крайният резултат е един особен начин на работа. Запазваме нова версия всеки няколко минути. Всеки път когато видим нещо нередно, я пропаднала компилация, я неочаквано провален тест, просто връщаме версията от преди 5 минути и опитваме отново.

Така успях да насадя тестове в абсолютно непокрит от тестове компонент. Доколкото знам имах насадени един или два дефекта от манипулацията. Вече имам и добро покритие от тестове, което ме пази от други дефекти. Допълнителната функционалност в компонента, изцяло разработена чрез тестове има един дефект за около 6 месеца, в които компонента е продаван.

Друг анекдот: тази седмица променях инсталационен проект за InstallShield дистрибуцията на същия компонент. Доста съм бос в тази област. Ключът към успеха беше бързата интеграция на проектния файл (XML базиран) в системата за контрол на версиите. Почти всяка промяна в графичния редактор, беше запазвана като нова версия и чрез стандартен diff проверявах разпространяването на промените в конфигурацията. Експериментирах смело и когато бърках се връщах към предишната работеща версия.

Малко библиография -- силно съм повлиян от есето за трите инструмента за стабилна разработка на софтуер на Дейв Томас и Анди Хънт (Прагматичните програмисти). Може да бъде намерено тук

Защо не искаме да пишем Unit Tests

Ето, днес си говорихме с Дешев и един друг приятел по ICQ, защо програмистите не пишат Unit Tests. Не че стигнахме до някакви изводи, обаче ще изредя тия за които се сещам че посменахме:
1. не знам какво е Unit Test и не знам как се пише
2. мързи ме
3. нямам време за тестове
4. ами нали си имаме QA
5. ми то няма голяма полза от тях
6 . ....
Моята е комбианция от всичките изброени май ... някакво смътно гадно чувство - ама сега гледай колко много допълнително писане ми се отваря, и за кво е всичкото това, като утре може всичко да се смени, ама наистина ли всичко трябва да тествам .... и като се замисля за всички тия неща и почвам да се отказвам.
Пък чесно казано понякога е толкоз просто и лесно. Просто решавам че наистина ще пиша тестове и си ги пиша и съм много доволен. Но кое ме кара да правя едното и кое другото - чесно казано не знам. Може би е толкоз простичко като ... just do it.

А твоята/вашата причина коя е? Коментар?

А защо agile методите стават все по-популярни

Agile според мен е своеобразна еволюция на методите за производство на software(sw за краткост). Класическия подход - waterfall, както и най-популярния cod'n'fix се провалят ден след ден с гръм и трясък. Жалко че няма истински добри статистики които да докажат провалите изцяло (или поне аз не знам такива), но има доста опити и всички стигат до почти едни и същи заключения - повечето проекти са и overbudget и overtime и масово се стига до burn-out на програмистите; масово клиента не знае какво иска, и си променя мнението и идеите час през час и т.н. И много от излседванията доказват също че провалите най-малко се дължат на чисто технически проблеми или пък че провала може да се избегне с много extrawork. Изобщо не бих искал пък да засягам качеството на sw, положението с него е просто трагично.
Явно че класическите подходи не вършат добра работа и трябва да се търсят нови в които да е заложена максимална гъвкавост по отношение на промените на заданието, добро качество, по-малко extrawork. Е, както знаем няма нищо ново под слънцето, затова хората който са търсели подобни методи са ги взаимствали от други видове бизнес и понеже най-разпостранената аналогия е с произдостводството, от там са дошли и идеите за Agile. За тези които се интересуват повече накрая има няколко линка, но е достатъчно да пуснете "lean manifacturing" в Google.
Ще ми се да зачекна и друг върпрос тук - производството на sw като research & development процес, а не като производствен процес. Пак за тези които се интересуват ще има линкове най-накрая. Ами в подобен процес (R&D) грешките са нещо нормално, да не кажа че дори са нещо добро - те ни "отрязват" грешните пътища и ни водят в "правилната" посока. Обаче грешките са най-различни: клиента грешно е формулирал нещо, програмиста грсшно е интерпретирал дадено изречение или където не му е ясно е заложил собственото си разбиране за дадения проблем (независимо че може хал хабер да си няма от него), грешно е написал някакъв код и т.н. Освен това при R&D постоянно се правят опити за да се докаже достоверноста на вече изграденото - а в повечето sw проекти опитите са чисто визуални и само концентрирани върху текущия проблем върху който работи програмиста - т.е. ние масово правим debugging и тестове на око. Но де факто истинския тест е този на клиента - ако той може да работи, удобно му е, успешно решава проблемите си, теста е ок. Само че при R&D тестовете се правят максимално често с цел евентуалните проблеми да се открият колкото се може по-бързо т.е. търси се максимално кратък срок обратна връзка. Е, в Agile това е един от основните принципи, доведен до кайност в XP - кратък цикъл на разработка с цел продукта максимално бързо да се озове в ръцете на клиента и да има максимално бърз feedback.
Е дано малко съм позапалил любопитсвтото ви и току виж поне сте отворили линковете тук:
за Agile: www.agilemanifesto.org, www.agilemodeling.com
за sw като R&D: What is Software Design?
за lean sw development: www.poppendieck.com
А ако знаете други web sites на тези теми - моля, пуснете коментар.

Agile -- адаптивност, естествен подбор

Agile -- това е общ термин за отношение или философия за разработката на софтуер. Съществуват много конкретни имплементации, в които са залегнали идеите на тази философия, най-популярната от които е т.нар. екстремно програмиране (Extreme Programming).

Думата agile е прилагателно име и означава "гъвкав", "адаптивен". Това изразява духа -- основната сила е в адаптацията и справянето с постоянните промени в един софтуерен проект. Традиционните подходи и начини на разработка се стремят да улучат правилните изисквания, правилния дизайн, правилната имплементация, правилните инсталация и тестване от самото начало. Те опитват да фиксират цената и времетраенето на един проект.

Това често е невъзможно! Тъкмо тук проличава същността на agile духа. Един гъвкав проект не се бои от промяната в плана. Единствената цел е да се достави бизнес стойност на клиента максимално бързо. Съществуват начини да произвеждаме и доставяме бързо софтуер, който се променя постоянно. Съществуват начини да работим по-близо с клиента и да доставим първо функциите с най-голяма стойност. Не е страшно ако се открие ново изискване, и нов начин да спечелим повече пари за клиента -- просто променяме курса.

Минимум инвентар, минимум практики, документи и процедури -- използваме нещо, единствено след като видим ясна нужда от него и преценим стойността, която ще получим след това. Бърза и постоянна доставка на работеща функционалност. Непрекъсната обратна връзка от клиента и потребителите. Какво повече му трябва на един софтуерен проект?

Българската следа

Нов блог? Май, не. По-скоро допълнение към английския ми блог, свързан с професията ми -- правенето на софтуер.

Мисля тук да пиша на български и да засягам теми, по-характерни за България. Може да си позволявам волности и да излизам от софтуерната област. Времето ще покаже. Приятно четене.

--------------
Новинка: Трансформираме блога в отборно усилие. Засега ставаме двама автори с Борислав.