Здравствуйте, 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>как ты реализуешь свой модуль, то это проблема.
А это СОВЕРШЕННО к разговору о написании тестов перед функционалом не относится и не пересекается.
[skiped]
MP>Здесь две части — проектирование и программирование. Мне кажется, что мы ломимся в открытую дверь, споря друг с другом. Я согласен, что сразу готовую программу написать сложно, как говорил Брукс "первую версию придется выкинуть".
Весьма спорное утверждение. Если вы собираетесь выкинуть первую версию, скорее всего вам придется выкинуть и вторую
MP>>ЗЯ согласен, что сразу готовую программу написать сложно, как говорил Брукс "первую версию придется выкинуть".
DG>Весьма спорное утверждение. Если вы собираетесь выкинуть первую версию, скорее всего вам придется выкинуть и вторую
Здравствуйте, loco_che, Вы писали:
_>TDD и юниттесты — это _>1. способ описать, что конкретно будет делать код. Не в терминах классов, domain models etc, а в совершенно конкретных вещах — берем на входе a,b,c — получаем на выходе d,e,f. Не больше, но и не меньше. Не надо писать "на будущее", надо только то, что надо.
Т.е. постановщик задачи не в состоянии внятно изложить суть задачи ? Или исполнители не в состоянии понять что от них хотят пока не ткнуть им "скока весить в граммах" ?
Или это попытка бороться с некомпетентностью начальства типа "вы вот мне требования изложите в тестах , я вам код и напишу", если да — тогда это потеря времени , в итоге начальник скажет типа "ты это сам каиенить тесты придумай , и потом к ним код напиши.."
_>2. юниттесты — это не способ тестить приложение, этим занимаются тестеры. Юниттесты — это снапшот кода, работающего по описанным правилам.
Т.е. сам код настолько не очевиден , что проще смотреть в юнит тесты чтобы понять что делает код . Ну если сначала писать тесты а потом код ... все может быть.
_>3. Не тесты пишутся под код, а код под тесты. Это заставляет тщательно продумывать, чего, собственно, должен делать код, на совершенно конкретных примерах и ситуациях.
А без этого вы пишете код не задумываясь в деталях что он будет делать , некий сферический в вакууме код ?
_>А то в большинстве случаев программирование сводится к
_>"Высоко-высоко над Небесным Градом, на небольшой площадке, венчающей _>собою верхушку Шпиля Высотою в Милю, стоял Владыка Иллюзий, Мара-Сновидец. _>Одет он был в плащ всех цветов — и не только радуги. Воздел он над головой _>руки, и, сливаясь воедино с собственной силой, хлынула через его тело мощь _>всех остальных богов. _>В уме его обретала форму греза. И излил он ее наружу, как разливается _>по пляжу накатившаяся на берег высокая волна." (c) понятно кто
_>Изливаем в редактор грезу вместо того, чтобы сделать работу.
Я реально не понимаю , как вообще можно программировать если без юнит тестов вы плохо понимаете что код делать должен ? может менять род занятий ? Мне уже слегка начинают надоедать "новые" серебряные пули несущиеся в неокрепшие умы...
Предлагаю перед написанием юнит тестов , ниписать юнит тесты к самим юнит тестам , чтобы было понятно что именно писать в самих юнит тестах. Для примера предлагаю написать прототип системы и используя его для тестирования юнит тестов написать юнит тесты , которые будут тестировать систему...
Здравствуйте, Mikhail Polykovsky, Вы писали:
MP>>>ЗЯ согласен, что сразу готовую программу написать сложно, как говорил Брукс "первую версию придется выкинуть".
DG>>Весьма спорное утверждение. Если вы собираетесь выкинуть первую версию, скорее всего вам придется выкинуть и вторую
MP>Почему?
Подобный подход может быть практичным, если вы пишете письмо своей тетушке. Отнако расширение метафоры "написания" ПО вплоть до выбрасывания первого экземпляра программы -- не лучший совет в мире разработки ПО, где крупная система по стоимости уже сравнялась с 10-этажным офисным зданием или океанским лайнером.
Полную версию объяснения читайте в книге С.Макконела "Совершенный код" (Code complete)
MP>>>>ЗЯ согласен, что сразу готовую программу написать сложно, как говорил Брукс "первую версию придется выкинуть".
DG>>>Весьма спорное утверждение. Если вы собираетесь выкинуть первую версию, скорее всего вам придется выкинуть и вторую
MP>>Почему?
DG>Подобный подход может быть практичным, если вы пишете письмо своей тетушке. Отнако расширение метафоры "написания" ПО вплоть до выбрасывания первого экземпляра программы -- не лучший совет в мире разработки ПО, где крупная система по стоимости уже сравнялась с 10-этажным офисным зданием или океанским лайнером.
DG>Полную версию объяснения читайте в книге С.Макконела "Совершенный код" (Code complete)
Насколько я понял, выбрасывать предлагается первую версию, которая до полноценного здания еще не доросла.
