Здравствуйте, thesz, Вы писали:

T>>>В .Net и Java отвратительная статическая типизация, это я тебе ответственно заявляю и здесь многие поддержат это моё мнение.
G>>Да и я поддержу.

T>>>Неудивительно, что в них применяется метод из совсем уж слабых языков программирования.
G>>А вот тут не согласен. Тестирование и TDD вполне достойные методы сами по себе.
G>>Ты все пытаешься доказать что при хорошей системе типов они не нужны, но как-то неубедительно.

T>Нужно функциональное тестирование, а не интеграционное и ниже уровнями.

Если тестирование уровнями ниже вполне заменяется статическими проверками, то да. Но если написание типов гораздо сложнее (требует больше знаний и\или времени) чем написание тестов, то тесты могут оказаться выгоднее.

Здравствуйте, AndrewVK, Вы писали:

G>>А чего ты тогда хочешь доказать?
AVK>То что применимость TDD ограничивается, как минимум, формализуемостью конечного результата.
Функциональные требования вполне формальны или формализуемы. Для реализации этих требований и подходит TDD.
Есть еще нефункционалтные треования, для которых возможно TDD не подойдет вообще, но их небольшая часть.

G>>>>Во-вторых при правльном применении
AVK>>>Опять бла-бла-бла. Ты не мудри, ты пальцем покажи.
G>>http://blog.wekeroad.com/mvc-storefront/kona-2/
AVK>Что я там должен увидеть?
Скринкаст.

G>>Если оптимизиация вызывает изменнеие дизайна, то надо переделать тесты.
AVK>Курица или яйцо? Откуда взялись изначальные тесты?
При первоначальной реализации требований.


AVK>>>То есть ты с определением в википедии не согласен? Приведи другое определение из какого нибудь внешнего по отношению к тебе источника.
G>>Я уже давно выяснил, написанное в википедии про TDD\BDD\DDD\IoC и прочие буквосочетания имеет мало общего с реальностью. Написано может быть и правильно, но не то что нужно.
G>>Поэтому предпочитаю смотреть код и смотреть как люди пишут этот код.

AVK>

AVK>Приведи другое определение из какого нибудь внешнего по отношению к тебе источника.

AVK>Если не можешь, так и скажи.
Я вообще в определениях не силен, лучше ссылки накидаю на демонстрацию TDD.

G>>Какой конкретики?
AVK>Ответов на конкретные вопросы. Я тебе их уже много в этом топике задавал.
Какие из них связаны с написанием\дизайном кода?
Отвечать на вопросы мироздания с помощью TDD не получится.

G>>Если хочешь — давай конкретные требования
AVK>А если их нет, конкретных и формальных? Если у меня они есть, я и без тебя знаю, что да как. Наличие таких требований уже больше 50% решения задачи.
Для формализации требований применяются свои средства, не имеющие отношения к дизайну кода.

G>>А я не говорил что ты его не использовал
AVK>Тогда к чему тирада про устриц? Ты кого имел в виду?

G>>, я лишь говорю что если мнение о TDD построено на википедии
AVK>Нет, мое мнение не построено на википедии. Просто в википедии, на мой взгляд, вполне неплохое изложение идеи. И, уж извини, какой бы плохой википедия не была, я ей как то больше доверяю, чем твоим бездоказательным утверждениям, основанным на том, что ты где то что то непонятно что видел или читал. Да, на всякий случай — умные книжки про TDD читал, реальные проекты с его использованием видел, и даже сам применял. Так что больше не стоит про устриц или непонимание, ок?
Ну тогда не стоит ссылками из википедии кидаться, у меня скоро на них отторжение будет.

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, gandjustas, Вы писали:

AVK>>>Предположим. Тогда на момент написания тестов TDD мы никакой конкретикой по прежнему не знаем, точной спецификации нет. Значит и тесты непонятно как писать.
G>>И как в таких условиях вообще код писать или проектированием заниматься?
AVK>А что, ты не смог бы? Обыкновенно — включаешь моск и вперед.
Я бы сначала уточнением требований занаялся. Хотя бы usecase (или как принятол называть у агилистов user stories) собрать, они достаточно формальны чтобы по ним можно было код писать.


G>>>>Я в прототипах не парюсь и пишу логику в button_click, никаким дизайном там и не пахнет.
AVK>>>Я что то как то не уловил смысла этой фразы. Не мог бы ты поподробнее свою мысль изложить?
G>>Мысль в том что прототим делается не для дизайна, а для того чтобы более наглядно представить требования или идею, которую хочется реализаовать.

AVK>Тогда возвращаемся к началу — если нет формальных требований, а есть лишь набор критериев и относительная важность каждого из них, как применять TDD? Формальные тесты уже, в немалой степени, определят дизайн решения на уровне контрактов юнитов. А у нас как раз и стоит задача разработки такого дизайна, а не чтобы тупо налопатить код в рамках готового дизайна.
Не понимаю как это. Вот есть набор критериев: чтобы быстро работало и чтобы было читаемо, ни слова о функциональности.
Что тут можно написать?
А если есть функциональность, тогда пишем тесты, делаем функционал, помня о читаемости подключаем тулзы проверки coding styles\design guidelines, после прохождения всех тестов показываем заказчику (или проводим нагрузочное тестирование), если быстродействие устраивает то сделали, если нет, тогда оптимизируем.

G>>Прототип помогает избавиться от неопределенности и противоречивости в требованиях.
AVK>Каким образом, интересно? Можно на конкретном примере?
Об этом написано в книге «Программист-прагматик» Эндрю Ханта и Дэйва Томаса.

Здравствуйте, gandjustas, Вы писали:

G>Я бы сначала уточнением требований занаялся.

Ты не понял — уточнять не у кого, прото потому что более точных требований не существует в природе.

G> Хотя бы usecase (или как принятол называть у агилистов user stories) собрать, они достаточно формальны чтобы по ним можно было код писать.

Да ну брось ты, они как раз таки как правило неформальны. А может и вообще не быть, потому что источник изменения внутри. Или может быть много, противоречивых.

G>Не понимаю как это. Вот есть набор критериев: чтобы быстро работало и чтобы было читаемо, ни слова о функциональности.

Почему ни слова. К функциональности тоже критерии — например, некая функциональность должна стать удобнее. Или для некоторой подсистемы Х должен улучшиться код ее использования. Ну и поом — что, на нефункциональные требования вообще забиваем? Или ты хочешь сказать, что они не влияют на дизайн? Или ты считаешь, что при TDD нужно реализовать функциональные требования, а потом начинать рефакторить дизайн и тесты в угоду требованиям нефункциональным?

G>А если есть функциональность, тогда пишем тесты, делаем функционал, помня о читаемости подключаем тулзы проверки coding styles\design guidelines, после прохождения всех тестов показываем заказчику (или проводим нагрузочное тестирование), если быстродействие устраивает то сделали, если нет, тогда оптимизируем.

А если в текущем дизайне быстродействие улучшить не удается и надо серьезно этот дизайн менять? Выкидываем тесты и забиваем на TDD?

AVK>>Каким образом, интересно? Можно на конкретном примере?
G>Об этом написано в книге

Гы

Здравствуйте, gandjustas, Вы писали:

AVK>>То что применимость TDD ограничивается, как минимум, формализуемостью конечного результата.
G>Функциональные требования вполне формальны или формализуемы.

Любые? Это даже не смешно.

G>Есть еще нефункционалтные треования, для которых возможно TDD не подойдет вообще, но их небольшая часть.

Оценка на чем основана? Опять исключительно на твоих проектах? Или на чтении книжек?

G>>>>>Во-вторых при правльном применении
AVK>>>>Опять бла-бла-бла. Ты не мудри, ты пальцем покажи.
G>>>http://blog.wekeroad.com/mvc-storefront/kona-2/
AVK>>Что я там должен увидеть?
G>Скринкаст.

Ясно, опять, вместо ответа на вопрос демонстрации на игрушечных примерах.

AVK>>Курица или яйцо? Откуда взялись изначальные тесты?
G>При первоначальной реализации требований.

А мы, если ты заметил, именно о первоначальной реализации и говорим.

G>Я вообще в определениях не силен, лучше ссылки накидаю на демонстрацию TDD.

Лучше — не надо. Потому что это не отвечает на мои вопросы. Я сам могу так красиво подобрать пример, чтобы TDD работал. Вопрос то не в том, что да как с TDD, где оно хорошо подходит, а в том, что да как, если подходит плохо.
Давай тебе еще один пример. Хочу я, к примеру (судя по твоим агитациям, ты с предметом хорошо знаком), сбацать свой IoC контейнер. У меня при этом есть ряд притензий к контейнерам существующим + желание сделать качественный дизайн. Не какой то конкретный, а качественный. Теперича я хочу этот дизайн таки воплотить в жизнь при помощи TDD. Именно дизайн, собственно реализация там смешная, ничего проблематичного, оно меня не интересует. Вот и раскажи мне последовательность действий.

AVK>>Ответов на конкретные вопросы. Я тебе их уже много в этом топике задавал.
G>Какие из них связаны с написанием\дизайном кода?

С дизайном — все.

G>Отвечать на вопросы мироздания с помощью TDD не получится.

Я от тебя наоборот конкретики прошу, а ты мне как раз таки все больше про мироздание.

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

А требования к дизайну, их тоже делают средствами, не имеющими отношения к дизайну?

G>Ну тогда не стоит ссылками из википедии кидаться

Ну ты то ничего лучше не можешь сказать. Ок, давай тогда расскажи, что тебе в википедии не нравится. Конкретно.

G>, у меня скоро на них отторжение будет.

Ага, тяжело оно, когда конкретика

T>>Люди, пишущие на Perl, не знают, что такое REPL. Полный абзац.
N>Знаешь, я тоже, как журденовский герой, не знал этого сокращения, пока не заглянул после твоего постинга в словарь (хотя использую ежедневно). Потому что у нас это называется "language interpreter shell" В то же время _расшифрованная_ аббревиатура была понятна с первой же секунды.

N>Если ты хотел этим REPL показать уровень, то пример выбран явно неудачно.

Везде это REPL.
Там language interpreter shell.
Нет слов.

15 слогов, конечно, не требуемые 17, но и так неплохо.

T>>Нужно функциональное тестирование, а не интеграционное и ниже уровнями.

G>Если тестирование уровнями ниже вполне заменяется статическими проверками, то да. Но если написание типов гораздо сложнее (требует больше знаний и\или времени) чем написание тестов, то тесты могут оказаться выгоднее.

Написание типов требует разительно меньше строк кода. Типы хранятся рядом с вычислениями, а не в отдельном файле (как обычно бывает с тестами). Типы не требуют специальной системы сборки.

Наличие большего количества знаний выгодно на длительном промежутке времени. Стратегически, так сказать.

Здравствуйте, thesz, Вы писали:

T>thesz взял это выражение из одного из текстов Yello (конкретно, Bostich), где в своё время было nes pa (а сейчас уже того варианта не найти).

Я к чему всё это — вот так флеймы и рождаются

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, gandjustas, Вы писали:

G>>Я бы сначала уточнением требований занаялся.
AVK>Ты не понял — уточнять не у кого, прото потому что более точных требований не существует в природе.
Ок, приведи пример.

G>> Хотя бы usecase (или как принятол называть у агилистов user stories) собрать, они достаточно формальны чтобы по ним можно было код писать.
AVK>Да ну брось ты, они как раз таки как правило неформальны. А может и вообще не быть, потому что источник изменения внутри. Или может быть много, противоречивых.
Неверно слово написал, сами usecase неформальны, но функциональность системы вполне формализуема по ним.

G>>Не понимаю как это. Вот есть набор критериев: чтобы быстро работало и чтобы было читаемо, ни слова о функциональности.

AVK>Почему ни слова. К функциональности тоже критерии — например, некая функциональность должна стать удобнее. Или для некоторой подсистемы Х должен улучшиться код ее использования.
и что такой криетрий дает?

AVK>Ну и поом — что, на нефункциональные требования вообще забиваем? Или ты хочешь сказать, что они не влияют на дизайн? Или ты считаешь, что при TDD нужно реализовать функциональные требования, а потом начинать рефакторить дизайн и тесты в угоду требованиям нефункциональным?
Почти так. Нефункциональные требования должны учитываться при дизайне, но сами по себе они никак дизайн не определяют.

G>>А если есть функциональность, тогда пишем тесты, делаем функционал, помня о читаемости подключаем тулзы проверки coding styles\design guidelines, после прохождения всех тестов показываем заказчику (или проводим нагрузочное тестирование), если быстродействие устраивает то сделали, если нет, тогда оптимизируем.

AVK>А если в текущем дизайне быстродействие улучшить не удается и надо серьезно этот дизайн менять? Выкидываем тесты и забиваем на TDD?
При TDD получается слабосвязный код, подменить один компонент другим (гораздо более быстродейственным) ничего не стоит.

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, gandjustas, Вы писали:

AVK>>>То что применимость TDD ограничивается, как минимум, формализуемостью конечного результата.
G>>Функциональные требования вполне формальны или формализуемы.
AVK>Любые? Это даже не смешно.
Это правда. Все зависит от желания того кто занимается анализом.

G>>Есть еще нефункционалтные треования, для которых возможно TDD не подойдет вообще, но их небольшая часть.
AVK>Оценка на чем основана? Опять исключительно на твоих проектах? Или на чтении книжек?
На проектах, моих и не только.
Есть факты, подтверждающие обратное — говори.

AVK>Ясно, опять, вместо ответа на вопрос демонстрации на игрушечных примерах.
Там не игрушечный пример.

AVK>>>Курица или яйцо? Откуда взялись изначальные тесты?
G>>При первоначальной реализации требований.
AVK>А мы, если ты заметил, именно о первоначальной реализации и говорим.
И как ты эту реализацию делать собираешься если у тебя нету ни одного функционального требования?
Вот сделай программу: интерфейс должен быть удобным, они должна работать быстро, код должен быть простой в поддержке.

G>>Я вообще в определениях не силен, лучше ссылки накидаю на демонстрацию TDD.
AVK>Лучше — не надо. Потому что это не отвечает на мои вопросы. Я сам могу так красиво подобрать пример, чтобы TDD работал. Вопрос то не в том, что да как с TDD, где оно хорошо подходит, а в том, что да как, если подходит плохо.
Ну так приведи адекватный пример, где подходит плохо, а то единственное что ты пока придумал — полное отсуствие функциональных требований, но в таких условиях вообще ни одна программа не будет написана.
Пока что был один пример где TDD не работает — concurrency, но там вообще мало чего работает, особенно если рассматривать мэинстримовые языки.

AVK>Давай тебе еще один пример. Хочу я, к примеру (судя по твоим агитациям, ты с предметом хорошо знаком), сбацать свой IoC контейнер. У меня при этом есть ряд притензий к контейнерам существующим + желание сделать качественный дизайн. Не какой то конкретный, а качественный. Теперича я хочу этот дизайн таки воплотить в жизнь при помощи TDD. Именно дизайн, собственно реализация там смешная, ничего проблематичного, оно меня не интересует. Вот и раскажи мне последовательность действий.
Ну рассказывай, какой функционал ты хочешь от этого контейнера?

AVK>>>Ответов на конкретные вопросы. Я тебе их уже много в этом топике задавал.
G>>Какие из них связаны с написанием\дизайном кода?
AVK>С дизайном — все.
покачто ни одного.

G>>Ну тогда не стоит ссылками из википедии кидаться
AVK>Ну ты то ничего лучше не можешь сказать. Ок, давай тогда расскажи, что тебе в википедии не нравится. Конкретно.
Еще раз, в википедии написано может быть правильно, но совсем не то что нужно.
То что нужно — лучше показывать, чем описывать словами.

Здравствуйте, gandjustas, Вы писали:

AVK>>Ты не понял — уточнять не у кого, прото потому что более точных требований не существует в природе.
G>Ок, приведи пример.

Я уже приводил два примера.

AVK>>Да ну брось ты, они как раз таки как правило неформальны. А может и вообще не быть, потому что источник изменения внутри. Или может быть много, противоречивых.
G>Неверно слово написал, сами usecase неформальны, но функциональность системы вполне формализуема по ним.

Вот в этом я сильно не уверен. Например, не получив прототип дизайна, нельзя с абсолютной уверенностью выбрать золотую середину между противоречивыми требованиями. Как следствие — до появления дизайна первой итерации противоречие это разрешить не получится.

AVK>>Почему ни слова. К функциональности тоже критерии — например, некая функциональность должна стать удобнее. Или для некоторой подсистемы Х должен улучшиться код ее использования.
G>и что такой криетрий дает?

Направление эволюции дизайна.

G>Почти так. Нефункциональные требования должны учитываться при дизайне, но сами по себе они никак дизайн не определяют.

То есть, к примеру, читаемость и легкость модификации кода не определяют дизайн? Ну, мягко говоря, это очень спорно.

AVK>>А если в текущем дизайне быстродействие улучшить не удается и надо серьезно этот дизайн менять? Выкидываем тесты и забиваем на TDD?
G>При TDD получается слабосвязный код, подменить один компонент другим (гораздо более быстродейственным) ничего не стоит.

Не путай божий дар с яишницей. Легко или сложно, это второй вопрос. Главное — ресурсы, потраченные на тесты, которые вперед, потрачены будут впустую.

Здравствуйте, gandjustas, Вы писали:

AVK>>>>То что применимость TDD ограничивается, как минимум, формализуемостью конечного результата.
G>>>Функциональные требования вполне формальны или формализуемы.
AVK>>Любые? Это даже не смешно.
G>Это правда.

Это не правда. Продолжим?

AVK>>Оценка на чем основана? Опять исключительно на твоих проектах? Или на чтении книжек?
G>На проектах, моих и не только.
G>Есть факты, подтверждающие обратное — говори.

О, я таких же как ты "фактов" — легко. Мои проекты говорят, что TDD привносит только проблемы и лишнюю трату ресурсов, давая на выходе крошечный бенефит. Твоя очередь

AVK>>Ясно, опять, вместо ответа на вопрос демонстрации на игрушечных примерах.
G>Там не игрушечный пример.

Он игрушечный в том плане, что заранее подходит для TDD.

AVK>>А мы, если ты заметил, именно о первоначальной реализации и говорим.
G>И как ты эту реализацию делать собираешься если у тебя нету ни одного функционального требования?

А кто сказал что ни одного?

G>Ну так приведи адекватный пример

Я уже приводил. Если примеры тебе не нравяться, я не виноват. Удобного для тебя примера, я, очевидно, не приведу, в том то и суть.

G>, где подходит плохо, а то единственное что ты пока придумал — полное отсуствие функциональных требований, но в таких условиях вообще ни одна программа не будет написана.

Я тебе привел два конкретных примера. Про полное отсутствие функциональных требований ты придумал сам.

G>Ну рассказывай, какой функционал ты хочешь от этого контейнера?

Упрощение разработки определенного типа приложений.

G>>>Ну тогда не стоит ссылками из википедии кидаться
AVK>>Ну ты то ничего лучше не можешь сказать. Ок, давай тогда расскажи, что тебе в википедии не нравится. Конкретно.
G>Еще раз, в википедии написано может быть правильно, но совсем не то что нужно.

Так, еще раз — в википедии написано конкретное определение. Это именно то, что нужно. Либо ты соглашаешься с тем, что написано там все верно, либо свои притензии к источнику определения оставляешь при себе.

G>То что нужно — лучше показывать, чем описывать словами.

Ясно. Я тебе так скажу — если ты даже базовые вещи не можешь сформулировать, ни о каком твоем понимании TDD говорить не приходится. И обвинения твои в том, что не понимает TDD кто то там, они выглядят, сам понимаешь.

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, gandjustas, Вы писали:

AVK>>>Ты не понял — уточнять не у кого, прото потому что более точных требований не существует в природе.
G>>Ок, приведи пример.
AVK>Я уже приводил два примера.
Один с IoC — с формальными требованиями по функционалу, их неформально описать даже не получится, так что не подходит.
А второй — что?

AVK>>>Да ну брось ты, они как раз таки как правило неформальны. А может и вообще не быть, потому что источник изменения внутри. Или может быть много, противоречивых.
G>>Неверно слово написал, сами usecase неформальны, но функциональность системы вполне формализуема по ним.
AVK>Вот в этом я сильно не уверен. Например, не получив прототип дизайна, нельзя с абсолютной уверенностью выбрать золотую середину между противоречивыми требованиями. Как следствие — до появления дизайна первой итерации противоречие это разрешить не получится.
Если не получается самомтоятельно снять неопределенность, то прототип надо показывать заказчину\будущим пользователями.


AVK>>>Почему ни слова. К функциональности тоже критерии — например, некая функциональность должна стать удобнее. Или для некоторой подсистемы Х должен улучшиться код ее использования.
G>>и что такой криетрий дает?
AVK>Направление эволюции дизайна.
"некая функциональность должна стать удобнее" какое направление эволюции дизайна дает?

G>>Почти так. Нефункциональные требования должны учитываться при дизайне, но сами по себе они никак дизайн не определяют.
AVK>То есть, к примеру, читаемость и легкость модификации кода не определяют дизайн? Ну, мягко говоря, это очень спорно.
Вообще не опеределяют, так как величины эмпирические. Невозможно задать целевое значение этой характеристики и его добиваться при разработке.
Кроме того понятия читаемости и легкости модификации сильно субъективны и зависят от того, кто будет чтением и модификацией заниматься.

AVK>>>А если в текущем дизайне быстродействие улучшить не удается и надо серьезно этот дизайн менять? Выкидываем тесты и забиваем на TDD?
G>>При TDD получается слабосвязный код, подменить один компонент другим (гораздо более быстродейственным) ничего не стоит.
AVK>Не путай божий дар с яишницей. Легко или сложно, это второй вопрос. Главное — ресурсы, потраченные на тесты, которые вперед, потрачены будут впустую.
А с чего ты взял что впустую?
1)тесты написанные перед кодом фиксируют требования к этому коду, поэтому не надо держать требования в голове, что сильно упрощает процесс разработки
2)тесты написанные перед кодом кокретно определяют функциональность, которую требуется достичь, поэтому возникает гораздо меньше желания писать код, не относящийся к делу
3)упрщается рефакторинг кода во время написания, так как тесты уже есть

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, gandjustas, Вы писали:

AVK>>>>>То что применимость TDD ограничивается, как минимум, формализуемостью конечного результата.
G>>>>Функциональные требования вполне формальны или формализуемы.
AVK>>>Любые? Это даже не смешно.
G>>Это правда.
AVK>Это не правда. Продолжим?
Вырывать слова из контекста это такой прием демагогии?
Всетаки приведи пример требований с неформализуемым набором функционала, чтобы по ним можно было написать код.

AVK>>>Оценка на чем основана? Опять исключительно на твоих проектах? Или на чтении книжек?
G>>На проектах, моих и не только.
G>>Есть факты, подтверждающие обратное — говори.

AVK>О, я таких же как ты "фактов" — легко. Мои проекты говорят, что TDD привносит только проблемы и лишнюю трату ресурсов, давая на выходе крошечный бенефит. Твоя очередь
А в мои проекты TDD внесло дофига бенефитов, начиная от более качественного дизайна, заканчивая сокращением плотности ошибок на стейджинге в 10 раз и уменьшением объема рабочего кода примерно в 2 раза.
Самый кайф был гогда отали тестеру версию и через день он начал ругаться что не может найти ни одной ошибки в логике, только огрехи в интерфейсе.

AVK>>>Ясно, опять, вместо ответа на вопрос демонстрации на игрушечных примерах.
G>>Там не игрушечный пример.
AVK>Он игрушечный в том плане, что заранее подходит для TDD.

Чем подходит? тем что у него функциональные требования есть?
Там обычный интернет-магазин.

Также стоит посмотреть начало серии mvc storefront http://www.asp.net/learn/mvc-videos/
А также http://ayende.com/hibernating-rhinos.aspx ролик под номером 1.

G>>Ну рассказывай, какой функционал ты хочешь от этого контейнера?
AVK>Упрощение разработки определенного типа приложений.
Какого?

Вот представляю себе картину, приходит к тебе заказчик и говорит: "сделайте мне программу, которая упрощает определенные операции бухучета".

AVK>Так, еще раз — в википедии написано конкретное определение.
Думаешь в TDD определение имеет какое-то значение?

AVK>Это именно то, что нужно.
Само определение нафиг никому не нужно.

AVK>Либо ты соглашаешься с тем, что написано там все верно, либо свои притензии к источнику определения оставляешь при себе.
А я не говорю что неверно, я говорю что там не то что надо.

G>>То что нужно — лучше показывать, чем описывать словами.
AVK>Ясно. Я тебе так скажу — если ты даже базовые вещи не можешь сформулировать, ни о каком твоем понимании TDD говорить не приходится. И обвинения твои в том, что не понимает TDD кто то там, они выглядят, сам понимаешь.
Плохо у тебя с логикой.
На доуге попробуй описать словами процесс завязывания шнурков бантиком. (как вариант — наматывание портянок)
Поймешь насколько легче это показать, чем объяснять.

Аналогичная картина с IoC, DDD и некоторыми другоми акронимами. Пока не не увидишь как это делается — сути не поймешь.

Здравствуйте, gandjustas, Вы писали:

G>Один с IoC — с формальными требованиями по функционалу, их неформально описать даже не получится

Так, ты кажется что то не понимаешь. Формальные требования к функционалу меня не колышат. Потому что они примитивны. Меня колышет внешний дизайн фреймворка. Я же ведь не зря акцентировал на том, что собственно реализация там смешная и очевидная. Вопрос в том, каков должен быть дизайн, и как, не имея этого дизайна, написать тесты. Вот это вопрос из вопросов.

G>, так что не подходит.

Подходит.

G>А второй — что?

UI настроек решарпера.

G>Если не получается самомтоятельно снять неопределенность, то прототип надо показывать заказчину\будущим пользователями.

Можно и показать. Как с тестами быть?

AVK>>Направление эволюции дизайна.
G>"некая функциональность должна стать удобнее" какое направление эволюции дизайна дает?

В направлении упрощения использования этой функциональности и увеличения количества покрываемых сценариев. Это если у тебя заказной софт, тогда ты можешь выдаивать из заказчика формальные требования, а потом делать умное лицо и говорить что заказчик сам виноват, что требования такие кривые. А если коробка — то никакого специального заказчика то и нет. Опять же, можно конечно кормить специяльного аналитега, но тогда получаются уродливые дизайны, где в угоду мелким фичушкам принесен и дизайн, и юзабилити, и стабильность, и целостность продукта. И все это уже совсем выбегает за рамки топика.

AVK>>То есть, к примеру, читаемость и легкость модификации кода не определяют дизайн? Ну, мягко говоря, это очень спорно.
G>Вообще не опеределяют, так как величины эмпирические. Невозможно задать целевое значение этой характеристики и его добиваться при разработке.

Ну вот видишь. Только у меня выводы совсем другие. Я лучше TDD отправлю в мусорку, чем ради него буду городить дизайн, который приводит к уродливому коду.

G>Кроме того понятия читаемости и легкости модификации сильно субъективны

Они в большой степени объективны.

AVK>>Не путай божий дар с яишницей. Легко или сложно, это второй вопрос. Главное — ресурсы, потраченные на тесты, которые вперед, потрачены будут впустую.
G>А с чего ты взял что впустую?

С того, что выхлопа 0.

G>1)тесты написанные перед кодом фиксируют требования к этому коду

Само по себе ценности не имеет.

G>, поэтому не надо держать требования в голове, что сильно упрощает процесс разработки

Помимо головы и кода есть масса различных вариантов, включая специализированный софт.

G>2)тесты написанные перед кодом кокретно определяют функциональность, которую требуется достичь

К сожалению, помимо функционала, они еще определяют и дизайн внешних контрактов. И именно в этом и проблема.

G>3)упрщается рефакторинг кода во время написания, так как тесты уже есть

С чего это он упрощается? Он усложняется. Тесты сильно мешают массированному рефакторингу, потому что ломаются не из-за ошибок, а из-за изменения дизайна контрактов. Тесты хороши, когда рефакторится реализация, а не дизайн, причем желательно подальше от тестов.
Вот именно поэтому TDD в ряде случаев и вызывает вопросы. Потому что на начальной стадии, как правило, дизайн плавает очень сильно, а TDD как раз на этой стадии тесты и навязывает.

Здравствуйте, gandjustas, Вы писали:

AVK>>Это не правда. Продолжим?
G>Вырывать слова из контекста это такой прием демагогии?

Прием демагогии это обвинять в вырывании из контекста, при том что я процитировал несколько уровней и закончил на конце предложения, да и контекст уж тебе то должен быть знаком, не так ли?

G>Всетаки приведи пример требований с неформализуемым набором функционала, чтобы по ним можно было написать код.

Опять за рыбу гроши. Любой пример, который я приведу, тебе не понравится. Потому что ты не понимаешь, что ситуации бывают разные. Бывает, когда ты строчишь код по линейке, а бывает, что никто на этой планете не знает, какой дизайн в итоге будет получен. Потому что иногда не конкретный функционал пытаются непременно сформировать, а руководствуются наличествующими ресурсами и полезным выхлопом от той или иной работы. Потому что всегда есть trade off по целой пачке функциональных и нефункциональных требований, и выбирать среднюю точку без учета проблем существующего и теоретически возможного дизайна кода и всего, что с ним связано сродни плеванию в потолок, эффект тот же.
А архитект, который по предельно формальным требованиям формирует единственно верный дизайн, который потом девелоперы реализуют строго в рамках спецификаций за строго определенное время — такое в основном только в книжках бывает.

AVK>>О, я таких же как ты "фактов" — легко. Мои проекты говорят, что TDD привносит только проблемы и лишнюю трату ресурсов, давая на выходе крошечный бенефит. Твоя очередь
G>А в мои проекты TDD внесло дофига бенефитов, начиная от более качественного дизайна, заканчивая сокращением плотности ошибок на стейджинге в 10 раз и уменьшением объема рабочего кода примерно в 2 раза.

А в моих проектах TDD сильно увеличил затраты ресурсов и резко снизил скорость эволюции дизайна в процессе разработки. Твой ход.
Детский сад, штаны на лямках.

AVK>>Он игрушечный в том плане, что заранее подходит для TDD.
G>
G>Чем подходит?

Тем что TDD на нем показывает высокую эффективность.

G> тем что у него функциональные требования есть?
G>Там обычный интернет-магазин.

Именно. Обычный интернет магазин, с которым заранее почти все ясно. Только не все проекты по уровню R&D интернет магазины.

G>Также стоит посмотреть начало серии mvc storefront http://www.asp.net/learn/mvc-videos/
G>А также http://ayende.com/hibernating-rhinos.aspx ролик под номером 1.

Я не буду длинные кина смотреть, время жалко. Все это я уже миллион раз видел.

G>>>Ну рассказывай, какой функционал ты хочешь от этого контейнера?
AVK>>Упрощение разработки определенного типа приложений.
G>Какого?

Например типа Visual Studio.

G>Вот представляю себе картину, приходит к тебе заказчик и говорит: "сделайте мне программу, которая упрощает определенные операции бухучета".

Кроме бухучетов и интернет-магазинов есть много интересных задач. И заказчик конкретный далеко не всегда имеется.

AVK>>Так, еще раз — в википедии написано конкретное определение.
G>Думаешь в TDD определение имеет какое-то значение?

Они имеет значение в этом топике. Потому что обсуждать что то, что ты даже вчерне описать не можешь — глупое и бессмысленное занятие.

AVK>>Это именно то, что нужно.
G>Само определение нафиг никому не нужно.

Конечно. Тогда так классно получится спорить. Всегда ведь можно сказать, что собеседник TDD не понимает. Еще бы, ведь что там у тебя в мозгах одному богу известно, а поделиться этим с окружающими ты не в состоянии.

AVK>>Либо ты соглашаешься с тем, что написано там все верно, либо свои притензии к источнику определения оставляешь при себе.
G>А я не говорю что неверно

То есть там верно? Да или нет?

G>, я говорю что там не то что надо.

Что значит не то что надо? А что надо? И почему не то что надо? Потому что то, что там написано напрямую опровергает твои заявления, но прямо обвинить в том, что там вранье, ты боишься?

AVK>>Ясно. Я тебе так скажу — если ты даже базовые вещи не можешь сформулировать, ни о каком твоем понимании TDD говорить не приходится. И обвинения твои в том, что не понимает TDD кто то там, они выглядят, сам понимаешь.
G>Плохо у тебя с логикой.

Плохо. Но не у меня.

G>На доуге попробуй описать словами процесс завязывания шнурков бантиком. (как вариант — наматывание портянок)

А чего пробовать. В инете такого навалом, можешь погуглить.

G>Аналогичная картина с IoC, DDD и некоторыми другоми акронимами.

Не надо свои проблемы переносить на всех остальных. Что такое IoC мне неоднократно удавалось без каких либо проблем, на пальцах, объяснять людям за 5 минут. Концепция примитивна как 5 пальцев, проще придумать сложно.

G> Пока не не увидишь как это делается — сути не поймешь.

Думаю, это твоя личная особенность.

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, gandjustas, Вы писали:

G>>Один с IoC — с формальными требованиями по функционалу, их неформально описать даже не получится

AVK>Так, ты кажется что то не понимаешь. Формальные требования к функционалу меня не колышат. Потому что они примитивны. Меня колышет внешний дизайн фреймворка. Я же ведь не зря акцентировал на том, что собственно реализация там смешная и очевидная. Вопрос в том, каков должен быть дизайн, и как, не имея этого дизайна, написать тесты. Вот это вопрос из вопросов.

Так ты и не говорил раньше что тебе нужна "внешняя красота".
Кстати в таком случае что-то вроде TDD работает: пишется код, в котором отражается какой API хотелось бы видеть (те самые "определенные сценарии"), а потом пишется код, который это реализует.

G>>А второй — что?
AVK>UI настроек решарпера.
Только к коду это не отностится.
Может еще и руководство пользователя с помощью TDD написать?

G>>Если не получается самомтоятельно снять неопределенность, то прототип надо показывать заказчину\будущим пользователями.
AVK>Можно и показать. Как с тестами быть?
В прототипе? Они там не нужны.

AVK>>>Направление эволюции дизайна.
G>>"некая функциональность должна стать удобнее" какое направление эволюции дизайна дает?

AVK>В направлении упрощения использования этой функциональности и увеличения количества покрываемых сценариев. Это если у тебя заказной софт, тогда ты можешь выдаивать из заказчика формальные требования, а потом делать умное лицо и говорить что заказчик сам виноват, что требования такие кривые. А если коробка — то никакого специального заказчика то и нет.
feedback кучи юзеров гораздо лучше одного заказчика с непостоянным мнением.
Кроме того изменчивость у коробочного софта поменьше.

AVK>>>То есть, к примеру, читаемость и легкость модификации кода не определяют дизайн? Ну, мягко говоря, это очень спорно.
G>>Вообще не опеределяют, так как величины эмпирические. Невозможно задать целевое значение этой характеристики и его добиваться при разработке.

AVK>Ну вот видишь. Только у меня выводы совсем другие.
Какие? С помощью каких способов ты можешь выполнит поставленные требования, типа "читаемость"?

AVK>Я лучше TDD отправлю в мусорку, чем ради него буду городить дизайн, который приводит к уродливому коду.
Повторенное дважды становится правдой?
С чего ты взял что TDD дает тебе уродливый дизайн? Скорее его отсуствие приведт к такому дизайну.

G>>Кроме того понятия читаемости и легкости модификации сильно субъективны
AVK>Они в большой степени объективны.
Докажи.

AVK>>>Не путай божий дар с яишницей. Легко или сложно, это второй вопрос. Главное — ресурсы, потраченные на тесты, которые вперед, потрачены будут впустую.
G>>А с чего ты взял что впустую?
AVK>С того, что выхлопа 0.
Ну это твои проблемы.

G>>1)тесты написанные перед кодом фиксируют требования к этому коду
AVK>Само по себе ценности не имеет.
Имеет, также как имеет ценность упомянутый тобой ниже "специализированный софт".

G>>, поэтому не надо держать требования в голове, что сильно упрощает процесс разработки
AVK>Помимо головы и кода есть масса различных вариантов, включая специализированный софт.
Какой специализированный софт проверит соотвествие куска кода требованиям к нему по нажатию одной кнопки?

G>>2)тесты написанные перед кодом кокретно определяют функциональность, которую требуется достичь
AVK>К сожалению, помимо функционала, они еще определяют и дизайн внешних контрактов. И именно в этом и проблема.

G>>3)упрщается рефакторинг кода во время написания, так как тесты уже есть
AVK>С чего это он упрощается? Он усложняется. Тесты сильно мешают массированному рефакторингу, потому что ломаются не из-за ошибок, а из-за изменения дизайна контрактов. Тесты хороши, когда рефакторится реализация, а не дизайн, причем желательно подальше от тестов.
AVK>Вот именно поэтому TDD в ряде случаев и вызывает вопросы. Потому что на начальной стадии, как правило, дизайн плавает очень сильно, а TDD как раз на этой стадии тесты и навязывает.

ОК, понял проблему. Она называется "нельзя вывести хороший дизайн и архитектуру из одних тестов", тесты навязывают решать проблемы локально, что может привести к тому, что за деревьями не видно будет леса.
Догматичное применение TDD и отказ от высокоуровневого проектирования — тот самый булшит, на который не стоит вестись.
Такой булшит часто появляется в словесном описании TDD, хотя мало кто такой подход использует (судя по тем же скринкастам).

Здравствуйте, AndrewVK, Вы писали:


G>>Всетаки приведи пример требований с неформализуемым набором функционала, чтобы по ним можно было написать код.

AVK>Опять за рыбу гроши. Любой пример, который я приведу, тебе не понравится. Потому что ты не понимаешь, что ситуации бывают разные. Бывает, когда ты строчишь код по линейке, а бывает, что никто на этой планете не знает, какой дизайн в итоге будет получен. Потому что иногда не конкретный функционал пытаются непременно сформировать, а руководствуются наличествующими ресурсами и полезным выхлопом от той или иной работы. Потому что всегда есть trade off по целой пачке функциональных и нефункциональных требований, и выбирать среднюю точку без учета проблем существующего и теоретически возможного дизайна кода и всего, что с ним связано сродни плеванию в потолок, эффект тот же.
Ладно, адекватных примеров не будет, это я понял.

AVK>А архитект, который по предельно формальным требованиям формирует единственно верный дизайн, который потом девелоперы реализуют строго в рамках спецификаций за строго определенное время — такое в основном только в книжках бывает.
Да, именно поэтому и придумали TDD.


AVK>>>О, я таких же как ты "фактов" — легко. Мои проекты говорят, что TDD привносит только проблемы и лишнюю трату ресурсов, давая на выходе крошечный бенефит. Твоя очередь
G>>А в мои проекты TDD внесло дофига бенефитов, начиная от более качественного дизайна, заканчивая сокращением плотности ошибок на стейджинге в 10 раз и уменьшением объема рабочего кода примерно в 2 раза.
AVK>А в моих проектах TDD сильно увеличил затраты ресурсов и резко снизил скорость эволюции дизайна в процессе разработки. Твой ход.
Из этого только вывод что ты не сумел применить TDD.


AVK>Именно. Обычный интернет магазин, с которым заранее почти все ясно. Только не все проекты по уровню R&D интернет магазины.
Ну да, ентерпрайз + веб по разным подсчетам занимают от 80% до 95% разработки, а они все не очень далеко ушли от тех же интернет-магазинов.


G>>Также стоит посмотреть начало серии mvc storefront http://www.asp.net/learn/mvc-videos/
G>>А также http://ayende.com/hibernating-rhinos.aspx ролик под номером 1.
AVK>Я не буду длинные кина смотреть, время жалко. Все это я уже миллион раз видел.
Судя по твоим постам — ни разу.

G>>>>Ну рассказывай, какой функционал ты хочешь от этого контейнера?
AVK>>>Упрощение разработки определенного типа приложений.
G>>Какого?
AVK>Например типа Visual Studio.
Там уже придумали MEF, тебе он не подходит? Чем не подходит? Опиши сценарии в которых ты хочешь свой контейнер применять.

AVK>>>Так, еще раз — в википедии написано конкретное определение.
G>>Думаешь в TDD определение имеет какое-то значение?
AVK>Они имеет значение в этом топике. Потому что обсуждать что то, что ты даже вчерне описать не можешь — глупое и бессмысленное занятие.
А ты перечитай топик сначала, я уже десяток раз описывал TDD.

AVK>>>Это именно то, что нужно.
G>>Само определение нафиг никому не нужно.
AVK>Конечно. Тогда так классно получится спорить. Всегда ведь можно сказать, что собеседник TDD не понимает. Еще бы, ведь что там у тебя в мозгах одному богу известно, а поделиться этим с окружающими ты не в состоянии.
См коммент выше.

AVK>>>Либо ты соглашаешься с тем, что написано там все верно, либо свои притензии к источнику определения оставляешь при себе.
G>>А я не говорю что неверно
AVK>То есть там верно? Да или нет?
Может быть и верно, я неочень внимательно читал.

G>>, я говорю что там не то что надо.
AVK>Что значит не то что надо? А что надо? И почему не то что надо? Потому что то, что там написано напрямую опровергает твои заявления, но прямо обвинить в том, что там вранье, ты боишься?
Да мне читать лениво что там написано, мне достаточно того что я успешно применяю TDD.


G>>На доуге попробуй описать словами процесс завязывания шнурков бантиком. (как вариант — наматывание портянок)
AVK>А чего пробовать. В инете такого навалом, можешь погуглить.
Ну напиши словами, или дай ссылку на википедию где это описано

G>>Аналогичная картина с IoC, DDD и некоторыми другоми акронимами.
AVK>Не надо свои проблемы переносить на всех остальных. Что такое IoC мне неоднократно удавалось без каких либо проблем, на пальцах, объяснять людям за 5 минут. Концепция примитивна как 5 пальцев, проще придумать сложно.
И люди сразу же все понимали и начинали применять?

G>> Пока не не увидишь как это делается — сути не поймешь.
AVK>Думаю, это твоя личная особенность.
Ну да, а то чт регулярно темы на форуме возникают, так это люди от нечего делать пишут.

Здравствуйте, gandjustas, Вы писали:

G>Ладно, адекватных примеров не будет, это я понял.

В реальных условиях, подобных тем, что описал AVK, примеры для TDD нужно подбирать очень-очень специально. Проблема в том, что "хороший дизайн" подразумевает подготовку к определённым будущим изменениям в требованиях. Тогда как TDD предполагает дизайн по уже состоявшимся изменениям. Противоречие не устранимое в принципе, как ты ни "понимай TDD". Понимаешь ли, какой момент, для хорошего архитектора (дизайнера) неготовность дизайна к модификациям требований — трагедь (термин шуточный, но на самом деле я не шучу), а для TDD-guy, судя по всему — норма жизни. Всё нормально, но второй подход априори дороже. Больше того, TDD по самой своей сути ведёт к плохому дизайну чаще, чем к хорошему, то есть влечёт удорожание в квадрате. Хотя все при деле, выхлопа очень много, но машина не едет.

AVK>>А архитект, который по предельно формальным требованиям формирует единственно верный дизайн, который потом девелоперы реализуют строго в рамках спецификаций за строго определенное время — такое в основном только в книжках бывает.
G>Да, именно поэтому и придумали TDD.

Ага, только придумали его ещё и предполагая плотное взаимодействие с заказчиком, что вообще невозможно, например, в рамках "коробки". Ну не приведёшь же ты к себе тыщу пользователей, правда? А с другой стороны, эти самые пользователи, встретив неудачную реализацию чего-то даже и не скажут об этом.

AVK>>А в моих проектах TDD сильно увеличил затраты ресурсов и резко снизил скорость эволюции дизайна в процессе разработки. Твой ход.
G>Из этого только вывод что ты не сумел применить TDD.

Из этого только вывод, что ты безуспешно попытался выступить пропонентом технологии ради технологии.

AVK>>Именно. Обычный интернет магазин, с которым заранее почти все ясно. Только не все проекты по уровню R&D интернет магазины.
G>Ну да, ентерпрайз + веб по разным подсчетам занимают от 80% до 95% разработки, а они все не очень далеко ушли от тех же интернет-магазинов.

Ты не прав, нужно написать 99%. Так внушительнее. Сам же знаешь, чем дальше аргумент отстоит от предмета спора, тем внушительнее должна быть формулировка.

G>>>Также стоит посмотреть начало серии mvc storefront http://www.asp.net/learn/mvc-videos/
G>>>А также http://ayende.com/hibernating-rhinos.aspx ролик под номером 1.
AVK>>Я не буду длинные кина смотреть, время жалко. Все это я уже миллион раз видел.
G>Судя по твоим постам — ни разу.

Обоснуй. А то вот я сделал прямо противоположный вывод из высказываний AVK. Ну что, сразимся имхой против имхи?

AVK>>Они имеет значение в этом топике. Потому что обсуждать что то, что ты даже вчерне описать не можешь — глупое и бессмысленное занятие.
G>А ты перечитай топик сначала, я уже десяток раз описывал TDD.

Ты лучше сам скомпилируй краткое определение для TDD (заодно поймешь, может быть, почему даже сам термин сей содержит глубокое внутреннее противоречие). А то, как показывает суровая практика, чем сильнее пропонент отказывается от выдачи определения, тем больше вероятность, что на самом деле он где-то пытается поставить лошадь позади телеги или поделить на нуль. Потому и отказывается от определения — много противоречий всплывёт. Гораздо проще обвинять окружающих в безмозглости.

AVK>>>>Это именно то, что нужно.
G>>>Само определение нафиг никому не нужно.
AVK>>Конечно. Тогда так классно получится спорить. Всегда ведь можно сказать, что собеседник TDD не понимает. Еще бы, ведь что там у тебя в мозгах одному богу известно, а поделиться этим с окружающими ты не в состоянии.
G>См коммент выше.

Не описание, а "определение". Слона можно долго описывать, но где гарантия, что ты описал не один только хвост? Так что, давай по-порядку: сначала определение, потом описание. А не то определениями я займусь... Бу-га-га.

AVK>>Что значит не то что надо? А что надо? И почему не то что надо? Потому что то, что там написано напрямую опровергает твои заявления, но прямо обвинить в том, что там вранье, ты боишься?
G>Да мне читать лениво что там написано, мне достаточно того что я успешно применяю TDD.

Не юли. Ты просто не знаешь толком определения TDD, потому и не можешь сравнить одно с другим.

G>>>На доуге попробуй описать словами процесс завязывания шнурков бантиком. (как вариант — наматывание портянок)
AVK>>А чего пробовать. В инете такого навалом, можешь погуглить.
G>Ну напиши словами, или дай ссылку на википедию где это описано

Не надо подменять предмет обсуждения.

G>>>Аналогичная картина с IoC, DDD и некоторыми другоми акронимами.
AVK>>Не надо свои проблемы переносить на всех остальных. Что такое IoC мне неоднократно удавалось без каких либо проблем, на пальцах, объяснять людям за 5 минут. Концепция примитивна как 5 пальцев, проще придумать сложно.
G>И люди сразу же все понимали и начинали применять?

Это только для икспиистов школы Agile постижение IoC нуждается в глубоком озарении. Я даже знаю почему — из-за того, что он нарушает LSP. Гы-гы.

G>>> Пока не не увидишь как это делается — сути не поймешь.
AVK>>Думаю, это твоя личная особенность.
G>Ну да, а то чт регулярно темы на форуме возникают, так это люди от нечего делать пишут.

А не фиг детям мозги пудрить чепухой. Сначала паттерны, потом TDD, потом Agile, все как одна — потаённые практики, доступные посвящённым. На поверку пшик, но чтобы был "пшик" нужно же воздуха накачать!

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Здравствуйте, gandjustas, Вы писали:

G>>Ладно, адекватных примеров не будет, это я понял.

ГВ>В реальных условиях, подобных тем, что описал AVK, примеры для TDD нужно подбирать очень-очень специально. Проблема в том, что "хороший дизайн" подразумевает подготовку к определённым будущим изменениям в требованиях. Тогда как TDD предполагает дизайн по уже состоявшимся изменениям.
Ну-ну, и как ты подготовишь к будущим именениям? Я знаю только один способ: делать маленькие слабосвязные компоненты и писать меньше кода. TDD обеспечивает и то и другое.
Специально дизайнить с расчетомо на изменения не стоит ибо получится монстр.

ГВ>Противоречие не устранимое в принципе, как ты ни "понимай TDD".
Это ты сам придумал противоречие.


AVK>>>А архитект, который по предельно формальным требованиям формирует единственно верный дизайн, который потом девелоперы реализуют строго в рамках спецификаций за строго определенное время — такое в основном только в книжках бывает.
G>>Да, именно поэтому и придумали TDD.

ГВ>Ага, только придумали его ещё и предполагая плотное взаимодействие с заказчиком, что вообще невозможно, например, в рамках "коробки".
С чего ты взял?

ГВ>Ну не приведёшь же ты к себе тыщу пользователей, правда? А с другой стороны, эти самые пользователи, встретив неудачную реализацию чего-то даже и не скажут об этом.
Еще как скажут. Community своего продукта лучше создавать с первых версий.
Или ты думаешь что в принципе можно придумать программу, сделать её с первого раза удачную, выкатить на рынок и вообще не париться по поводу того что думают пользователи?

AVK>>>А в моих проектах TDD сильно увеличил затраты ресурсов и резко снизил скорость эволюции дизайна в процессе разработки. Твой ход.
G>>Из этого только вывод что ты не сумел применить TDD.
ГВ>Из этого только вывод, что ты безуспешно попытался выступить пропонентом технологии ради технологии.
Логика на гране фантастики.


AVK>>>Они имеет значение в этом топике. Потому что обсуждать что то, что ты даже вчерне описать не можешь — глупое и бессмысленное занятие.
G>>А ты перечитай топик сначала, я уже десяток раз описывал TDD.

ГВ>Ты лучше сам скомпилируй краткое определение для TDD (заодно поймешь, может быть, почему даже сам термин сей содержит глубокое внутреннее противоречие).
А зачем оно надо? Чем какое-то определение поможет?

ГВ>А то, как показывает суровая практика, чем сильнее пропонент отказывается от выдачи определения, тем больше вероятность, что на самом деле он где-то пытается поставить лошадь позади телеги или поделить на нуль. Потому и отказывается от определения — много противоречий всплывёт. Гораздо проще обвинять окружающих в безмозглости.
Еще один умный. Тогда давай напиши определение завязывания шнурков, которое что-либо говорит о самом процессе завязывания.

AVK>>>>>Это именно то, что нужно.
G>>>>Само определение нафиг никому не нужно.
AVK>>>Конечно. Тогда так классно получится спорить. Всегда ведь можно сказать, что собеседник TDD не понимает. Еще бы, ведь что там у тебя в мозгах одному богу известно, а поделиться этим с окружающими ты не в состоянии.
G>>См коммент выше.

ГВ>Не описание, а "определение". Слона можно долго описывать, но где гарантия, что ты описал не один только хвост? Так что, давай по-порядку: сначала определение, потом описание. А не то определениями я займусь... Бу-га-га.
Ты лучше образованием займись.

AVK>>>Что значит не то что надо? А что надо? И почему не то что надо? Потому что то, что там написано напрямую опровергает твои заявления, но прямо обвинить в том, что там вранье, ты боишься?
G>>Да мне читать лениво что там написано, мне достаточно того что я успешно применяю TDD.
ГВ>Не юли. Ты просто не знаешь толком определения TDD, потому и не можешь сравнить одно с другим.
Я тоже самое говорил, я не знаю определение TDD, от которого есть толк.
И выдумывать его абсолютно нет желания.

G>>>>На доуге попробуй описать словами процесс завязывания шнурков бантиком. (как вариант — наматывание портянок)
AVK>>>А чего пробовать. В инете такого навалом, можешь погуглить.
G>>Ну напиши словами, или дай ссылку на википедию где это описано
ГВ>Не надо подменять предмет обсуждения.
Есть вещи которые проще показать, чем описывать. Когда это поймешь не будешь писать тот бред, который написан выше.

G>>>>Аналогичная картина с IoC, DDD и некоторыми другоми акронимами.
AVK>>>Не надо свои проблемы переносить на всех остальных. Что такое IoC мне неоднократно удавалось без каких либо проблем, на пальцах, объяснять людям за 5 минут. Концепция примитивна как 5 пальцев, проще придумать сложно.
G>>И люди сразу же все понимали и начинали применять?
ГВ>Это только для икспиистов школы Agile постижение IoC нуждается в глубоком озарении. Я даже знаю почему — из-за того, что он нарушает LSP. Гы-гы.
И где он нарушает LSP?

Пусть q(x) является свойством верным относительно объектов x некоторого типа T. Тогда q(y) также должно быть верным для объектов y типа S, где S является подтипом типа T.

И по-русски:

Таким образом, идея Лисков о "подтипе" дает определение понятия замещения — если S является подтипом T, тогда объекты типа T в программе могут быть замещены объектами типа S без каких либо изменений желательных свойств этой программы

Что из этого IoC нарушает?