Отговарям на последното мнение на Jamie:

опитвам се да цитирам преди отговорите, че наистина стана тежък разговор...

Позна, че съм почитател на екстрийм програминга. Даже в момента участвам в усилията за изграждане на XP група в България.

>не променяш сигнатура на метод дори ЗАЩОТО това се прави при
>дизайна - например в Роуз се генерират прототипи. Ти променяш
>сигнатурата - на колегата ти извикванията към тебе гърмят - класик
>шит ! Честито !

А какво би станало ако няма мой код и код на колегата и целия код е общ? Какво би станало ако при промяна на сигнатура се променят само 1-2 извиквания защото кода е качествен? Какво би станало ако това нещо се "забелязва" от тестовете на първата интеграция и оправянето струва минути?

Как може да отричаш рефакторинга и изобщо каквото и да било без да го пробваш? Или си пробвал? Моля те разкажи ми за опитите си да прилагаш ТДД и рефакторинг - с радост бих помогнал. Аз съм удивен от тези практики, защото видях лично за себе си, че големия дизайн в началото не работи. Мотал съм се достатъчно с УМЛ инструменти и никога не можех да предвидя всичко - ха, че да не съм ясновидец. Реших, че е по-разумно да инвестирам време и умения за да реагирам бързо на промяната вместо да я забранявам и да се пазя от нея.

>За Ю Ем Ел и хартийката - пак типичен кодер. Бих изхвърлил кода ти, а
>не "хартийката" - така проекта ще пострада по-малко.....

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

>код написан с идеята за виртуозност но нечитаем, сюрия тестове които
>след елементарна промяна в кода показват грешки в 60% от въпросния
>код просто защото например класовете страдат от вече цитирания от
>мен "коуплинг" ?

това за нечитаемостта си е чиста проба спекулация. освен това как реши, че тестовете и кода ще са толкова зависими ( high coupling )? Смея да твърдя, че в стремежа да постигна тестваем дизайн правя забележително малко обвързани ( coupled ) класове.

>Ами ако от 2-годишния проект получа актуални диаграми, 200 страници
>реална документация (а не отбиване на номера) и синхронициран с
> всичко това код (както е трябвало да го напише кодера) - тогава
>какво ?

Не ми се е случвало такова нещо. Страшно лесно е да разсинхронизираш всичките артефакти по пътя и няма начин дори да разбереш, че е така защото документацията и моделите не могат да се изпълняват или обработват автоматично. Затова има смисъл да залагаме на изпълнимите средства - тестовете! Мисля, че това са предимствата на леките методологии - те не са недисциплинирани, тъкмо напротив. Просто огромното количество церемонии са заменени с реални практики, които гарантират бърза обратна връзка - веднага разбирам дали предишната ми намеса е била направена като хората или не - веднага, а не след месеци. Не ми отговори - какво става, когато дизайна ти е грешен и не може да изпълни бизнес изискването. Ще ме убедиш ли, че дизайните ти са на 100% верни от самото начало?

--
"Agile is a mindset, not a set of practices, rules, or tools."
Tom Poppendieck