Страхът и тестовете
Една от причините за неписане на тестове е страхът. Страх, да не счупим нещо -- често променям кода, за да мога изобщо да го хвана под "тестовия микроскоп". Страх, да не би да влошим състоянието на кода в резултат от тестовете.
Има една вълшебна пръчица, която може да ни спаси от страха. Повечето програмисти й казват "система за управление на версиите", source control system, version control system или нещо подобно. Ето рецептата: научаваме се да работим с клиента на системата. Толкова добре, че дори и насън да можем да го вършим. Взимане на последна версия на файл, взимане на предишна версия, разклоняване, споделяне на файлове.
Крайният резултат е един особен начин на работа. Запазваме нова версия всеки няколко минути. Всеки път когато видим нещо нередно, я пропаднала компилация, я неочаквано провален тест, просто връщаме версията от преди 5 минути и опитваме отново.
Така успях да насадя тестове в абсолютно непокрит от тестове компонент. Доколкото знам имах насадени един или два дефекта от манипулацията. Вече имам и добро покритие от тестове, което ме пази от други дефекти. Допълнителната функционалност в компонента, изцяло разработена чрез тестове има един дефект за около 6 месеца, в които компонента е продаван.
Друг анекдот: тази седмица променях инсталационен проект за InstallShield дистрибуцията на същия компонент. Доста съм бос в тази област. Ключът към успеха беше бързата интеграция на проектния файл (XML базиран) в системата за контрол на версиите. Почти всяка промяна в графичния редактор, беше запазвана като нова версия и чрез стандартен diff проверявах разпространяването на промените в конфигурацията. Експериментирах смело и когато бърках се връщах към предишната работеща версия.
Малко библиография -- силно съм повлиян от есето за трите инструмента за стабилна разработка на софтуер на Дейв Томас и Анди Хънт (Прагматичните програмисти). Може да бъде намерено тук
Има една вълшебна пръчица, която може да ни спаси от страха. Повечето програмисти й казват "система за управление на версиите", source control system, version control system или нещо подобно. Ето рецептата: научаваме се да работим с клиента на системата. Толкова добре, че дори и насън да можем да го вършим. Взимане на последна версия на файл, взимане на предишна версия, разклоняване, споделяне на файлове.
Крайният резултат е един особен начин на работа. Запазваме нова версия всеки няколко минути. Всеки път когато видим нещо нередно, я пропаднала компилация, я неочаквано провален тест, просто връщаме версията от преди 5 минути и опитваме отново.
Така успях да насадя тестове в абсолютно непокрит от тестове компонент. Доколкото знам имах насадени един или два дефекта от манипулацията. Вече имам и добро покритие от тестове, което ме пази от други дефекти. Допълнителната функционалност в компонента, изцяло разработена чрез тестове има един дефект за около 6 месеца, в които компонента е продаван.
Друг анекдот: тази седмица променях инсталационен проект за InstallShield дистрибуцията на същия компонент. Доста съм бос в тази област. Ключът към успеха беше бързата интеграция на проектния файл (XML базиран) в системата за контрол на версиите. Почти всяка промяна в графичния редактор, беше запазвана като нова версия и чрез стандартен diff проверявах разпространяването на промените в конфигурацията. Експериментирах смело и когато бърках се връщах към предишната работеща версия.
Малко библиография -- силно съм повлиян от есето за трите инструмента за стабилна разработка на софтуер на Дейв Томас и Анди Хънт (Прагматичните програмисти). Може да бъде намерено тук
posted by Hristo at 11:21 PM
3 Comments:
Абсолютно съм съгласен и с теб и PP(Andy и Hunt). Въпроса е колко други програмисти са съгласни, казвам го защото помня че гледах статистика (даже мисля че ти ми беше дал линка) - над 50% от фирмите не ползват изобщо SCS.
Много от колегите гледат на тези 3 интрумента като нещо затормозяващо и пречещо, а не като инструменти които могат да са ни в полезни. Имам такива познати които са от 10-15 години в бранша и като им спомена за CVS и UnitTests ми казват "мани ги тез тъпни бе, само ме бавят и ми пречат". Причините които ми идват на ума веднага са:
1. мързел да се научи още едно нещо и да се ползва
2. невежество (т.е. изобщо не знаят за ползите да се използват подобни инструменти).
3. липса на дисциплина - това може би е най-често срещано, дори и при колеги дето доста са страдали от загубени или презаписани файлове. то това е обикновено комбинирано с 1.
И не знам как можем да се преборим с 1 и 3 ... ако ти знаеш (или някой друг знае) .... да напише
Как да се борим? Не знам. Хората сме такива, че рядко се учим от добро.
Миналата сряда ми направи впечатление, че проектът на един колега не е в системата за контрол на версиите. Вдигнах рамене. Достатъчно съм пял за предимствата. Днес разбрах, че рилийза на същият продукт от петък е със сбъркани файлове. Няколко файла не бяха просто с най-новите си версии, поради факта, че човека беше забравил да ги сложи в дистрибуцията.
Мисля, че вече всички ще държим проектите във VSS. :-)
Да, сигурно като се е опарил ще го ползва, но едва ли в смисъла за който говориш в постинга. Но и това е нещо, нали е по-добре от нищо, а и така се започва. Може би искаме прекалено много ... хубавите неща стават на малки стъпки и постоянно. (какво друго е дисциплината освен постоянно т.е. винаги спазване на определени правила?)
Post a Comment
<< Home