До колко може да се изкара един проект без дизайн? Без начален, но с много постоянен и своевременен дизайн! Кодът и дизайнът разделени ли са? Разделени ли са от анализа, изискванията, бизнес нуждите зад проекта?

Различните подходи на различните методологии. Аз съм от Agile страната. Jamie засега - от по-традиционната. Пускам го в отделна тема, защото разговора тръгна случайно от MVS.NET темата. Първо малко контекст, следилите другата тема може да го прескочат:
=====================
Jamie
=====================
смърди на Ю Ем Ел от километри :-)
Отново опираме не до самото програмиране, а до дизайна. А оттам - и до анализа преди него. Липсват ти - почва се дялане до полудяване.

ПП: Кода НЕ Е и НЕ ТРЯБВА ДА Е дизайна. Обратното обаче вече се е случило - има уеб (и приложен) сървър, програмируем изцяло с Ю Ем Ел.
=====================
Муслон
=====================
Нямам нищо против УМЛ... Стига да не се прекалява. Иначе е хубаво средство за комуникация на идеи. За генерация на код - ако някой го влече нека ползва УМЛ.

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

>Кода НЕ Е и НЕ ТРЯБВА ДА Е дизайна.
А така. Сега имаме две противоположни мнения. Би ли ми казал защо мислиш така? Аз заставам зад позицията, че писането на код е висша форма на дизайн - от спецификацията чрез тестове, през писането за да удовлетворим пропадащия тест, до рефакторинга с който да ошлайфаме продукта до там, че да не стане това на което викаш "дялане до полудяване".

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

И да - покажи ми начин да правя изпълними тестове на модела в твоите изпълними УМЛ среди. Още не съм сигурен, че модел и дизайн са едно и също нещо - моделът е метафора за продукта ни, начин на мислене или ако искаш теория. Това може да е различно от физическия дизайн.
=====================
Jamie
=====================
всяко нещо като се прекалява - не е добре ;-)
"Аз съм на мнение, че дизайна и кода трябва да се правят едновременно. Планиране, анализ, код и дизайн - на кратки цикли с бърза обратна връзка и възможност за промяна. "Архитекти"-те които не пишат код и живеят само в УМЛ света са престъпление срещу природата. Същото важи и за "програмисти", които чакат някой да им спусне отгоре стъпка по стъпка каквото трябва да направят. "

Много крайно изказване за архитектите. Като цяло съм съгласен с едно изключение - анализ-планиране-код(но само с цел уточняване на технологията)-поправки в дизайна(евентуално).
Масивния код се пише след уточнен дизайн.

Мислиш като кодер.
Решънъл Роуз позволява доста тестове на ниво дизайн още, освен това са добре видими и грешките в дизайна - както "коуплинг" например. Стигнеш ли до рефакторинг - вече си "налапал лайната" (извинете френския ми) - това значи че си "осрал" тотално дизайна било поради грешен анализ, било поради грешна насока в писането на кода. Мисля че в кода доста неща си остават неясни, особено когато сглобите парчетата и тима седне да види цялото - интегрити тестинг се прави най-вече по тази причина.

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

ППП: Търся диалог, не караница. Надявам се да го получа.
=====================
Муслон
=====================
Хъ и аз искам диалог.

Мисля, че не се разбираме защото идеите ни за разработка на софтуер са много различни. Аз обичам леките методи, концентрирани върху директната бизнес стойност от всяка практика. Това дето го казваш за масираното кодиране след масиран дизайн след масиран анализ си мирише на класически водопад. Естествено, че ще ти трябва документация, когато обратната връзка идва след месеци и тогава вече не знаеш какво е ставало. Естествено, че ще искаш да се пазиш от местния незаменим гений и неговите решения. Някъде четох, че водопадния модел е бил отречен от автора си малко след публикуването му.

Да приемем, че ползваш итеративен процес ( RUP? ). Всеки път минаваш през анализ, дизайн, кодиране, тестване? Колко дълги са тези периоди? Какво става ако по време на кодиране намерим недостатък в дизайна? Какво става ако докато тестваме намерим специален случай, който не се покрива в дизайна? Кога променяме дизайна? Колко се чака при тези промени? Кой плаща за времето прекарано в чакане и производство на документация?

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

( Без да искам да обиждам ) С изказването си за рефакторинга и как прилагането му означава, че дизайна е объркан показваш, че не знаеш какво е рефакторинг и никога не си опитвал да го прилагаш. Потърси в клуба предишната ми тема за митовете против рефакторинга. Накратко: рефакторинг прилагам постоянно, за да променя дизайна и да го направя по-добър. Работя на цикли от добавяне на нова функционалност, което често води до нечистотии и след това рефакторинг, за да излекувам и изчистя дизайна. Циклите са кратки - да кажем по 5-6 такива на час.

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

Грешната насока в писането на кода не я разбирам - нали всеки код се пише с някаква цел? Той или изпълнява целта или не. Проблемите при интеграция могат да се решат с по-честа интеграция. Като свърша парче работа по дадена функционалност - интегрирам. Ако го правя няколко пъти на ден шанса да се разминем с колегите е минимален. И дори и да се случи конфликт, ще бъде оправен за минути.

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

Не отричам дизайна като процес в разработката на софтуер. Казвам само, че трябва да се прави постоянно. Малко дисциплина, малко поддържащи практики и може да се направи. Може да звучи като парадокс, но когато престанеш да дизайнваш предварително и започнеш да отглеждаш дизайна еволюционно ще започнеш да виждаш невероятни неща. Има го и страха от озоваването на някакво тясно място откъдето измъкване няма защото не сме мислили преди това - от тази ситуация ни предпазва рефакторинга. За около година не ми се е случвало. Мисля, че опасността е преувеличена.
========================
Jamie
========================
така става "чаршаф" и не се чете леко :-)

Няма в случая "водопад". Не си прочел внимателно - казах че процеса на дизайн и кодиране не е напълно отделен - що се отнася до уточняване на възможностите на технологиите и избор на подходящата.
"Всеки път минаваш през анализ, дизайн, кодиране, тестване?"
Разсъждаваш повърхностно. Не минавам всеки път през ЦЕЛИЯ процес на анализ (изобщо не влиза в този цикъл), ре-дизайн, кодиране и тест. Оттам си отговори и за времето - с добър стартов анализ и дизайн времето за това "циклене" е малко. Плаща клиента - за да получи качество.

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

За рефакторинга - отричам го като идеология изцяло. Мислех че си го разбрал :-) Нуждата от рефакторинг доказва ялов анализ и дизайн.

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


"Грешната насока в писането на кода не я разбирам - нали всеки код се пише с някаква цел? Той или изпълнява целта или не. Проблемите при интеграция могат да се решат с по-честа интеграция. Като свърша парче работа по дадена функционалност - интегрирам. Ако го правя няколко пъти на ден шанса да се разминем с колегите е минимален. И дори и да се случи конфликт, ще бъде оправен за минути. "

Грешна насока е когато не съвпада със замисъла - когато имаш грешна бизнес-ориентация на приложението. Колкото до интеграцията и подхода ти - смехория :-)) Това означава тима да губи бая време просто да си държи главата над повърхността - и то защото например е "изхвърлил хартийката"... умно, няма що !

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

Ами ако от 2-годишния проект получа актуални диаграми, 200 страници реална документация (а не отбиване на номера) и синхронициран с всичко това код (както е трябвало да го напише кодера) - тогава какво ?
Как изглежда това сравнено с 3-4 страници фантазии нямащи общо с кода, код написан с идеята за виртуозност но нечитаем, сюрия тестове които след елементарна промяна в кода показват грешки в 60% от въпросния код просто защото например класовете страдат от вече цитирания от мен "коуплинг" ?
Как ти изглежда това ?

Приятел, ти ми миришеш на почитател на екстрийм програминг. Няма лошо - но той съсщо си има недостатъци наред с предимствата.

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

Отговарям на последното мнение на 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

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

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

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

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

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


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

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

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

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



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

UB40 !

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

Jamie,
Виждал ли си някога проект в който всички документи са up-to-date. Аз по колкото проекти съм работил единствения точен документ, който казва какво прави продукта е сорс кода. Предпочитам да имам добре оформен и ясен код, отколкото един куп out-of-date диаграми.

> Виждал ли си някога проект в който всички документи са up-to-date
Да, последният по който работя - и така наистина е много добре.

> какво прави продукта е сорс кода
дай го като потребителска документация на клиента или на шефа си да видим дали ще разбере какво прави програмата

...
Абе искам да кажа, че изцяло съм съгласен с jamie но не поради същата причина като него ;)

Просто като се пише един проект ТРЯБВА да се прави дизайн. В повечето случай клиента няма ясна представа какво се иска от системата, така, че PM трябва да направи поне малко use-case диаграми за детайлизира какво точно се очаква. После клиента ги вижда и казва поне още 10 features. Този процес е полезен най-вече, защото клиента добива ясна представа какво иска, а екипа, който ще работи по програмата знае какво ще прави.

След това следва работата на архитекта - а тя е да опише границите на системата и да обособи подсистемите. Естествено трябва да дефинира и интерфейсите за комуникация.

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

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

Иначе няма нищо лошо да си пише код докато се прави дизайн. Протипите са именно за тази цел - да решат някой по-особенни и трудни дизайнерски проблеми.

Колкото до UML - може и без него, но той е най-доброто. Можеш да показваш колкото си искаш таблички или списъци с features на програмата, но една UML диаграма е много по-лесно за възприемане. Просто като я погледнеш и ти става ясно. А щом клиента е наясно и е довелен, ще има и парички, т.е целта на проекта е оправдана ;)


Абе в крайна сметка всичко е бизнес и пари. Колкото повече дизайн, толкова по-малко работа за програмисти, защото не правят едно и също нещо по 10 пъти. А и така проектите се реализират много по-бързо.

>> Виждал ли си някога проект в който всички документи са up-to-date
>Да, последният по който работя - и така наистина е много добре.

Късметлия си. Аз колкото съм работил не съм виждал такова нещо (е, нямам чак толкова много опит, де:).

>> какво прави продукта е сорс кода
>дай го като потребителска документация на клиента или на шефа си да видим дали ще разбере какво прави програмата

Не съм казал нищо за потребителска документация. Дай на потребителя клас диаграмите или примерно деплоймънт и да видим ква ще му е файдата от това.


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

Другата възможност е - дизайна да еволюира. Т.е. да почнеш с просто и чак като / ако потрябва да го усложняваш. Пак може да завършиш със същите неща, но това ще означава, че наистина ти трябват. В тоя случай в началото пак имаш някакво изясняване на това какво правиш (анализ). То без това не може. Ама можеш доста по-бързо да изкараш работещо нещо и да видиш има ли смисъл от него. В горния подход - да можеш да правиш прототип.

Аз поне така ги виждам / разбирам нещата.

И един въпрос за УМЛ пак:

Наистина ли една секуенсе диаграма описваща сортировка е по-лесно четима от 10 ред код?

Тоест? При перфектен "архитект" и UML мога да наема една дузина "кодери" от улицата и мога да си направя операционна система?

Много утопично е твърдението, че можеш да направиш UML схема на целия проект, да генерираш стъбовете на класовете и оттам да дадеш на code-monkeys да се оправят докато ти си пиеш кампарито на Бахамите. В реалност се получават толкова много изменения на оригиналния дизайн и толкова промени, че всяка промяна на UML-а означава купове поправка на кода отдолу като резултата е кръпка до кръпка и продукт - боза.

С това не казвам, че не трябва да има планиране и предварителен дизайн, а просто че UML добавя extra-layer от диаграми, документи и пр. които трябва да се преправят наред с всичко друго - резултата е невероятно количество излишна бумащина, която се синхронизира с кода и документацията адски трудно. Този layer е според мен напълно излишен _освен_ ако всичките членове на екипа нямат 20 сериозни проекта зад гърба си и знаят за какво става дума. Иначе минусите са повече от плюсовете.

Jamie e 100% prav spored mene.
Spored mene hodeiki mezdu darvetata nikoga niama da se vidi kolko e goliama gorata, osven ako tova koeto te zaobikalia ne e gorichka ili hrastalaci.

Май имаме няколко неразбирания, ще се опитам да ги обобщя, че наистина се получава ужасна размяна на огромни количества текст.

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

Мисля, че стана по-ясно коя страна подкрепям - бих искал да видя примери ( по възможност реални ) и причини, които да показват преимуществата и недостатъците на двата подхода.

2) Документацията за програмистите и УМЛ диаграмите - тези междинни артефакти на производствения процес. Генерирането на тези "творби" отнема време и усилия, поддържането им също - за какво го правим? Каква реална бизнес стойност ни носят и можем ли да ги заменим с нещо по-ефективно или по-леко?

Мога да обясня с какво са заменени в екстремното програмиране - набор от технологични и социални практики, които взаимно се допълват:
- On Site Customer -> анализ? дизайн? труден въпрос по ГУИ-то? човека е при теб - питай го
- Pair Programming -> труден проблем? не познаваш част от кода? работи заедно с един от хората, които са по-добре подготвени.
- Pervasive Testing -> важна промяна? пусни тестовете и ще видиш дали си счупил нещо. не помниш/не знаеш какво прави този клас - погледни теста, който показва смисъла от съществуването му. функционалността по историята готова ли е? виж потребителския тест.
- Refactoring - този "къдрав" регулярен израз по-добре да седи в отделен метод ValidateEmailAddress, че да не се чудим другия път какво прави! тази промяна беше лесна нали? остави кода в такова състояние, че и следващата да е такава. нашия дизайн не се разлага с времето и кръпките.

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

Перфектния архитект ще научи ли "кодерите от улицата" на добра разработка на софтуер? Ще размахва камшика, докато те пишат? Нещо се съмнявам.

Добри програмисти ще могат ли да еволюират достатъчно добър дизайн, че да износят проекта? Сигурно. Най-вероятно защото добрият програмист трябва да е и архитект. На "програмистите", които разчитат на детайлна спецификация и солидна библиотека с алгоритми и АПИ-та, за да си вършат работата като пчелички, един колега викаше просто "скриптьори".

Самотен супер-архитект ще може ли да излезе напред в състезанието с отбор от кретени? Група програмисти над средното ниво ще успеят ли да го изпреварят без да имат архитект? Това се опитваме да разберем.

Проект прави ли се с калпави хора? Тц!

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