|
До колко може да се изкара един проект без дизайн? Без начален, но с много постоянен и своевременен дизайн! Кодът и дизайнът разделени ли са? Разделени ли са от анализа, изискванията, бизнес нуждите зад проекта?
Различните подходи на различните методологии. Аз съм от 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
|
Дизайн, Гъвкавост, Промени в различни методологии
