Пак за инструментите - или не само да ги имаме, а и как да ги ползваме

Оказа се че много прогрмисти знаят и имат CVS(Subversion, MSSS и т.н.), знаят как да ги използват, ползват ги, но .... пак имат доста проблеми (казвам го защото много често чувам оплаквания от рода: "ох, затрих си sources и трябва да се върна 3 дни назад", "леле обозих нещо и не знам какво, а commit-вах рпеди 3 дни".
Според мен SCC трябва да се ползва много, много често. Commit е добре да се прави по няколко пъти на ... час! (не на ден или седмица). Защо? - ей тук ще споделя моя опит защо ми помагат честите commits (между другото изградил съм си и навик да правя commit и в края на всеки работен ден - а това предполагам лесно може да се автоматизира при затваряне на IDE-то):
1. (и най-важно) можем да се връщаме назад на малки стъпки - причината е много елементарна - ако commit-вам на всеки 10 минути например, "бозите" които ще сътворя за тия 10 минути са много по-малко отколкото бозите които бих написал за 3 дни. така после лесно мога да открия и къде съм сбъркал. тази техника отличо пасва и с техниката за често пускане на UnitTests - причината е абсолютно същата.
2. честа синхронизация с колегите които работят по същия код - така избягваме проблемите по стиковането на кода. това налага обаче и чести updates, което също не е болка за умиране .

Друго правило което гледам да спазвам е да слагам тагове когато стигна положение в което кода е в добро състояние. (какво означава в добро състояние всеки може да прецени сам според мен). Т.е. когато "усетя че текущото състояние е "добро" слагам таг на целия проект с някакво име. Същата техника може да се ползва и за край на итерация/release.

Ако трябва да обобщя , то е не само да "ползваме" програмистките инструменти, но и да ги ползваме често. И идеята е да изградим навици за това, а не да си търсим причини да не го правим. Навика е автоматизация ;) - правиш го без да мислиш (и от самосебе си разрешаваш прблеми от рода на най-горе описаните 2 ).
Или както беше писал Steve McConnell в Rapid Development: ако дадем бормашина в ръцете на човек който не знае нищо за електричеството, той ще го използва като чук. (цитата не е малко неточен)

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

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

Има една вълшебна пръчица, която може да ни спаси от страха. Повечето програмисти й казват "система за управление на версиите", 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 духа. Един гъвкав проект не се бои от промяната в плана. Единствената цел е да се достави бизнес стойност на клиента максимално бързо. Съществуват начини да произвеждаме и доставяме бързо софтуер, който се променя постоянно. Съществуват начини да работим по-близо с клиента и да доставим първо функциите с най-голяма стойност. Не е страшно ако се открие ново изискване, и нов начин да спечелим повече пари за клиента -- просто променяме курса.

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

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

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

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

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