Имам алергия към формалните ритуали. (Не, че има общо с темата :)
Идеята беше, че моеш да нариташ зрелищно неверника с примери как TDD препича филийки в тостера и ги маже с лютеница, като едновременно вари яйчицата, точно да са рохки и само ръсиш пипер и муаш :)

На мен това ми изглежда съвсем неформално. Значително по-формален подход е синтезиране на програмата (конструктивно) и т.н.

Този подход - TDD - има някакъв приложнически чар. При съвременното "програмиране", което е скалъпване на някакви библиотеки и получаване на продукт, ми се струва доста добър подход. Това е занаятчийска техника и в контекста на българското производство, струва ми се, по-начало нихилистичният народен работодател би имал полза да инвестира в някаква подготовка на персонала си в тази и подобни области, колкото и реалният development да не е приоритетен в нашите предприятия.

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

Изискванията са далеч не толкова стабилно нещо. В просец на писане изникват нови неща, оказва се по някога, че трябва архитектурата да се посмени, правят се оптимизации. Изобщо планирането тръгва от use case, а не от нещо техническо на което можеш да напишеш unit test. Промяна не е само това което клиента официално изисква след като види резултата.

За мен правилната последователност е в началото да има само бегли описания на тестове - не толкова да се следи качеството, колкото да не ти се изплъзне крайната цел. След това реалните тестове трябва да се появяват при завършен компонент. Това спестява всички усилия по преправяне на тестове и допълнително улеснява самото им писане.

----------------------------------------
Здрав дух, в здрава бутилка!

Ако не искаш да завършиш един проект и ако искаш екипа да се изпокара най-добрия начин е да разменяш хората по един таск. Всеки човек си има свой начин на мислене и свой стил (нямам предвид конвенция на писане), примерно аз никога не използвам цикли do-while. След смяна на човека се започва: това какво е, а това защо не е така, ама тоя интерфейс за чий си го изнесъл след като има само една имплементация ... я дай сега аз първо да си направя нещата да са като хората, да ти оправя бозите, а след това ще продължа нататък ... Да не говорим за загубата на време в разбиране на код който подлежи на промяна.

----------------------------------------
Здрав дух, в здрава бутилка!

Автоматични тестове, ръчни тестове, код ревюта, задължителна код конвенция и като капак по един качествен QA.

----------------------------------------
Здрав дух, в здрава бутилка!

След смяна на човека се започва: това какво е, а това защо не е така, ама тоя интерфейс за чий си го изнесъл след като има само една имплементация ... я дай сега аз първо да си направя нещата да са като хората, да ти оправя бозите, а след това ще продължа нататък ... Да не говорим за загубата на време в разбиране на код който подлежи на промяна.

Това разбира се е погрешна гледна точка. Ако нещата са кофти на ниво проектиране, се получава точно това което казваш - боза. Ако нещата са проектирани добре и достатъчно подробно и ясно, тогава остава проблема с колко ясно пишат кодерите. Идеята, че всеки кодер си има стил и това е важно, всъщност не е важна. От гледна точка на всеки тийм лидер (и нагоре) хората са ресурс и то заменим такъв. Да го кажем по друг начин, какво правиш ако един кодер си замине и ти трябва да предадеш неговите проекти на друг ?! Става стандартното - ооо колко лош програмист е напусналия и как трябва да се пренапише всичко. Резултатът - Загуба на време и в крайна сметка на пари!
Другото по темата - обикновено конвенции, стил, коментари и т.н. са нещо което никой кодер не спазва. Това е начина да ги накараш да разберат колко е важно всъщност. Дори да се стигне до полускандал, изводите са очевидни - пишете така, че другия да ви разбере писанията! Понеже тийм лидера, ПМ или който да е отговорния фактор не може да се съобразява с всеки кодерски стил, то кодерите ще се съобразява с това което е прието за стандарт в фирмата.

Юнит тестовете са най-полезни точно когато архитектурата не е вече актуална и трябва да се смени. Как според теб може да се докаже, че рефакторинга не е счупил нещо, докато сме се опитвали да решим даден проблем? По предишния проект пълен регрешън се правеше за 3 дни от двама тестери. Няма начин да чакаме толкова дълго. За сметка на това добре проектираните юнит тестове ти дават отговор в рамките на минута-минута и половина.

Разбира се обаче, че трябва да има баланс. Аз например никога не пиша юнит тестове за сторнати процедури и ДАЛ. Сторнатите процедури по стандарт трябва да са тъпи и да не съдържат почти никаква логика. ДАЛ имаме готов компонент, за който вече са измислени юнит тестовете и който се пипа само като трябва да се портне към нова версия на фреймуърка (сега се говори да сме го сменяли с Ентити).

Аз точно затова казах, че мое наблюдение код ревютата са най-неефективни. За сметка на това пеъринг дава много добри резултати - постепенно хората по един проект си уеднаквяват стила, докато в един момент започнат да следват стандартите без дори да се замислят. Много подходящ и при наемане на нови хора да им се покаже "как правим нещата тук". Защото, както се разбра вече, документи никой не чете.

<quote>
Автоматични тестове, ръчни тестове, код ревюта, задължителна код конвенция и като капак по един качествен QA.
</quote>

Да, и 100 мармота също, за всеки случай. И едно пони.