TDD и юниттесты — это
1. способ описать, что конкретно будет делать код. Не в терминах классов, domain models etc, а в совершенно конкретных вещах — берем на входе a,b,c — получаем на выходе d,e,f. Не больше, но и не меньше. Не надо писать "на будущее", надо только то, что надо.
2. юниттесты — это не способ тестить приложение, этим занимаются тестеры. Юниттесты — это снапшот кода, работающего по описанным правилам.
3. Не тесты пишутся под код, а код под тесты. Это заставляет тщательно продумывать, чего, собственно, должен делать код, на совершенно конкретных примерах и ситуациях.

А то в большинстве случаев программирование сводится к

"Высоко-высоко над Небесным Градом, на небольшой площадке, венчающей
собою верхушку Шпиля Высотою в Милю, стоял Владыка Иллюзий, Мара-Сновидец.
Одет он был в плащ всех цветов — и не только радуги. Воздел он над головой
руки, и, сливаясь воедино с собственной силой, хлынула через его тело мощь
всех остальных богов.
В уме его обретала форму греза. И излил он ее наружу, как разливается
по пляжу накатившаяся на берег высокая волна." (c) понятно кто

Изливаем в редактор грезу вместо того, чтобы сделать работу.

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

_>1. способ описать, что конкретно будет делать код. Не в терминах классов, domain models etc, а в совершенно конкретных вещах — берем на входе a,b,c — получаем на выходе d,e,f. Не больше, но и не меньше. Не надо писать "на будущее", надо только то, что надо.
Не знаю как у тебя но у меня практически нет задач для которых можно сказать что точно должно быть на выходе ибо во время решения задачи приходится заниматся кучей исселедований и как следствие постановка порой всесьма сильно корректируется либо выход такого размера что составить его руками просто не реально.
Таким образом максимум что я могу себе позволить это после того как код написан сделать несколько дампов для того чтобы засекать изменения в работе системы.
А бывают случаи когда даже дамп не сделать...

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

WH>Не знаю как у тебя но у меня практически нет задач для которых можно сказать что точно должно быть на выходе ибо во время решения задачи приходится заниматся кучей исселедований и как следствие постановка порой всесьма сильно корректируется либо выход такого размера что составить его руками просто не реально.

Если вы не представляете, что должно быть на выходе конкретного метода при подаче на вход конкретных значений — как вы можете быть уверены, что ваш код делает то, что должен?
Понятно, если есть 1 огромная функция, КОТОРАЯ ДЕЛАЕТ ВСЕ — тут да, тяжеловато.
Но суть-то как раз и в том, чтоб не писать сперва такой код и потом думать, как же его проверить-то
Суть в том, что сперва написать тест для проверки конкретной небольшой части кода, читай — написать правила, по которым должна работать эта конкретная часть кода. Потом — реализовать ее именно в том виде, в каком она придумана для теста. Потом убедиться, что она работает именно так, как придумано. И все.

WH>Таким образом максимум что я могу себе позволить это после того как код написан сделать несколько дампов для того чтобы засекать изменения в работе системы.

Юниттесты — это не способ проверить, как работает система. Для этого есть тестеры
Это способ убедиться, что написанные методы делают именно то, что должны и так, как должны. Автоматически, без отладки. Запустил раннер — все зеленое — ок
Красное — где-то что-то напортачил, чиним не отходя от кассы. Кто-то еще напортачил в методе, изменил логику под свои нужды, а ты и не знаешь об этом — о да, у него все работает, а у тебя нет. Что делать? Запускаем тесты и сразу видим, где жопа. Лучше сразу после изменений, чем тестер откопает это через месяц, или, что хуже, найдет клиент

WH>А бывают случаи когда даже дамп не сделать...

Бывают
Но компиляете-то вы исходники у себя на машине, так ведь?
По сути, тесты — это некая инкарнация компилятора. Компилятор вам говорит, что новонаписанный код нарушает синтаксис, тесты — где нарушена описанная в них логика.

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

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

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

_>Если вы не представляете, что должно быть на выходе конкретного метода при подаче на вход конкретных значений — как вы можете быть уверены, что ваш код делает то, что должен?
Наверное мы работаем на разных уровнях.
Лично мне никто и никогда не ставит задание:
Написать класс байда с методами инь, янь, хрень. Каждый из которых должен делать то-то и то-то.

Мне ставят задачи както так:
Придумать объектную систему в которой объект владелец может добавлять свойства тем объектам которыми он владеет (как придумай сам).
Все это должно описыватчся декларотивно (как придумай сам)
система должна сама сериализовать эту объектную систему (как придумай сам) в формат (придумай сам)
...
И главное все это должно быть расшаряемо.

Ну и к чему тут можно написать тесты? Мне особенно интересно как протестировать расшаряемость.

_>Понятно, если есть 1 огромная функция, КОТОРАЯ ДЕЛАЕТ ВСЕ — тут да, тяжеловато.
Подавляющие большинство моих функций не привышают 10 строк.
_>Но суть-то как раз и в том, чтоб не писать сперва такой код и потом думать, как же его проверить-то
_>Суть в том, что сперва написать тест для проверки конкретной небольшой части кода, читай — написать правила, по которым должна работать эта конкретная часть кода. Потом — реализовать ее именно в том виде, в каком она придумана для теста. Потом убедиться, что она работает именно так, как придумано. И все.
Если тебе ставят задание "написать класс байда..." то так работать можно, а если тебе ставять задание в виде "Придумать объектную систему..." то так работать невозможно ибо до того как работа будет закончена код будет переписан 3 раза. Меньше не получается. И на каждый раз писать тесты это просто пустая трата времени. Болие того непонятно даже что писать ибо я еще не придумал как это должно работать, какие должны быть классы, какие у них должны быть методы и тем болие что они должны делать.

_>Юниттесты — это не способ проверить, как работает система. Для этого есть тестеры
_>Это способ убедиться, что написанные методы делают именно то, что должны и так, как должны. Автоматически, без отладки. Запустил раннер — все зеленое — ок
А если ошабка в тесте?
_>Красное — где-то что-то напортачил, чиним не отходя от кассы. Кто-то еще напортачил в методе, изменил логику под свои нужды, а ты и не знаешь об этом — о да, у него все работает, а у тебя нет. Что делать? Запускаем тесты и сразу видим, где жопа. Лучше сразу после изменений, чем тестер откопает это через месяц, или, что хуже, найдет клиент
Вот для этого я и использую дампы решения. После изменений запусткается код и если дампы отличаются от эталонных то разбираемся что произошло.

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

WH>Лично мне никто и никогда не ставит задание:

Мне тоже не ставят Мечтаю, чтоб ставили! Сиди себе и пиши. Нет, все самому приходится

WH>Мне ставят задачи както так:
WH>...
WH>И главное все это должно быть расшаряемо.

Тебе в любом случае надо иметь спецификацию. Либо ты ее пишешь сам, либо клиент. После того как она утверждена, начинаем рисовать юз кейзы на каждый пункт спецификации, и т.д. Т.д. — это все у Бека описано, копи-пастить сюда — это много

WH>Ну и к чему тут можно написать тесты? Мне особенно интересно как протестировать расшаряемость.

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

WH>Если тебе ставят задание "написать класс байда..." то так работать можно, а если тебе ставять задание в виде "Придумать объектную систему..." то так работать невозможно ибо до того как работа будет закончена код будет переписан 3 раза.

Ты что, сразу код пишешь!?

WH>Меньше не получается. И на каждый раз писать тесты это просто пустая трата времени.

Не надо писать тесты под код
Надо писать код, котрый легко тестить

WH>Болие того непонятно даже что писать ибо я еще не придумал как это должно работать, какие должны быть классы, какие у них должны быть методы и тем болие что они должны делать.

Вот как придумаешь — сразу пиши тесты. Не код, а тесты, а потом — код.

WH>А если ошабка в тесте?

А ты пиши такие тесты(и, соответственно, код), чтобы они были маленькие и однозначные.

WH>Вот для этого я и использую дампы решения. После изменений запусткается код и если дампы отличаются от эталонных то разбираемся что произошло.

Ну так в тестах-то искать быстрее искать

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

_>Не надо писать тесты под код
_>Надо писать код, котрый легко тестить

А мне казалось надо писать код, который работает...

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

_>Мне тоже не ставят Мечтаю, чтоб ставили! Сиди себе и пиши. Нет, все самому приходится
А лично я сразу уволюсь если мне попытаются так задачу поставить.

_>Тебе в любом случае надо иметь спецификацию.
Какую еще спецификацию? "Класс байда с етодами инь, янь, хрень"?
_>Либо ты ее пишешь сам, либо клиент.
Клиент понятие слишком растяжимое.
Если клиент это бугалтерик мегаконторы "Рога и копыта" то нужно писать спецификацию формочек. Если клиент это мега-софтовая контора "Твердософт" то нужно писать спецификацию на публичные классы и методы.
_>После того как она утверждена, начинаем рисовать юз кейзы на каждый пункт спецификации, и т.д. Т.д. — это все у Бека описано, копи-пастить сюда — это много
Рисовать? В сад! Пустая трата времени. Работал я в разных конторах и ни разу от рисовальщиков накакого полезного выхлопа небыло. Те совсем никакого. Лучше бы писателей доков на их место наняли.

_>Я пишу — тесты — это снапшот рабочего кода, гарантия, что код работает так, как ты его описал/задумал, что ты в результате очередной правки ничего не поломал.
1)Снапшот кода это вобще не понятно что такое.
2)Если всетки имеется в виду снапшот результата работы то зачем его писать руками?
Лично я сначало пишу рабочий код. Потом пишу текстувую дампилку результатов (в языках с рефлекшеном это можно сильно автоматизировать).
После чего запускаю код с несколькими наборами аргументов на которых он может свалится и формирую дамп. Далие я этот дамп смотрю е если там все как задумано объявляю его эталонным.
Теперь если кто-то что-то поменял и у меня что-то поломалось то дампы изменятся и это очень легко отследить.
Выглядит это примерно так:


_>Ты что, сразу код пишешь!?
Да. Если ты можешь с чистого листа без единого прототипа нарисовать подсистему на 150К кода учтя все требования не забыв про то что это все нужно интегрировать в систему в которой уже болие 10 метров кода также нужно помнить про главное не функциональное требование расширяемость (оно даже главнее производительности при условии что она не фатально низкая). И при всем этом по твоим рисункам можно будет точно воссоздать систему не внеся в рисунки ни единого изменения и не делая отходов от рисунков в коде то ты мега гений и не понятно что делаешь среди нас простых смертных.

Лично я ничинаю с прототипа который непрерывно рефакторю.
После массы совещаний, продумываний, натыканий на грабли окружения... этот прототип постепенно превращается в законченую систему.

_>Надо писать код, котрый легко тестить
Надо писать код результат которого можно сдампить в текстовый файл, а это справедливо почти для любого кода. Это позволяет засечь непредвиденное изменение поведения. Больше ничего не нужно. Болие того в нормальном дампе все прекрасно видно.

_>Ну так в тестах-то искать быстрее искать
Уверен?

Немного от темы , я очень много раз слышал про код , который пишется один раз , до которого были написаны юнит тесты , который так хорош и просто , что его можно

1. Обдумать
2. Написать тесты
3. написать сам код.

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

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

M>Немного от темы , я очень много раз слышал про код , который пишется один раз , до которого были написаны юнит тесты , который так хорош и просто , что его можно

M>1. Обдумать
M>2. Написать тесты
M>3. написать сам код.

M>Все про него говорят , но только я ни разу не встречал . кошмар короче , вероятно этот код по жизни бегает от меня и прячется ...

открой любую книжку по программированию..
какое нибудь жёлтобелое дерево..
да просто бинарный поиск..
их проще всего на тестах отлаживать..

_>>Ты что, сразу код пишешь!?
WH>Да. [skip] то ты мега гений и не понятно что делаешь среди нас простых смертных.

ХитрО. Ты сам утверждаешь что пишешь код сразу, а затем записываешь таких как ты в гении. Мания величия?

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

M>Немного от темы , я очень много раз слышал про код , который пишется один раз , до которого были написаны юнит тесты , который так хорош и просто , что его можно

M>1. Обдумать
M>2. Написать тесты
M>3. написать сам код.

M>Все про него говорят , но только я ни разу не встречал . кошмар короче , вероятно этот код по жизни бегает от меня и прячется ...

Ты хочешь, чтобы он тебя преследовал?
А вообще никакая методология не применяется в чистом виде.
Всегда есть различные отклонения от "генеральной линии".
Если это принять, то многие проблемы чудным образом исчезают.
У нас в конторе довольно много юнит тестов.
Каждую ночь уходит около 4-х часов на прогон всех тестов.
Когда получается, то пишем их именно в последовательности "обдумать, написать тест, написать код".
Если не получается — это не трагедия. Значит напишем чуть позже по уже написанному коду.
Но я себя чувствую комфортнее, если написанный кусочек кода могу сразу же потестировать.

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

_>TDD и юниттесты — это

Я что-то не понял?
Это ответ или упрек? А кому и на что?

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

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

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

_>>Ты что, сразу код пишешь!?
WH>Да. [skip] то ты мега гений и не понятно что делаешь среди нас простых смертных.

MP>ХитрО. Ты сам утверждаешь что пишешь код сразу, а затем записываешь таких как ты в гении. Мания величия?

Есть разница между писать сразу код и писать сразу код
WolfHound вроде четко сказал, что пишет сперва прототип, потом его многократно изменяет и обрабатывает, пока не получится уже окончательная структура, после чего она доделывается уже окончательно. Очень разумный и эффективный подход.

И это немножно не то, что сесть и сразу написать (или там — нарисовать так, что по ней без изменений можно написать) готовую рабочую систему, не находишь?

З.Ы.
Комбинация хитрого скипа в цитировании и собственной фразы, из-за которой изменился смысл высказывания, не остался незамеченным . Повторяем для хитрых — WH утверждал, что нереально сразу придумать правильную, эффективную и удобную структуру программы, ни разу ее не попробовав в прототипах. Бумага все стерпит — там легко нарисовать все классно и красиво, но при попыках отобразить эти рисунки на код обычно получаются проблемы, которые ведут либо к окольным путям в коде, либо к перерисовыванию рисунков и пререписванию кода наново. Т.е. те же самые прототипы, которые он и предлагает сразу делать.
Только и всего. Ты же сумел представить его слова совершенно иначе. Ай-яй-яй!

_>>>Ты что, сразу код пишешь!?
WH>>Да. [skip] то ты мега гений и не понятно что делаешь среди нас простых смертных.

MP>>ХитрО. Ты сам утверждаешь что пишешь код сразу, а затем записываешь таких как ты в гении. Мания величия?

F>Есть разница между писать сразу код и писать сразу код
F>WolfHound вроде четко сказал, что пишет сперва прототип, потом его многократно изменяет и обрабатывает, пока не получится уже окончательная структура, после чего она доделывается уже окончательно. Очень разумный и эффективный подход.

F>И это немножно не то, что сесть и сразу написать (или там — нарисовать так, что по ней без изменений можно написать) готовую рабочую систему, не находишь?

Здесь две части — проектирование и программирование. Мне кажется, что мы ломимся в открытую дверь, споря друг с другом. Я согласен, что сразу готовую программу написать сложно, как говорил Брукс "первую версию придется выкинуть". Но при этом мне показалось, что вы с WH отрицаете стадию проектирования, переходя сразу к написанию кода. И вот с этим я согласиться не смог Если я вас неправильно понял — извините.


F>Комбинация хитрого скипа в цитировании и собственной фразы, из-за которой изменился смысл высказывания, не остался незамеченным
Да? Я просто попытался выделить главное, обо что споткнулся. Приношу свои извинения, если извратил смысл исходного поста.

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

MP>Здесь две части — проектирование и программирование. Мне кажется, что мы ломимся в открытую дверь, споря друг с другом. Я согласен, что сразу готовую программу написать сложно, как говорил Брукс "первую версию придется выкинуть". Но при этом мне показалось, что вы с WH отрицаете стадию проектирования, переходя сразу к написанию кода. И вот с этим я согласиться не смог Если я вас неправильно понял — извините.
Никто не отрицает проектирование. Просто выделеная стадия проектирование совершенно бессмысленна. Ни на бумаге ни в розе нельзя учесть даже все грабли о которых знаешь. О тех что не знаешь я вобще молчу. А когда начинаешь писать код то видно все и сразу. И при первых признаках проблемы можно изменить дизайн так чтобы этой проблемы больше небыло.
При таком подходе результат получается гораздо быстрее и гораздо качественнее. Также совершенно ясно что такой подход совершенно не совместим с юнит тестами ибо классы и методы постоянно появляются, исчезают, расщепляются и сливаются. Поддерживать актуальность тестов при таком подходе просто не возможно.

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

WH>Здравствуйте, Mikhail Polykovsky, Вы писали:

MP>>Здесь две части — проектирование и программирование. Мне кажется, что мы ломимся в открытую дверь, споря друг с другом. Я согласен, что сразу готовую программу написать сложно, как говорил Брукс "первую версию придется выкинуть". Но при этом мне показалось, что вы с WH отрицаете стадию проектирования, переходя сразу к написанию кода. И вот с этим я согласиться не смог Если я вас неправильно понял — извините.
WH>Никто не отрицает проектирование. Просто выделеная стадия проектирование совершенно бессмысленна. Ни на бумаге ни в розе нельзя учесть даже все грабли о которых знаешь. О тех что не знаешь я вобще молчу. А когда начинаешь писать код то видно все и сразу. И при первых признаках проблемы можно изменить дизайн так чтобы этой проблемы больше небыло.

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

WH>При таком подходе результат получается гораздо быстрее и гораздо качественнее. Также совершенно ясно что такой подход совершенно не совместим с юнит тестами ибо классы и методы постоянно появляются, исчезают, расщепляются и сливаются. Поддерживать актуальность тестов при таком подходе просто не возможно.

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

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

MP>Ага. Теперь мне ясна ваша позиция, хотя я придерживаюсь противоположног подхода и считаю выделенную стадию проектирвоания очень важной. Что ж, каждый создает программу так, как ему удобнее

Соглашусь с этим.
Каждый раз, когда мы на проекте выделяли специально время "на подумать"
и порисовать в MagicDraw, результат был всегда лучше, чем при спонтанном проектировании.
Проблемы открывались раньше и переделовать приходилось меньше.

Но опыт и в самом деле у всех разный...

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

WH>Здравствуйте, Mikhail Polykovsky, Вы писали:

MP>>Здесь две части — проектирование и программирование. Мне кажется, что мы ломимся в открытую дверь, споря друг с другом. Я согласен, что сразу готовую программу написать сложно, как говорил Брукс "первую версию придется выкинуть". Но при этом мне показалось, что вы с WH отрицаете стадию проектирования, переходя сразу к написанию кода. И вот с этим я согласиться не смог Если я вас неправильно понял — извините.
WH>Никто не отрицает проектирование. Просто выделеная стадия проектирование совершенно бессмысленна. Ни на бумаге ни в розе нельзя учесть даже все грабли о которых знаешь. О тех что не знаешь я вобще молчу. А когда начинаешь писать код то видно все и сразу. И при первых признаках проблемы можно изменить дизайн так чтобы этой проблемы больше небыло.
WH>При таком подходе результат получается гораздо быстрее и гораздо качественнее. Также совершенно ясно что такой подход совершенно не совместим с юнит тестами ибо классы и методы постоянно появляются, исчезают, расщепляются и сливаются. Поддерживать актуальность тестов при таком подходе просто не возможно.

Абсолютно согласен с тем, что прототипирование важно и что практически нереально взять сесть и все заранее продумать. Но полагаю, что это никак не противоречит юнит тестам. Во-первых, эволюция кода совсем не означает, что код меняется по всему приложению/системе. Скорее всего он изменяется в некой локальной части и не аффектит все остальное (если это не так, то, скорее всего, надо что-то передизайнивать). Поэтому при изменении кода имеет смысл не все юнит тесты переписывать, а только те, которые относятся к той части кода, которая меняется. Юнит тесты вообще не надо переписывать, если меняется только внутреннее устройство тестируемого юнита и не меняется его интерфейс (что в общем-то бывает нередко).
Во-вторых, подход с текстовой дампилкой будет также неудовлетворительно себя вести при тотальном изменении кода, как и юнит тесты; поскольку эталонные дампы результатов станут неактуальны.

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

B>Соглашусь с этим.
B>Каждый раз, когда мы на проекте выделяли специально время "на подумать" и порисовать в MagicDraw, результат был всегда лучше, чем при спонтанном проектировании.
Ты все не так понял. Нет никакого спонтанного проектирования.
Просто проектирование идет прямо в коде. Это не отменяет совещаний и обсуждений того куда все катится. Болие того иногда даже на доске цеветными фломастерами рисуют схемы но эти схемы находятся на гораздо болие высоком уровне чем классы и тем болие методы и служат они исключительно для того чтобы было проще объяснить другим как в принципе работает система.
Но никто и никогда не рисует классы и тем болие методы ибо это совершенно пустая трата времени.

B>Проблемы открывались раньше и переделовать приходилось меньше.
Извини не поверю. Разрисовать систему можно только на очень высоком уровне где каждый кружочек раскрывается в десятки и сотни килобайт кода.
Все попытки спустится ниже утыкаются в детали работы с окружением и ничего с этим не поделать.
Болие того на большинство вопросов без написания прототипа ответить невозможно. Хуже того некоторые вопросы и не возникают до того как будет написан хотябы один прототип.

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

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

M>>Немного от темы , я очень много раз слышал про код , который пишется один раз , до которого были написаны юнит тесты , который так хорош и просто , что его можно

M>>1. Обдумать
M>>2. Написать тесты
M>>3. написать сам код.

M>>Все про него говорят , но только я ни разу не встречал . кошмар короче , вероятно этот код по жизни бегает от меня и прячется ...

B>Ты хочешь, чтобы он тебя преследовал?
B>А вообще никакая методология не применяется в чистом виде.
B>Всегда есть различные отклонения от "генеральной линии".
B>Если это принять, то многие проблемы чудным образом исчезают.
B>У нас в конторе довольно много юнит тестов.
B>Каждую ночь уходит около 4-х часов на прогон всех тестов.
B>Когда получается, то пишем их именно в последовательности "обдумать, написать тест, написать код".
B>Если не получается — это не трагедия. Значит напишем чуть позже по уже написанному коду.
B>Но я себя чувствую комфортнее, если написанный кусочек кода могу сразу же потестировать.

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

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

B>>Проблемы открывались раньше и переделовать приходилось меньше.
WH>Извини не поверю. Разрисовать систему можно только на очень высоком уровне где каждый кружочек раскрывается в десятки и сотни килобайт кода.
WH>Все попытки спустится ниже утыкаются в детали работы с окружением и ничего с этим не поделать.
WH>Болие того на большинство вопросов без написания прототипа ответить невозможно. Хуже того некоторые вопросы и не возникают до того как будет написан хотябы один прототип.

Ну верить или не верить — это вообще не вопрос
Естественно мы не рисуем до самых низов. Это и в самом деле не нужно.
Прототипирование не исключает рисование, как и рисование — прототипирование.
Мы и рисуем и прототипы создаем. У нас, думаю, разумный компромисс,
когда выделяется время именно "на подумать и порисовать", которое выливается в прототипирование.
Повторюсь, но результат получается лучше, чем спонтанное рисование во-время обсуждения.

Я вот тебе тоже не поверю, что с куском кода ты всегда сможешь
лучше объяснить идею, чем с хорошей диаграммой.
Причина — слишком много ненужных деталей.

Можно еще пообсуждать, что есть смысл рисовать, а что нет.
Например, class diagram и instance diagram очень полезны и куда нагляднее кода.
Диаграммы состояний тоже гораздо нагляднее кода.
Sequence diagram опять же очень удобны.
Демонстрировать параллелизм с помощью кода — это вообще издевательство.
Картинки гораздо нагляднее показывают, к примеру, точки синхронизации.
Ну и так далее...

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

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

D>Абсолютно согласен с тем, что прототипирование важно и что практически нереально взять сесть и все заранее продумать.
D>Но полагаю, что это никак не противоречит юнит тестам.
Это противоречит идее написания тестов до кода. Ибо то как будет выглядить код еще не известно.
D>Во-первых, эволюция кода совсем не означает, что код меняется по всему приложению/системе. Скорее всего он изменяется в некой локальной части и не аффектит все остальное (если это не так, то, скорее всего, надо что-то передизайнивать).
Угу... в локалльной части килов на 100-150 из 10 метров всей системы...
А классические юнит тесты для 100К кода ото само по себе огромное колличество кода.
D>Поэтому при изменении кода имеет смысл не все юнит тесты переписывать, а только те, которые относятся к той части кода, которая меняется.
Либо не переписывать если их нет...
D>Юнит тесты вообще не надо переписывать, если меняется только внутреннее устройство тестируемого юнита и не меняется его интерфейс (что в общем-то бывает нередко).
Зато часто бывают задачи где через интерфейс проходит тонна данных и загнать их в юнит тест дело весьма проблематичное.
За то дамп работает прекрасно.
D>Во-вторых, подход с текстовой дампилкой будет также неудовлетворительно себя вести при тотальном изменении кода, как и юнит тесты; поскольку эталонные дампы результатов станут неактуальны.
Тут нужно учитывать что сама по себе дампилка это как правило несколько строк кода и десятки килобайт дампов, а юнит тесты это десятки килобайт кода.
Так вот на переписывания десятка строк дампилки и на анализ десятка килобайт хорошо отформатированного дампа уйдет гораздо меньше времени и сил чем на переписывание десятков килобайт кода юнит тестов.

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

B>Я вот тебе тоже не поверю, что с куском кода ты всегда сможешь
B>лучше объяснить идею, чем с хорошей диаграммой.
B>Причина — слишком много ненужных деталей.

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


B>Можно еще пообсуждать, что есть смысл рисовать, а что нет.
B>Например, class diagram и instance diagram очень полезны и куда нагляднее кода.
B>Диаграммы состояний тоже гораздо нагляднее кода.
B>Sequence diagram опять же очень удобны.
B>Демонстрировать параллелизм с помощью кода — это вообще издевательство.
B>Картинки гораздо нагляднее показывают, к примеру, точки синхронизации.
B>Ну и так далее...

Гораздо нагляднее описать это на русском языке.

B>В общем есть довольно много разных типов картинок, которые очень полезно
B>рисовать до того, как дело дойдет то прототипов.
B>Единственный вред от картинок — это когда не отражают то, что есть на самом деле.

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

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

FDS>В коде никогда не бывает слишком много деталей: всегда можно взять тот уровень кода, который содержит нужное количество деталей, исключая некоторые очень сложные моменты и просто плохой код.

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

//MyCoolBaseClass.h
class MyCoolBaseClass
{
};

//MyCoolDerivedClass1.h
class MyCoolBaseClass1: public MyCoolBaseClass
{
};

//MyCoolDerivedClass2.h
class MyCoolBaseClass2: public MyCoolBaseClass
{
};

будет нагляднее, компактнее и обозримее одной картинки?
Не верю...

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

Параллелизм описывать текстами на русском(английском) языке?
Хотел бы я посмотреть на такое описание

Хотя кое-где будет достачно и кода.
Например если надо показать интерфейс какого-то конкретного класса.
Тогда действительно, можно вывалить .h файл и если там есть комментарии и удачно подобранны имена,
то этого будет достаточно...

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

FDS>Я то же чувствую себя комфортнее, когда кусочек кода можно сразу протестировать. Поэтому я н и к о г д а не пишу тесты заранее — ведь я их не могу протестировать .

давайте определимся с терминами..
тело самого теста в принципе написать можно..
вот прописывать сразу результат нереально..

т.е. изначально стоит описать "пустой интерфейс"
некую тестовую накрутку вокруг него
а потом смотреть чего он на выход выдаёт и смотреть эти данные..

конечно в традиционной идеологии NUnit/JUnit это не реально, так как правую часть Assert.AreEqual(,)
прописывать придётся..

но если писать тесты как описано у WolfHound
или у меня тут http://izh-test.sourceforge.net/russian/what_is_it_for.html

то "тест" вполне можно писать до самой программы

конечно при этом тестируется не конечная программа а то чего удалось достичь на данном этапе
а при каждом изменении легко можно видеть что изменилось в тестовом поведении программы

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

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

FDS>>В коде никогда не бывает слишком много деталей: всегда можно взять тот уровень кода, который содержит нужное количество деталей, исключая некоторые очень сложные моменты и просто плохой код.

B>Ну ну...
B>Обычно гораздо проще нарисовать одну картинку,
B>которая показывает нужный аспект, чем выдирать из кода нужные куски.
B>Возми к примеру диаграмму классов.
B>Неужели куча файлов с объявлениями типа
B>

B>//MyCoolBaseClass.h
B>class MyCoolBaseClass
B>{
B>};

B>//MyCoolDerivedClass1.h
B>class MyCoolBaseClass1: public MyCoolBaseClass
B>{
B>};

B>//MyCoolDerivedClass2.h
B>class MyCoolBaseClass2: public MyCoolBaseClass
B>{
B>};
B>

B>будет нагляднее, компактнее и обозримее одной картинки?
B>Не верю...

Это всё описывается словами: группа классов, реализующих крутую функциональность, наследуется от класса, реализующего базовую функциональность, заключающуюся в ....
И не надо никаких картинок.
На этой картинке, кстати, мало что будет показано. Зачастую она и не нужна, вместо неё просто список наследников базового класса гораздо компактнее и информативнее.

B>А диаграмму состояний с переходами как ты будешь наглядно кодом демонстрировать?
B>Да и зачем мне вообще твой код, реализующий эту машину состояний,
B>если я просто хочу понять какие состояния доступны и по каким условиям осуществляются переходы?

Веский аргумент, но попытаюсь ответить.
Здесь совсем другое — тебе нужна документация по состояниям. Ты же в код сам конечный автомат не запихиваешь? У тебя есть таблица (у меня в бакалаврской граф именно таблицей задавался), значит есть интерфейс её задания — там и смотри какая она. Естественно, что графическая схема тут лучше, но она не показывает тебе никаких взаимодействий классов и методов, поэтому не идёт в сравнение с диаграммами о которых мы говорим — диаграммах, фактически дублирующих код.

B>Параллелизм описывать текстами на русском(английском) языке?
B>Хотел бы я посмотреть на такое описание

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

А чем вас просмотр кода не устраивает, не так уж, обычно, там и сложно?

B>Хотя кое-где будет достачно и кода.
B>Например если надо показать интерфейс какого-то конкретного класса.
B>Тогда действительно, можно вывалить .h файл и если там есть комментарии и удачно подобранны имена,
B>то этого будет достаточно...

Кода очень часто достаточно, если требуется показать конкретный алгоритм функционирования части системы: лучше кода тут только русский язык. Взять даже конечный автомат, забитый прямо в код: вы можете найти переключатель, соответствующий конкретному состоянию и увидеть всё что надо, весь алгоритм переключения на высоком уровне, а на диаграмме вы сам алгоритм никогда не отобразите.

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

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

FDS>>Я то же чувствую себя комфортнее, когда кусочек кода можно сразу протестировать. Поэтому я н и к о г д а не пишу тесты заранее — ведь я их не могу протестировать .

V>давайте определимся с терминами..
V>тело самого теста в принципе написать можно..
V>вот прописывать сразу результат нереально..

V>т.е. изначально стоит описать "пустой интерфейс"
V>некую тестовую накрутку вокруг него
V>а потом смотреть чего он на выход выдаёт и смотреть эти данные..

V>конечно в традиционной идеологии NUnit/JUnit это не реально, так как правую часть Assert.AreEqual(,)
V>прописывать придётся..

V>но если писать тесты как описано у WolfHound
V>или у меня тут http://izh-test.sourceforge.net/russian/what_is_it_for.html

V>то "тест" вполне можно писать до самой программы

V>конечно при этом тестируется не конечная программа а то чего удалось достичь на данном этапе
V>а при каждом изменении легко можно видеть что изменилось в тестовом поведении программы

Да, предложенная методика хороша, я сам её иногда использую. НО! Я не могу заранее определить интерфейс некоторого модуля. При кодировании у меня интерфейсы меняются до неузнаваемости. Может это как-то неправильно, но у меня код часто сохраняется, а вот интерфейс меняется. Причём именно интерфейс, который обеспечивает главную функциональность приложения. У меня уже были завалы, когда я пытался этот интерфейс определить сначала и ничего хорошего не получалось: я его мог определить только на уровне человеческого языка: что там хранится и вызывается, но не более того: никаких имён и параметров.

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


FDS>Это всё описывается словами: группа классов, реализующих крутую функциональность, наследуется от класса, реализующего базовую функциональность, заключающуюся в ....
FDS>И не надо никаких картинок.

Лучше один раз увидеть чем сто раз услышать.

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

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


FDS>>Это всё описывается словами: группа классов, реализующих крутую функциональность, наследуется от класса, реализующего базовую функциональность, заключающуюся в ....
FDS>>И не надо никаких картинок.

FR>Лучше один раз увидеть чем сто раз услышать.

Значит у нас разные главные каналы восприятия информации: меня диаграммы классов просто бесят

Ну вобщем нету одного "самого верного" способа озвучить свои мысли и поделиться идеями.
На практике есть смысл пользоваться и картинками,
и словесными описаниями, и кусками кода, которые что-то демонстрируют.
Ну а если надо править баг, то естественно, что никакие картинки не заменят кода.
Баг же не в картинках, а коде

Далеко не всегда просто найти форму, которая наглядно описывает некий аспект системы.
Такие вот дела...

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

FDS>Значит у нас разные главные каналы восприятия информации: меня диаграммы классов просто бесят

Рискну предположить, что ты исключение.
Диаграммы классов — это как раз то, что порой применяют даже ярые противники UML
Они очень наглядны и легки для понимания.

FDS>>Значит у нас разные главные каналы восприятия информации: меня диаграммы классов просто бесят

B>Рискну предположить, что ты исключение.
B>Диаграммы классов — это как раз то, что порой применяют даже ярые противники UML
B>Они очень наглядны и легки для понимания.

И действительно, что может быть проще?

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

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

FDS>>Значит у нас разные главные каналы восприятия информации: меня диаграммы классов просто бесят

B>Рискну предположить, что ты исключение.
B>Диаграммы классов — это как раз то, что порой применяют даже ярые противники UML
B>Они очень наглядны и легки для понимания.

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

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

B>Ну вобщем нету одного "самого верного" способа озвучить свои мысли и поделиться идеями.
B>На практике есть смысл пользоваться и картинками,
B>и словесными описаниями, и кусками кода, которые что-то демонстрируют.
B>Ну а если надо править баг, то естественно, что никакие картинки не заменят кода.
B>Баг же не в картинках, а коде

B>Далеко не всегда просто найти форму, которая наглядно описывает некий аспект системы.
B>Такие вот дела...

Ну, в общем-то да, но для меня обычно код и текстовое описание системы достаточны и полны. Фактически, зависит от опыта.

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

FDS>>>Значит у нас разные главные каналы восприятия информации: меня диаграммы классов просто бесят

B>>Рискну предположить, что ты исключение.
B>>Диаграммы классов — это как раз то, что порой применяют даже ярые противники UML
B>>Они очень наглядны и легки для понимания.

M>И действительно, что может быть проще?

Не понимаю твоего ехидства.
Тут проблема в том что пытаются слишком много запихнуть на одну картинку.
Ну либо сделали сложно то, что можно было сделать проще.
Такую кашу, что на картинке, любым способом будет сложно описать.
Хоть текстом на русском, хоть кодом на С++, хоть украинским гопаком...

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

FDS>Ну, в общем-то да, но для меня обычно код и текстовое описание системы достаточны и полны. Фактически, зависит от опыта.

Ну у меня его (опыта) видимо пока еще не достаточно

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

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

FDS>>>>Значит у нас разные главные каналы восприятия информации: меня диаграммы классов просто бесят

B>>>Рискну предположить, что ты исключение.
B>>>Диаграммы классов — это как раз то, что порой применяют даже ярые противники UML
B>>>Они очень наглядны и легки для понимания.

M>>И действительно, что может быть проще?

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

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

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

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

FDS>>Ну, в общем-то да, но для меня обычно код и текстовое описание системы достаточны и полны. Фактически, зависит от опыта.

B>Ну у меня его (опыта) видимо пока еще не достаточно

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

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

M>И действительно, что может быть проще?

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

Так что ужасные картинки просто показывают ужасные проектные решения
и на картинках они заметнее.

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

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

M>>И действительно, что может быть проще?

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

B>Так что ужасные картинки просто показывают ужасные проектные решения
B>и на картинках они заметнее.

Кстати, не обязательно, что эта каша так уж неудачна. Я видел удачные решения, которые для меня — полная каша, просто потому что UML на диаграмме даёт совершенно не те данные и связи, которые нужны (точнее, кучу лишних взаимодействий). Хотя принципиально тут вы правы — каши быть не должно. Вопрос только в том, что из хорошей UML диаграммы может получиться каша на C++, а из плохой UML-диаграммы можно сделать, скорее всего, что-то приличное: просто потому что языки сильно различаются и выделяют разные аспекты функционирования.

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

FDS>Кстати, не обязательно, что эта каша так уж неудачна. Я видел удачные решения, которые для меня — полная каша, просто потому что UML на диаграмме даёт совершенно не те данные и связи, которые нужны (точнее, кучу лишних взаимодействий).

Если на диаграмме есть связи, которые мешают понимаю, то их надо скрывать.
Самые неудачные и бесполезные диаграммы — это те, которые получаются
автоматически в результате reverse engineering (импорт кучи кода).
На таких диаграммах видно "все", а "все" никогда не нужно.

Самые удачные диаграммы — это те, которые рисуют люди
для других людей и тратят время "на подумать".

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

B>Если на диаграмме есть связи, которые мешают понимаю, то их надо скрывать.
B>Самые неудачные и бесполезные диаграммы — это те, которые получаются
B>автоматически в результате reverse engineering (импорт кучи кода).
B>На таких диаграммах видно "все", а "все" никогда не нужно.

B>Самые удачные диаграммы — это те, которые рисуют люди
B>для других людей и тратят время "на подумать".

Вот с этим согласен. А ещё лучше, если диаграммы не стандартизованы...

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

B>Ты хочешь, чтобы он тебя преследовал?
B>А вообще никакая методология не применяется в чистом виде.
B>Всегда есть различные отклонения от "генеральной линии".
B>Если это принять, то многие проблемы чудным образом исчезают.
B>У нас в конторе довольно много юнит тестов.
B>Каждую ночь уходит около 4-х часов на прогон всех тестов.
B>Когда получается, то пишем их именно в последовательности "обдумать, написать тест, написать код".
B>Если не получается — это не трагедия. Значит напишем чуть позже по уже написанному коду.
B>Но я себя чувствую комфортнее, если написанный кусочек кода могу сразу же потестировать.

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

Здравствуйте, bkat, Вы писали:
[...]
B>Ну верить или не верить — это вообще не вопрос
B>Естественно мы не рисуем до самых низов. Это и в самом деле не нужно.
B>Прототипирование не исключает рисование, как и рисование — прототипирование.
B>Мы и рисуем и прототипы создаем. У нас, думаю, разумный компромисс,
B>когда выделяется время именно "на подумать и порисовать", которое выливается в прототипирование.
B>Повторюсь, но результат получается лучше, чем спонтанное рисование во-время обсуждения.

Мягко говоря не согласен категорически. Множество раз наблюдал как работает методика WH но НИ РАЗУ за 10 лет не видел как работает излагаемая вами метода.

Т.е. я много раз видел как от большого ума создавалась "архитектура" и отдавалась на реализацию группе. Смотреть на это без слез нельзя было.

И я бы согласился что это работает если бы у меня были положительные примеры , но увы...


[...]

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

M>И я бы согласился что это работает если бы у меня были положительные примеры , но увы...

Ну что я могу сказать? У нас явно разный опыт.
Или просто одинаковые вещи оцениваем по-разному.
У меня есть положительный опыт, когда время, выделенное на проектирование,
было потрачено с толком, причем результат был положителен.
Всегда требовались несколько итераций, но это вполне нормально.

Может ты еще и необходимость специфицирования системы тоже будешь отрицать?
Тоже ведь надо сначала подумать, что что собственно должна делать система.
А нафига это делать, если решение уже перед глазами (шутка...)

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

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

B>>Ты хочешь, чтобы он тебя преследовал?
B>>А вообще никакая методология не применяется в чистом виде.
B>>Всегда есть различные отклонения от "генеральной линии".
B>>Если это принять, то многие проблемы чудным образом исчезают.
B>>У нас в конторе довольно много юнит тестов.
B>>Каждую ночь уходит около 4-х часов на прогон всех тестов.
B>>Когда получается, то пишем их именно в последовательности "обдумать, написать тест, написать код".
B>>Если не получается — это не трагедия. Значит напишем чуть позже по уже написанному коду.
B>>Но я себя чувствую комфортнее, если написанный кусочек кода могу сразу же потестировать.

M>Наблюдаю противоречие, если код можно написать таким способом то вероятно это должен быть довольно очевидный код. Но если это код очевидный он должен был быть написан уже давно.

Каким способом? Сначала тесты, а потом код?
Не вижу противоречия.
Цель такой последовательности "тест-код" — это подумать над тем,
что ты собственно хочешь сделать.
Ну если ты сначала кодишь, а потом смотришь а куда это можно впихнуть,
то конечно будут проблемы.
На самом деле думаю почти все сначала все же задумаваются над
тем, а что собственно нужно.
Спор только о том, а нужно ли этот этап делать явным.
На мой взляд да, нужно.

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

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

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

M>>И я бы согласился что это работает если бы у меня были положительные примеры , но увы...

B>Ну что я могу сказать? У нас явно разный опыт.
B>Или просто одинаковые вещи оцениваем по-разному.
B>У меня есть положительный опыт, когда время, выделенное на проектирование,
B>было потрачено с толком, причем результат был положителен.
B>Всегда требовались несколько итераций, но это вполне нормально.

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

B>Может ты еще и необходимость специфицирования системы тоже будешь отрицать?
B>Тоже ведь надо сначала подумать, что что собственно должна делать система.
B>А нафига это делать, если решение уже перед глазами (шутка...)

Про это я ничего не говорил.

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

B>Каким способом? Сначала тесты, а потом код?
B>Не вижу противоречия.
B>Цель такой последовательности "тест-код" — это подумать над тем,
B>что ты собственно хочешь сделать.

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


B>Ну если ты сначала кодишь, а потом смотришь а куда это можно впихнуть,
B>то конечно будут проблемы.

К тому же психиатру.

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

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


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

А это СОВЕРШЕННО к разговору о написании тестов перед функционалом не относится и не пересекается.

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

[skiped]

MP>Здесь две части — проектирование и программирование. Мне кажется, что мы ломимся в открытую дверь, споря друг с другом. Я согласен, что сразу готовую программу написать сложно, как говорил Брукс "первую версию придется выкинуть".

Весьма спорное утверждение. Если вы собираетесь выкинуть первую версию, скорее всего вам придется выкинуть и вторую

MP>>ЗЯ согласен, что сразу готовую программу написать сложно, как говорил Брукс "первую версию придется выкинуть".

DG>Весьма спорное утверждение. Если вы собираетесь выкинуть первую версию, скорее всего вам придется выкинуть и вторую

Почему?

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

_>TDD и юниттесты — это
_>1. способ описать, что конкретно будет делать код. Не в терминах классов, domain models etc, а в совершенно конкретных вещах — берем на входе a,b,c — получаем на выходе d,e,f. Не больше, но и не меньше. Не надо писать "на будущее", надо только то, что надо.

Т.е. постановщик задачи не в состоянии внятно изложить суть задачи ? Или исполнители не в состоянии понять что от них хотят пока не ткнуть им "скока весить в граммах" ?

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

_>2. юниттесты — это не способ тестить приложение, этим занимаются тестеры. Юниттесты — это снапшот кода, работающего по описанным правилам.

Т.е. сам код настолько не очевиден , что проще смотреть в юнит тесты чтобы понять что делает код . Ну если сначала писать тесты а потом код ... все может быть.

_>3. Не тесты пишутся под код, а код под тесты. Это заставляет тщательно продумывать, чего, собственно, должен делать код, на совершенно конкретных примерах и ситуациях.

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

_>А то в большинстве случаев программирование сводится к

_>"Высоко-высоко над Небесным Градом, на небольшой площадке, венчающей
_>собою верхушку Шпиля Высотою в Милю, стоял Владыка Иллюзий, Мара-Сновидец.
_>Одет он был в плащ всех цветов — и не только радуги. Воздел он над головой
_>руки, и, сливаясь воедино с собственной силой, хлынула через его тело мощь
_>всех остальных богов.
_>В уме его обретала форму греза. И излил он ее наружу, как разливается
_>по пляжу накатившаяся на берег высокая волна." (c) понятно кто

_>Изливаем в редактор грезу вместо того, чтобы сделать работу.

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

P.S.

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

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

MP>>>ЗЯ согласен, что сразу готовую программу написать сложно, как говорил Брукс "первую версию придется выкинуть".

DG>>Весьма спорное утверждение. Если вы собираетесь выкинуть первую версию, скорее всего вам придется выкинуть и вторую

MP>Почему?

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

Полную версию объяснения читайте в книге С.Макконела "Совершенный код" (Code complete)

MP>>>>ЗЯ согласен, что сразу готовую программу написать сложно, как говорил Брукс "первую версию придется выкинуть".

DG>>>Весьма спорное утверждение. Если вы собираетесь выкинуть первую версию, скорее всего вам придется выкинуть и вторую

MP>>Почему?

DG>Подобный подход может быть практичным, если вы пишете письмо своей тетушке. Отнако расширение метафоры "написания" ПО вплоть до выбрасывания первого экземпляра программы -- не лучший совет в мире разработки ПО, где крупная система по стоимости уже сравнялась с 10-этажным офисным зданием или океанским лайнером.

DG>Полную версию объяснения читайте в книге С.Макконела "Совершенный код" (Code complete)

Насколько я понял, выбрасывать предлагается первую версию, которая до полноценного здания еще не доросла.