Ще коментирам само 2-3 неща:

"Мотал съм се достатъчно с УМЛ инструменти и никога не можех да предвидя всичко - ха, че да не съм ясновидец. Реших, че е по-разумно да инвестирам време и умения за да реагирам бързо на промяната вместо да я забранявам и да се пазя от нея. "

Липса на анализ.

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

Липса на анализ, както и на синхронизиране на промените в кода и УМЛ диаграмите (дизайна). Кодер не е обида, просто е тип член на екипа в проекта. Също както тестер или софтуерен архитект.


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

Спекулация е. Цитирах твое твърдение по повод кода писан под УМЛ дизай - значи си спекулирал ?
Дори два коуплед класа сочат неграмотно проектиране.

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

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



ПП: Пиши по-кратко че да се чете по-леко.
ХР е примамливо и си има приложение, но по-добре да се използва като допълнително предимство вместо да се опитва да отрича алтернативите.

UB40 !

Съдържаниет е скрито
Влезте за да го видите