Здравствуйте, 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>И действительно, что может быть проще?

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

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