Здравствуйте, vgrigor, Вы писали:
V>т.е. серьезое понимание не возникает, а возникает понимание что адо копать сильно дальше, V>сущетвено доделывая автора, и правя направление согласно современным теденциям.
На то они и паттерны, чтобы давать направление а привязку к местности делать самостоятельно.
V>Мало одого Value Object, надо бы систему применения, критерия где это правильно, на общем плане, V>поэтому яйцо приведено а курица — ет.
Насколько я помню, там это все было.(сейчас нет книжки под рукой). Это объекты которые должны при копировании клонироваться. Это вообще сильно привязано к Java и должно даваться в учебниках по Java.
V>Очень много выборов вариантов, V>из многого неоптималього, хотя похожего по сути, V>а хороших архитектур в результате — НЕ МНОГО.
Как раз хороших архитектур очень много. Архитектура может являеться хорошей, только если она оптимальна для конкретного решения. А этих конкретных решений очень много. Там есть паттерны которые противоречат друг другу, только потому, что применимость зависит от требований.
GZ>>Я понял. Ты смотришь на эту книгу, как книгу по программированию. Это книга по архитектуре. Но не по программированию или практикам разработки. V>просто хочется, чтобы было ощущение работоспособности после чтения книги,
Да не может быть ощущения работоспособности от неполного набора паттернов по концептуальной архитектуре. Код там, только для того чтобы примерно описать паттерн. А от концепции к реализации очень долгий путь. Это не книга программиста или проектировщика. Это книга архитектора.
V>а есть ощущение что ничего практического извлечь нельзя.
Два раза наблюдал, как новички с блеском в глазах рассказывали что в этой книге есть все что нужно знать архитектору. Для меня эта книга лишь структурировала некоторые предыдущие знания. Если бы эта книжка мне попалась лет 6 назад, то у нас с ребятами, не было бы одного неуспешного проекта, но к сожалению, она тогда еще не была написана.
В действительности, эта книга сильно повлияла на архитектуры поскольку вводила систему паттернов. Если ты посмотришь MSDN, то там источник некоторых паттернов указан именно Фаулер.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Re[9]: Comrade Фаулер. Опрос мнений
От:
Аноним
Дата:
24.05.06 17:48
Оценка:
Наверное несоответствий уже много нашли. Но вот какое дело. TDD Довольно осчутимо влияет на архитектуру. Ведь над все тестировать. Отсюда и более жесткая декомпозиция и ухищрения с базами данных.
С другой стороны, Фаулер неоднократно заявлял в своих книгах и публикациях, что предпочитает использовать именно этот стиль разработки.
А в книге то про это молчок... Хотя аспект очень существенный и промолчать про это в книге по архитектуре — мовитон.
Вот почему хотелось увидеть примеры, которые протестированы и работают. Не бывает архитектуры без программирования.
Представте себе архитектора, который не знает что начальное состояние данных и объектов перед любым тестом должно быть одинаковым... Создание тестов порой более хитроумная штука чем склеивать систему из картинок при помощи безликих разработчиков.
Так что устарела книжица. Морально во-всяком случае.
Здравствуйте, GlebZ, Вы писали:
GZ>Нелогично, как то. С одной стороны вы не читаете статьи Фаулера, с другой стороны — вы уже утверждаете о более интересных публикациях.
Да я уже начитался — хватит с меня bullshit. А утверждать что-либо я и не думал это IMHO. Ищтите лучше. На западе выпускается на порядок больше книг по теме.
GZ>У меня понимания хоть отбавляй. На все случаи жизни. Где конкретно ты это нашел. Конкретно — страницу.
Везет же вам! Да explicitly надо говорить — это вам не C# с полиморфизмом — be awared. это может хотябы натолкнуть читателя на поиск решений.
GZ>А что там заканчивать? Вопрос и выеденого яица не стоит. Value Object — чисто явовская фича. Money — я вообще не знаю зачем он вклеил. Видать хотел описать проблематику и типовое решение. Округление денег ведь действительно задалбывает.
Ну про жабу это зря. Далеко не всегда надо коприровать значения, а вот сделать объект immutable — значительно чаще. Money — вообще довольно интересный пример. Он не так прост как кажется. Несколько банковских приложений за плечами позволяют мне оценить важность этой конструкции.
GZ>Где ты видел в этой книге хоть одно упоминание XP? Это набор паттернов. Набор типовых решений которые применяются в определенных случаях, и которые могут быть видоизменены в зависимости от окружения.
Там нет (хотя кто его знает — не перечитывать же). Но мистер Ф все время говорит что он TDD уважает... Надо быть последовательным.
GZ>Это собственно ты ожидаешь из этой книги holy book. Никто, и даже сам Фаулер — вряд ли бы ее классифицировали так. Сделали из трехтомника Кнута — библию. И что? Во первых она не полная, во вторых тяжело читается, и в третьих, тяжко ищется информация. "Алгоритмы: построение и анализ" Корнелла более понятны и удобны.
Я вообще эту книгу не очень люблю. А вот жаркая ее защита (и на мелкософт наехали, и про чеченцев вспомнили) напоминает мне времена инквизиции.
GZ>Да не может быть полной книжка по архитектуре корпоративных приложений. Она дала некоторые общепринятые всеми (и в мире Java и в мире Microsoft) паттерны. Полновесная книга по архитектуре, будет состоять из n-томов, из которых m-томов будет переписываться ежегодно.
Да если посмотреть на паттерны то у авторов даже единой системы имен нету. У кого-то template method, у кого-то framework. У кого-то Special case у кого-то Null object... Какой уж тут справочник...
GZ>А не надо из нее делать полноценный справочник или библию. Это всего лишь часть возможных решений. Этого собственно никто и не скрывает. Я могу по контрактам и открытым интерфейсам книжку не меньше написать.
А может стоит?
GZ>Я понял. Ты смотришь на эту книгу, как книгу по программированию. Это книга по архитектуре. Но не по программированию или практикам разработки.
Здравствуйте, DaBro, Вы писали:
GZ>>А что там заканчивать? Вопрос и выеденого яица не стоит. Value Object — чисто явовская фича. Money — я вообще не знаю зачем он вклеил. Видать хотел описать проблематику и типовое решение. Округление денег ведь действительно задалбывает.
DB>Ну про жабу это зря. Далеко не всегда надо коприровать значения, а вот сделать объект immutable — значительно чаще.
На мой взгляд, уметь разделять полновесные объекты, и полуобъектны value должен быть каждый джаваист. DB>Money — вообще довольно интересный пример. Он не так прост как кажется. Несколько банковских приложений за плечами позволяют мне оценить важность этой конструкции.
Maybe.
DB>Там нет (хотя кто его знает — не перечитывать же). Но мистер Ф все время говорит что он TDD уважает... Надо быть последовательным.
Посмотри здесь
. Не буду его перевирать.
DB>Я вообще эту книгу не очень люблю. А вот жаркая ее защита (и на мелкософт наехали, и про чеченцев вспомнили) напоминает мне времена инквизиции.
Не понял Откуда чечены появились? И в честь чего на мелкософт наехали?
DB>Да если посмотреть на паттерны то у авторов даже единой системы имен нету. У кого-то template method, у кого-то framework. У кого-то Special case у кого-то Null object... Какой уж тут справочник...
Есть такое дело. Терминология неустоявшаяся, но большая часть терминологии из этой книги прижилась. Посмотри сборник паттернов Microsoft
DB>Не бывает архитектуры без программирования.
Бывает архитектура до программирования.
GZ>На то они и паттерны, чтобы давать направление а привязку к местности делать самостоятельно.
Если есть что привязывать, но нет такого ощущения то есть такие вещи там.
GZ>Как раз хороших архитектур очень много. Архитектура может являеться хорошей, только если она оптимальна для конкретного решения. А этих конкретных решений очень много. Там есть паттерны которые противоречат друг другу, только потому, что применимость зависит от требований.
А я вот помню микрософт одну выдумал DNA, работающую, на 5 лет.
И больше не было.
А Java — J2EE.
Потом стали изобретать разные штуки, но набор не стал особенно большим.
Хотя параметризаций одного и того же — множество.
Кроме SOA можете вспомнить еще такого, выделенного типа арзитектур, названия ?
GZ>>>Я понял. Ты смотришь на эту книгу, как книгу по программированию. Это книга по архитектуре. Но не по программированию или практикам разработки.
Ну, да — только я не пойму почему архитектура должна быть бесползеной.
возьмем DNA к примеру — там все ясно, и даже код.
GZ>Да не может быть ощущения работоспособности от неполного набора паттернов по концептуальной архитектуре. Код там, только для того чтобы примерно описать паттерн. А от концепции к реализации очень долгий путь. Это не книга программиста или проектировщика. Это книга архитектора.
Да долгий, зато он мастер, или не мастер,
чтобы опробировать пути, пройти заметнную практическую часть,
и дать нам за наши деннежки ?
Или только тоже добрые слова, хотя так крут?
Не крут.
GZ>Два раза наблюдал, как новички с блеском в глазах рассказывали что в этой книге есть все что нужно знать архитектору. Для меня эта книга лишь структурировала некоторые предыдущие знания. Если бы эта книжка мне попалась лет 6 назад, то у нас с ребятами, не было бы одного неуспешного проекта, но к сожалению, она тогда еще не была написана.
Это да, 3 года назад — это было неплохо, а особенно 6,
а теперь это общеизвестные вещи, инкапсулированные в библиотеки.
А фаулер — только наметки,
на сейчас сделанное.
Маразм да?
GZ>В действительности, эта книга сильно повлияла на архитектуры поскольку вводила систему паттернов. Если ты посмотришь MSDN, то там источник некоторых паттернов указан именно Фаулер.
Славься Фаулер! Славься Фаулер!
Ура народному герою Фаулеру, товарищи!
Хитрые МикроМягкие... Они юзают Фаулера, для красного словца, и что они чттут права, и как красивый аргумент, которому народ поклоняется.
Паттерны — хорошо,я не спорю, много сделал хорошего,
но книга давно уже не шибко полезна, и изначально была недоделана.
К примеру: классифиировал он ОРМ, но вместо указаний на правильные организации, архитектуру
он просто сказал — что де это круто для детей, довольствуйтесь классификацией.
(от базы, от обьектов, и смешанное что-то).
типа "смотрите Вильсона, а то мне самому проанализировать облом или никак".
GZ>Читайте автора:здесь GZ>И здесь русский перевод.
Ужас, как не перевариваю XP!!!
гадость редкостная.
— Психушка (- экстремалыв этом!)
— гербалайф, — рай для прессования программистов, зомбирование их,
— прикрыто аналогиями MSF и Agile, чтобы обмануть общественность что там есть стоящие вещи
сами по себе.
Умри XP !!
еще, отдельно Это люди, говорят что "архитектура не нужна,
а нуждна простая разработка"
в приведеной статье (хорошая статья, видно где бомбы ХП)
Ну да — используйте сначала файлы, потом уже на базу переползайте ("сынки"). Известная тема. Опять bullshit. Либо афтор не часто разработкой серъезных систем занимается.
Меня одно удивляет. По моему опыту трах с базой данных если применяются unit tests отнимает довольно много времени (а если поверить в сказки про файлы в начале пректа — то и подавно) а вот честно про это рассказать ни Фаулер ни Бэк не удосужились. А ведь это бы сильно помогло начинающим. Может быть они не трахались с базой то — у них все сразу получилось или и не пытались даже? А вроде практики великие. Во многом из-за этого сомнения у меня и зародились. А еще из-за склонности комрада Ф к словоблудию и красивым но бессмысленным оборотам речи.
Прав комрад в одном — архитектор (во всяком случае тот который будет принят на работу в серъезный проект ) — не программист а очень опытный программист продолжающий практиковаться в написании кода. Хотя может я опять чего не понял — словоблудом быть он должен...
У меня сейчас проблема есть — приложение с ~1K unit tests. И там изначально понятно был что файлами то не обойтись. И вот тут поодержка тестов начинает занимать 50% времени. А самое забавное что тесты рефакторяться иногда чаще чем рабочий код. Потому что борьба со сложностью. И нет гарантии что тесты остаються корректными — никто не застрахован. Не скажу что без них было бы проще, но с базой, и системами кэша такое вытворять приходится... И ведь надо чтоб хотябы минут за 10 все выполнялось (как раз перекур устроить можно ). К тому же и заказчик поторапливает. А Кент и Мартин знай себе повторяют — главное чтобы быстро и покрытие 100%. Может они только примеры к книгам пишут?
GZ>Бывает архитектура до программирования.
А бывает и во время — вот тут все ошибки мега-архитекторов и вылазят. Причем как правило они их признавать не собираются (это из более раннего опыта — сейчас к счастью пафоса поменьше у профессии этой стало)
А к тому-же попробуй ка поархитектурить когда даже заказчик не знает толком чего хочет. Зато хочет быстро и с должным качеством.
Здравствуйте, DaBro, Вы писали:
DB>Да если посмотреть на паттерны то у авторов даже единой системы имен нету. У кого-то template method, у кого-то framework. У кого-то Special case у кого-то Null object... Какой уж тут справочник...
Это характерно для любой развивающейся и еще не устаканившейся области знаний.
V>>Ужас, как не перевариваю XP!!!
L>Что конкретно тебе не нравится в xp?
Парны программированием — в особенности.
V>>- гербалайф, — рай для прессования программистов, зомбирование их, L>В чем это проявляется?
Программисты в паре вынуждены давить друг на друга, — очень хтрая выдумка авторов методики,
хотя они не упоминают жтой цели,
тоже вполне хитро,
т.е. обманная методика в своей основе. фу!
Культивированием совсем упрощенных подходов к инфраструктуре программы,
отдавая предпочтению чисто напряженному кодингу.
V>>- прикрыто аналогиями MSF и Agile, чтобы обмануть общественность что там есть стоящие вещи V>>сами по себе. L>Если я не ошибаюсь, то даже термин agile (и agile в msf) появился несколько позже появления xp.
Может быть, я не помню, не суть, — слово "быстро" в программировании было всегда.
а уж "неформально" — с самого начала,
и все это себе присваивает ХП — для прикрытия своей соновной отличной сути, которая выше.
Здравствуйте, vgrigor, Вы писали:
L>>Что конкретно тебе не нравится в xp?
V>Парны программированием — в особенности.
Ты пробовал? Я до того, как начал работать в компании, практикующей xp, тоже думал что парное программирование — это чушь. Но со временем мое мнение изменилось.
L>>В чем это проявляется?
V>Программисты в паре вынуждены давить друг на друга, — очень хтрая выдумка авторов методики, V>хотя они не упоминают жтой цели, V>тоже вполне хитро, V>т.е. обманная методика в своей основе. фу!
В чем заключается давление? Уж не в том ли, что когда ты работаешь в паре, то вряд ли полезешь на какой-нибуть сайт анекдотов?
V>Культивированием совсем упрощенных подходов к инфраструктуре программы, V>отдавая предпочтению чисто напряженному кодингу.
Чушь. Отдается предпочтение не "совсем упрощенным подходам", а ударение делается на то, что бы не дизайнить "с запасом".
V>>>- прикрыто аналогиями MSF и Agile, чтобы обмануть общественность что там есть стоящие вещи V>>>сами по себе. L>>Если я не ошибаюсь, то даже термин agile (и agile в msf) появился несколько позже появления xp.
V>Может быть, я не помню, не суть, — слово "быстро" в программировании было всегда.
Еще раз повторю. agile (и agile в msf) — исторически более поздние явления чем xp и, следовательно, говорить о том, что xp ими прикрывается несколько некорректно.
L>Ты пробовал? Я до того, как начал работать в компании, практикующей xp, тоже думал что парное программирование — это чушь. Но со временем мое мнение изменилось.
Я жил в общежитии,
ездил в полных автобусах.
то же и программист и второй программист за одним кодом одновременно.
V>>Может быть, я не помню, не суть, — слово "быстро" в программировании было всегда.
L>Еще раз повторю. agile (и agile в msf) — исторически более поздние явления чем xp и, следовательно, говорить о том, что xp ими прикрывается несколько некорректно.
Неважно "что исторически и может быть"
когда говорят чем не так плоха ХП — ссылаются на аналогии с Agile, и MSF,
последние две- неоспоримо хороши, а ХП пользуется этими техниами как прикрытием основных гадостей,
которые обсуждаются.
т.е. в ХП хорошо только Agile и MSF, а не кто кого изобрел.
L>>Ты пробовал? Я до того, как начал работать в компании, практикующей xp, тоже думал что парное программирование — это чушь. Но со временем мое мнение изменилось.
V>Я жил в общежитии, V>ездил в полных автобусах.
V>то же и программист и второй программист за одним кодом одновременно.
Я не спрашивал где ты жил и на чем ездил. Ответь, пожалуйста на вопрос.
V>>>Может быть, я не помню, не суть, — слово "быстро" в программировании было всегда.
L>>Еще раз повторю. agile (и agile в msf) — исторически более поздние явления чем xp и, следовательно, говорить о том, что xp ими прикрывается несколько некорректно.
V>Неважно "что исторически и может быть"
Важно то, что если принимать это во внимание, то твои слова о том, что xp аппелирует к agile-технологиям — бред.
Одним из очень важных преимуществ XP-style (IMHO) является то, что код
может сопровождать сразу два программиста. Т.е. если один попадает в
форс-мажор, код продолжает сопровождаться без остановок. Особенно,
если при этом производится тасовка пар в команде — самый продвинутый уровень
применения. Тогда владение кодом и понимание работы всего программного
комплекса выходит на качественно иной уровень.
Но основная беда XP в том, что внедрять его желательно сверху, от
руководства
командой. А, как показала практика, профессиональные командные программисты,
попробовав XP, ее поддерживают. А вот некомандным она полностью бесполезна.
И, по моему, главное заблуждение противников XP-style — это то, что
применение XP означает отсутствие этапа архитектурного проектирования
системы, документирования и других канонических из Waterfall-стиля.
Но предыдущие ораторы это уже прокомментировали.
Где конкретно ты это нашел. Конкретно — страницу.
) — не программист а очень опытный программист продолжающий практиковаться в написании кода. Хотя может я опять чего не понял — словоблудом быть он должен...
). К тому же и заказчик поторапливает. А Кент и Мартин знай себе повторяют — главное чтобы быстро и покрытие 100%. Может они только примеры к книгам пишут? 
