Коллеги, а не закрадывлось ли у вас осчусЧения что буржуйский товарисчи (Фаулер, Бэк) и иже с ними вводят в заблуждение нашего брата. Рассмотрим примеры — кто видил работающий пример в книге Ф? Кто знает как сделать unit tests быстрыми в большом приложении, работаюшем с реляционной базой? А есть рецепт как их воообще сделать? При этом оба считаются большими практиками нашего дела... Может жажда наживы завладела нашими забугорными братьями. Не ради здравого смысла плодят они бесконечные XP и Agile, а кОрысти ради?
Отдавая должное идеолагам — скажу что test driven development не плох по сравнеию с тем что было до него. Но все же... продавая книгу за 700 руб. стоит и об аудитории задуматься.
PS Как сделать голосование не разобрался — так что в форум пишем...
В догонку
Цель опроса — узнать у кого какое мнение от прочтения/применения "новомодных" методов программирования.
А также о доверии практиков к трудам жадных до денег буржуйских теоретиков.
D> Коллеги, а не закрадывлось ли у вас осчусЧения что буржуйский товарисчи D> (Фаулер, Бэк) и иже с ними вводят в заблуждение нашего брата. Рассмотрим D> примеры — кто видил работающий пример в книге Ф? Кто знает как сделать D> unit tests быстрыми в большом приложении, работаюшем с реляционной D> базой? А есть рецепт как их воообще сделать? При этом оба считаются D> большими практиками нашего дела... Может жажда наживы завладела нашими D> забугорными братьями. Не ради здравого смысла плодят они бесконечные XP D> и Agile, а кОрысти ради?
Недостаток этих книг в том, что они показывают начинающим разработчикам путь, до которого ни не доросли еще, эти разрабочики.
В результате разработчики со своими кривыми руками кидаются следовать этим книгам и их ждет большой облом из-за недостатка опыта.
Они просто не могут правильно применить методологию для своего конкретного проекта.
А про тестирование у Фаулера написано. Не помню, возможно между строк
Там и написано, что для тестирования необходимо изолировать слои, чтоб можно було легко подменить реальный слой на слой тестирования.
Т.е. например для тестирования приложения, работающего с базой данных, просто отключаем слой работы непосредственно с базой, и заменяем его слоем — заглушкой, который будет эмулировать слой работы с базой, но сливать все в лог, или выдавать данные согласно плану тестирования.
Аналогично для других слоев.
Т.о. с тестированием то как раз проблемы нет. Проблема в другом. Проблема в правильной архитектуре. И вот правильный выбор архитектуры, разбивка на слои, модули это как раз таки очень сложно и словаи это не описать. нужен опыт. Книга тут только первый шаг. После этого нужно раз 10 переписывать, пока не поймешь как же надо правильно. Если вообще поймешь
Здравствуйте, DaBro, Вы писали:
DB>Коллеги, а не закрадывлось ли у вас осчусЧения что буржуйский товарисчи (Фаулер, Бэк) и иже с ними вводят в заблуждение нашего брата. Рассмотрим примеры — кто видил работающий пример в книге Ф? Кто знает как сделать unit tests быстрыми в большом приложении, работаюшем с реляционной базой? А есть рецепт как их воообще сделать? При этом оба считаются большими практиками нашего дела... Может жажда наживы завладела нашими забугорными братьями. Не ради здравого смысла плодят они бесконечные XP и Agile, а кОрысти ради?
DB>Отдавая должное идеолагам — скажу что test driven development не плох по сравнеию с тем что было до него. Но все же... продавая книгу за 700 руб. стоит и об аудитории задуматься.
DB>PS Как сделать голосование не разобрался — так что в форум пишем...
У буржуйских товарищей (кроме микросот) ест традиция писать книги иключительно добросовестно,
куда входит и полезность,
(Но это не значит что она будет действительно полезна.)
и в этом им помогает дружный коллектив советчиков а потом редакция,
которым такое обвинение- страшное дело:
совсем не как у нас — у нас срубить бабок "любым способом" теперь "дело чести",
как у чеченцев : "важны деньги, ограбь соседа — и ты правильный мужик"
Почитайте российские книги на эту тему....
Я думаю вы не найдете не одной почему-то ?
У книги есть ряд недостатков — програмной пользы мало,
зато он расскзаывает какие архитектурные подходы существовали до времени 2 года тому назад,
фундамент.
Здравствуйте, kochmin_alexandr, Вы писали:
D>> Коллеги, а не закрадывлось ли у вас осчусЧения что буржуйский товарисчи D>> (Фаулер, Бэк) и иже с ними вводят в заблуждение нашего брата. Рассмотрим D>> примеры — кто видил работающий пример в книге Ф? Кто знает как сделать D>> unit tests быстрыми в большом приложении, работаюшем с реляционной D>> базой? А есть рецепт как их воообще сделать? При этом оба считаются D>> большими практиками нашего дела... Может жажда наживы завладела нашими D>> забугорными братьями. Не ради здравого смысла плодят они бесконечные XP D>> и Agile, а кОрысти ради?
_>Недостаток этих книг в том, что они показывают начинающим разработчикам путь, до которого ни не доросли еще, эти разрабочики. _>В результате разработчики со своими кривыми руками кидаются следовать этим книгам и их ждет большой облом из-за недостатка опыта. _>Они просто не могут правильно применить методологию для своего конкретного проекта.
[skiped]
Недостаток ли это книг, если их читают те, кому, вообщем-то не то, что не положено их читать, а порой и вредно?
И даже, если списать часть на "кривые руки", остается еще одни момент: я не уверен, что Фаулер, Бек и иже с нимни "зажрались" и "плодят они бесконечные XP и Agile". Скорее всего делают это они как раз-таки не от хорошей жизни, а от сложности тех проектов, с которыми они сталкиваются каждый день.
К сожалению, вряд ли многие "наши" пытались ответить хотя бы на вопрос — "Зачем"?
Здравствуйте, kochmin_alexandr, Вы писали:
_>Недостаток этих книг в том, что они показывают начинающим разработчикам путь, до которого ни не доросли еще, эти разрабочики. _>В результате разработчики со своими кривыми руками кидаются следовать этим книгам и их ждет большой облом из-за недостатка опыта. _>Они просто не могут правильно применить методологию для своего конкретного проекта.
Здравствуйте, Andir, Вы писали:
A>Здравствуйте, kochmin_alexandr, Вы писали:
_>>Недостаток этих книг в том, что они показывают начинающим разработчикам путь, до которого ни не доросли еще, эти разрабочики. _>>В результате разработчики со своими кривыми руками кидаются следовать этим книгам и их ждет большой облом из-за недостатка опыта. _>>Они просто не могут правильно применить методологию для своего конкретного проекта.
A>Удивительно точно выражено
Я не согласен.
Не всегда авторитеты пишут золото к которому надо стремиться и когда дойдешь — получится это золото.
Надо с этим спокойнее, а то бывает как в известной пословице:
"заставишь, дурака богу молиться, а он весь лоб разобьет"
В данном случае это проосто сборка советов,
— выраженных не очень четко,(мысль о полезности и месте в общей системе нечетка иили неопределена, и вообще недоделано все)
— и не доведенных до ума или какой-либо демонстрации,
— по достаточно избитым паттернам как ОРМ, — это уже не надо всем, а только создателям ОРМ, как внутренности SQL раньше,
— в тоже время пропустив действительно современные и полезные вместе оригинальносью архитектуры,
которые позволяют создавать и понимать действительно действительно хорошо организованные программы.
Так что в эт книге Фаулер совсем не как полубог выступил, ну совсем...
Не стоит смущать "молодых программистов" лишний раз "непонятной божественностью".
Здравствуйте, vgrigor, Вы писали:
A>>Удивительно точно выражено V>Я не согласен. V>[skip] V>Не стоит смущать "молодых программистов" лишний раз "непонятной божественностью".
С этой фразой тоже согласен Речь не о величественности Фаулера и остальных "консалтеров", а о том, что книги такого типа являются скорее способом упорядочить знания уже опытного разработчика, а не учебником для начинающего.
Здравствуйте, DaBro, Вы писали:
DB>Коллеги, а не закрадывлось ли у вас осчусЧения что буржуйский товарисчи (Фаулер, Бэк) и иже с ними вводят в заблуждение нашего брата. Рассмотрим примеры — кто видил работающий пример в книге Ф?
У господина Ф много книг. И по UML и по архитектуре. Судя по всему вы имеете ввиду именно XP. DB>Кто знает как сделать unit tests быстрыми в большом приложении, работаюшем с реляционной базой? А есть рецепт как их воообще сделать?
Эталонная база данных, либо подмена интерфейсов БД. Unit-тесты — это штука далеко не бесплатная. С ними нужно повозиться. По некоторым оценкам на unit-тесты уходит до 30 процентов времени. Никто собственно и не обещал коммунизма(хотя мне попадались книжки по XP в котором это обещалось но это не в книжках вышеописанных товарищей).
Кроме того, многое просто невозможно описать unit-тестами.
DB>Отдавая должное идеолагам — скажу что test driven development не плох по сравнеию с тем что было до него. Но все же... продавая книгу за 700 руб. стоит и об аудитории задуматься.
Тогда судя по логике, получается, что именно тебя корысть одолела.
...
A>С этой фразой тоже согласен Речь не о величественности Фаулера и остальных "консалтеров", а о том, что книги такого типа являются скорее способом упорядочить знания уже опытного разработчика, а не учебником для начинающего.
Возможно именно такая цель и подразумевалась. Да только имхо книга получилась довольно хаотичной — система прослеживается плохо, просто куча мала различных приемов и советов. Несомненное достоинство книги — в ней предложен словарь терминов. И теперь не надо натужно выдумывать собственые названия.
Чтож,
Судя по обилию переходов на личности тема животрепещущая. Это хорошо!
А теперь по-порядку. Как было замечено в некоторых постах — в книге Фаулера — Архитектура корп. прилаж. Присутствует некоторая хаотичность. Она к тому-же усугубляется практически полным отсутствием работающих или хотя-бы законченных примеров. В принципе никто не ограничивал автора — можно было бы сделать "солюшен" с юнит-тестами для пары важных концепций на CD. Кажется упомянутый комрад лестно отзывался об XP. Так гдеж примеры то?
Про UML (во всяком случае 2-е издание) я вообще умолчу. Книга весьма далекая от практики.
Рефакторинг — да — достойная книга.
Опять же не могу спорить с тем что у нас пишется оч. мало хороших книг по программированию(во всяком случае по архитектуре корпоративных систем и тп). А еще меньше переводиться! По поводу наших авторов ясно одно — далеко им до буржуев...
По поводу тестов — это круто. Слои, грамотная архитектура... Ясно, что эти вопросы решаются тем или иным способом. К счастью вариантов масса. Только вот странно почему маститые авторы упоминают только один — основанный на полиморфизме?
Ну а по поводу бабла скажу одно — оно еще никому не мешало! Вряд-ли кто-нибудь будет спорить
Кстати, по поводу зарубежных авторов — был тут давича в одном большом московском книжном, так там все полки заставлены клонами тип В недрах Ado.Net, C++ за 21 день, и Java для домохозяек. И пишут все это дабро тоже не у нас...
Здравствуйте, DaBro, Вы писали:
DB>А теперь по-порядку. Как было замечено в некоторых постах — в книге Фаулера — Архитектура корп. прилаж. Присутствует некоторая хаотичность. Она к тому-же усугубляется практически полным отсутствием работающих или хотя-бы законченных примеров. В принципе никто не ограничивал автора — можно было бы сделать "солюшен" с юнит-тестами для пары важных концепций на CD. Кажется упомянутый комрад лестно отзывался об XP. Так гдеж примеры то?
Законченный пример корпоративного приложения? Ну-ну. И причем тут XP? Книжка называется "Архитектура корпоративных программных приложений", а не "сборник примеров корпоративных приложений с использованием TDD". Книжка хорошая, но вот с интерпретацией того что там написано, достаточно проблематично. Забывают о ключевом слове "корпоративных", и забывают то, что на этих паттернах все программирование не кончается. И в том числе в "корпоративных приложениях". А хаотичности там мало. Все прекрасно структурировано.
DB>Опять же не могу спорить с тем что у нас пишется оч. мало хороших книг по программированию(во всяком случае по архитектуре корпоративных систем и тп). А еще меньше переводиться! По поводу наших авторов ясно одно — далеко им до буржуев...
Учи английский. Основные интересные мысли не в книгах, а в статьях.
DB>Только вот странно почему маститые авторы упоминают только один — основанный на полиморфизме?
Не понял что ты имеешь ввиду.
DB>Ну а по поводу бабла скажу одно — оно еще никому не мешало! Вряд-ли кто-нибудь будет спорить
А для бабла — нужно имя. Фаулер сделал себе имя. И вполне заслуженно.
DB>>Ну а по поводу бабла скажу одно — оно еще никому не мешало! Вряд-ли кто-нибудь будет спорить GZ>А для бабла — нужно имя. Фаулер сделал себе имя. И вполне заслуженно.
Заслуженное сделанное "Имя" — позволяет выпустить недоработанную книгу?
"Зачетка работает" — не знания, так бывает.
Если бы там было дело — пусть бы она стоила 1000 рупий тут, архитектура того стоит,
задумка была отличная, но задумка и резульаты — несколько разные вещи,
как сделано — по моему и 600 рупий не стоит, зато бумага хорошая.
Хотя почитать о чем все говорят и на что ссылаются надо конечно.
Здравствуйте, vgrigor, Вы писали:
V>Заслуженное сделанное "Имя" — позволяет выпустить недоработанную книгу?
Конкретней. Что значит недоработанную? Место или ссылку!!!
Уважаемый GlebZ Я очень благодарен за по-истине отеческую заботу.
Надо было "учи английский, сынок!"
Могу вас уверить, что английский язык я знаю неплохо. Правда, читать статьи означенного комрада желания у меня нет.
Есть масса куда-более интересных публикаций.
Если нет понимания о полиморфизме. Все что написано в обсуждаемой литературе основываеться на одном подходе — сделай Mock-объект. У вас такое всегда работает? А сколько времени на поддержку тратите? (вопрос на засыпку — а где полиморфизм то? — шутка.)
В прочем между строк может и проскакивает идея, но искать ее в книге на 800 страниц — уж извините — на то google есть.
Если вы считаете что в книге рассматриваеться законченный, но не работающий пример корпоративного приложения, то да — исходники на компакт все-равно не влезут. Но Value Object и Money можно было и закончить. А тем более удачный был бы шаг — демонстрация силы TDD на столь простеньком примере... Хотя можно было-бы и поинтереснее примеры написать.
Возвращаясь к теме опроса.
Многие отнеслись личностно. Я знаю — трудно наезжать на holy book.
Авторов ограниченное число — некоторые склонны признать тот факт что книга (Архитектура прог. прилаж.) не полна.
Многие же призывают к истине и просят привести ссылку. И те и другие правы. Если кому-то книга кажеться вполне достаточной — это хорошо, если же кто то не нашел там ответов — это еще лучше!
По-моему надо проверять любую идею на опыте. А вторая эвристика — если ты хочешь написать хорошую книгу по программированию — потрудись иллюстрировать ее примерами кода. Картинки не катят — это для художников. Есть много неплохих в этом плане примеров. Можно на amazon полюбопытствовать...
Судя по количеству заинтересовавшихся — 7 человек — тема из разряда священных войн. Очень жаль...
Видать не популярна.
А итог такой — главное без фанатизма — читайте хорошую литературу и учитись отличать красивую обложку от полезного содержания.
Здравствуйте, DaBro, Вы писали:
DB>Могу вас уверить, что английский язык я знаю неплохо. Правда, читать статьи означенного комрада желания у меня нет. DB>Есть масса куда-более интересных публикаций.
Нелогично, как то. С одной стороны вы не читаете статьи Фаулера, с другой стороны — вы уже утверждаете о более интересных публикациях.
DB>Если нет понимания о полиморфизме. Все что написано в обсуждаемой литературе основываеться на одном подходе — сделай Mock-объект. У вас такое всегда работает? А сколько времени на поддержку тратите? (вопрос на засыпку — а где полиморфизм то? — шутка.) DB>В прочем между строк может и проскакивает идея, но искать ее в книге на 800 страниц — уж извините — на то google есть.
У меня понимания хоть отбавляй. На все случаи жизни. Где конкретно ты это нашел. Конкретно — страницу.
DB>Если вы считаете что в книге рассматриваеться законченный, но не работающий пример корпоративного приложения, то да — исходники на компакт все-равно не влезут. Но Value Object и Money можно было и закончить.
А что там заканчивать? Вопрос и выеденого яица не стоит. Value Object — чисто явовская фича. Money — я вообще не знаю зачем он вклеил. Видать хотел описать проблематику и типовое решение. Округление денег ведь действительно задалбывает.
DB>А тем более удачный был бы шаг — демонстрация силы TDD на столь простеньком примере... Хотя можно было-бы и поинтереснее примеры написать.
Где ты видел в этой книге хоть одно упоминание XP? Это набор паттернов. Набор типовых решений которые применяются в определенных случаях, и которые могут быть видоизменены в зависимости от окружения.
DB>Многие отнеслись личностно. Я знаю — трудно наезжать на holy book.
Это собственно ты ожидаешь из этой книги holy book. Никто, и даже сам Фаулер — вряд ли бы ее классифицировали так. Сделали из трехтомника Кнута — библию. И что? Во первых она не полная, во вторых тяжело читается, и в третьих, тяжко ищется информация. "Алгоритмы: построение и анализ" Корнелла более понятны и удобны.
DB>Авторов ограниченное число — некоторые склонны признать тот факт что книга (Архитектура прог. прилаж.) не полна.
Да не может быть полной книжка по архитектуре корпоративных приложений. Она дала некоторые общепринятые всеми (и в мире Java и в мире Microsoft) паттерны. Полновесная книга по архитектуре, будет состоять из n-томов, из которых m-томов будет переписываться ежегодно.
DB>Многие же призывают к истине и просят привести ссылку. И те и другие правы. Если кому-то книга кажеться вполне достаточной — это хорошо, если же кто то не нашел там ответов — это еще лучше!
А не надо из нее делать полноценный справочник или библию. Это всего лишь часть возможных решений. Этого собственно никто и не скрывает. Я могу по контрактам и открытым интерфейсам книжку не меньше написать.
DB>По-моему надо проверять любую идею на опыте. А вторая эвристика — если ты хочешь написать хорошую книгу по программированию — потрудись иллюстрировать ее примерами кода. Картинки не катят — это для художников. Есть много неплохих в этом плане примеров. Можно на amazon полюбопытствовать...
Я понял. Ты смотришь на эту книгу, как книгу по программированию. Это книга по архитектуре. Но не по программированию или практикам разработки.
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, DaBro, Вы писали:
DB>>Могу вас уверить, что английский язык я знаю неплохо. Правда, читать статьи означенного комрада желания у меня нет. DB>>Есть масса куда-более интересных публикаций. GZ>Нелогично, как то. С одной стороны вы не читаете статьи Фаулера, с другой стороны — вы уже утверждаете о более интересных публикациях.
У него есть весьма удачные статьи.
т.е. когда прочитаешь — 2возникает понимание",
но вот книга не получилась удачной.
т.е. серьезое понимание не возникает, а возникает понимание что адо копать сильно дальше,
сущетвено доделывая автора, и правя направление согласно современным теденциям.
Поэтому недоделанная.
GZ>У меня понимания хоть отбавляй. На все случаи жизни. Где конкретно ты это нашел. Конкретно — страницу.
Там вообще все — неплохо начато,но сильно фрагметарно закончено.
DB>>Если вы считаете что в книге рассматриваеться законченный, но не работающий пример корпоративного приложения, то да — исходники на компакт все-равно не влезут. Но Value Object и Money можно было и закончить. GZ>А что там заканчивать? Вопрос и выеденого яица не стоит. Value Object — чисто явовская фича. Money — я вообще не знаю зачем он вклеил. Видать хотел описать проблематику и типовое решение. Округление денег ведь действительно задалбывает.
Мало одого Value Object, надо бы систему применения, критерия где это правильно, на общем плане,
поэтому яйцо приведено а курица — ет.
DB>>Авторов ограниченное число — некоторые склонны признать тот факт что книга (Архитектура прог. прилаж.) не полна. GZ>Да не может быть полной книжка по архитектуре корпоративных приложений. Она дала некоторые общепринятые всеми (и в мире Java и в мире Microsoft) паттерны. Полновесная книга по архитектуре, будет состоять из n-томов, из которых m-томов будет переписываться ежегодно.
нет, можно аписать ясно и понятно,
если таковое понимание есть у автора.
Очень много выборов вариантов,
из многого неоптималього, хотя похожего по сути,
а хороших архитектур в результате — НЕ МНОГО.
DB>>По-моему надо проверять любую идею на опыте. А вторая эвристика — если ты хочешь написать хорошую книгу по программированию — потрудись иллюстрировать ее примерами кода. Картинки не катят — это для художников. Есть много неплохих в этом плане примеров. Можно на amazon полюбопытствовать... GZ>Я понял. Ты смотришь на эту книгу, как книгу по программированию. Это книга по архитектуре. Но не по программированию или практикам разработки.
просто хочется, чтобы было ощущение работоспособности после чтения книги,
а есть ощущение что ничего практического извлечь нельзя.
Здравствуйте, vgrigor, Вы писали:
V>Мало одого Value Object, надо бы систему применения, критерия где это правильно, на общем плане, V>поэтому яйцо приведено а курица — ет.
Паттерны это такая штука, а особенно архитектурные, что критерии правильности применения подобрать...хм, ну Вы поняли. А собственно Фаулер и не претендовал на то, чтобы описать систему применения и всё такое — просто набор удачных решений, хотя часто встречаются его советы и примеры по реальному применению того или иного паттерна. Короче говоря, в Джихад катимся господа, с этим обсуждением.
ЗЫ. И книгу то никто и не заставляет покупать и паттерны эти изучать Но тем не менее, "ел и плевался, плевался и ел" (С)
Здравствуйте, 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-стиля.
Но предыдущие ораторы это уже прокомментировали.
Здравствуйте, DaBro, Вы писали:
DB>Ну да — используйте сначала файлы, потом уже на базу переползайте ("сынки"). Известная тема. Опять bullshit. Либо афтор не часто разработкой серъезных систем занимается.
Ты по моему плохо прочел мнение автора.
DB>Меня одно удивляет. По моему опыту трах с базой данных если применяются unit tests отнимает довольно много времени (а если поверить в сказки про файлы в начале пректа — то и подавно) а вот честно про это рассказать ни Фаулер ни Бэк не удосужились. А ведь это бы сильно помогло начинающим. Может быть они не трахались с базой то — у них все сразу получилось или и не пытались даже? А вроде практики великие. Во многом из-за этого сомнения у меня и зародились. А еще из-за склонности комрада Ф к словоблудию и красивым но бессмысленным оборотам речи.
Для того, чтобы понять что автор говорит, нужно понять что такое XP. XP — это выстроенная система в которой практики взаимосвязанны.Когда ты это поймешь и поймешь почему это так, ты поймешь и о чем пишет автор.
DB>У меня сейчас проблема есть — приложение с ~1K unit tests.
1 кил? DB>И там изначально понятно был что файлами то не обойтись. И вот тут поодержка тестов начинает занимать 50% времени. А самое забавное что тесты рефакторяться иногда чаще чем рабочий код. Потому что борьба со сложностью. И нет гарантии что тесты остаються корректными — никто не застрахован. Не скажу что без них было бы проще, но с базой, и системами кэша такое вытворять приходится... И ведь надо чтоб хотябы минут за 10 все выполнялось (как раз перекур устроить можно ). К тому же и заказчик поторапливает. А Кент и Мартин знай себе повторяют — главное чтобы быстро и покрытие 100%. Может они только примеры к книгам пишут?
Первое, покрытие на 100 процентов не бывает, или бывает в очень простых случаях. Во вторых, тесты нужны в XP, не просто так. Они нужны для автоматизации рефакторинга. А рефакторинг нужен тоже не просто так. А он нужен чтобы поддерживать эволюцию проекта в системе коротких итераций. А эволюция проекта не просто так делается, а за счет нее убирается время на сбор и анализ требований(а это иногда до 2/3 времени проекта). А генерацию требований не отменишь, если у тебя не будет заказчика под боком. Все взаимосвязанно. Что-то выбьешь, ничего не получишь.
DB>А бывает и во время — вот тут все ошибки мега-архитекторов и вылазят. Причем как правило они их признавать не собираются (это из более раннего опыта — сейчас к счастью пафоса поменьше у профессии этой стало)
Ошибки у мега-архитекторов не вылазят. На то они и мега-архитекторы чтобы уметь бороться с рисками. DB>А к тому-же попробуй ка поархитектурить когда даже заказчик не знает толком чего хочет. Зато хочет быстро и с должным качеством.
Так значит тебе нравится XP?
Здравствуйте, vgrigor, Вы писали:
V>Важно то, что если принимать это во внимание, то твои слова о том, что xp не аппелирует к agile-технологиям — бред.
Если не сложно, ответь на вопрос:
Может ли кто-либо для доказательствава своей правоты приводить в пример то, чего еще не существует?
GZ>Ты по моему плохо прочел мнение автора.
Я много раз читал мнение автора.
GZ>Для того, чтобы понять что автор говорит, нужно понять что такое XP. XP — это выстроенная система в которой практики взаимосвязанны.Когда ты это поймешь и поймешь почему это так, ты поймешь и о чем пишет автор.
Не вижу ответа на вопрос. Я уже давно не могу понять что такое XP
DB>>У меня сейчас проблема есть — приложение с ~1K unit tests. GZ>1 кил?
Да 784 если быть точным.
GZ>Первое, покрытие на 100 процентов не бывает, или бывает в очень простых случаях. Во вторых, тесты нужны в XP, не просто так. Они нужны для автоматизации рефакторинга. А рефакторинг нужен тоже не просто так. А он нужен чтобы поддерживать эволюцию проекта в системе коротких итераций. А эволюция проекта не просто так делается, а за счет нее убирается время на сбор и анализ требований(а это иногда до 2/3 времени проекта). А генерацию требований не отменишь, если у тебя не будет заказчика под боком. Все взаимосвязанно. Что-то выбьешь, ничего не получишь.
А третье — методологии названные agile пытаються позаимствовать хотябы подмножество того что работает в XP. Наиболее сложная часть — работать в парах. По многим причинам. Я собеседовал многих людей. Мало кто признался что может... Так что не надо про рефакторинг поучений — итак все ясно. Просто иногда даже это не работает. Особенно когда нужно тесты рефакторить.
GZ>Ошибки у мега-архитекторов не вылазят. На то они и мега-архитекторы чтобы уметь бороться с рисками.
can_mistake(X):- man(X).
man(megaArchitect).
?- can_mistake(megaArchitect).
Ну это классика...
А ты не архитектор часом?
GZ>Так значит тебе нравится XP?
А я говорил что мне не нравится XP?
L>Хорошо, давайте не будем обсуждать xp, а всего-лишь ответим на вопрос: L>
L>Может ли кто-либо для доказательствава своей правоты приводить в пример то, чего еще не существует?
Отвечаю по вашему вопросу :
когда у людей главное отпиарить свое, агрессивно напав, причем заведомо нечестно,
"отвечать на вопрос" прямо — или бессмысленно,
или помогать заведомо нечестному подходу.
Судя даже по коллективной агрессии, что особенно неприлично — так оно и есть — второе.
Здравствуйте, vgrigor, Вы писали:
V>Укуси еще кого-нибудь.
Ты ошибаешься, я никого не хочу кусать. Всего лишь хочется понять логику твоих рассуждений. Но, как оказывается, это сделать очень непросто, т.к. на вопросы, единственным ответом на которые можеть быть да или нет, ты не отвечаешь или начинаешь рассказывать про свое тяжелое общежитско-автобусное прошлое.
Интересно, а для какой корысти необходимо в RUP плодить столько артефактов (одних диаграмм скока напридумали там чертить )? Йих потом еще надо все время синхронизировать с кодом...
Здравствуйте, hugo, Вы писали:
H>Интересно, а для какой корысти необходимо в RUP плодить столько артефактов (одних диаграмм скока напридумали там чертить )? Йих потом еще надо все время синхронизировать с кодом...
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, hugo, Вы писали:
H>>Интересно, а для какой корысти необходимо в RUP плодить столько артефактов (одних диаграмм скока напридумали там чертить )? Йих потом еще надо все время синхронизировать с кодом...
L>RUP не обязывает плодить все возможные артафакты.
Нет, не обязывает, но очень поощряет. Если заглянуть в книгу по RUP, например, в "Унифицированный процесс разработки..." А.Якобсока, Г.Бача..., то становится понятно, что вся эта масса диаграмм дается не случайно.
Здравствуйте, DaBro, Вы писали:
GZ>>Для того, чтобы понять что автор говорит, нужно понять что такое XP. XP — это выстроенная система в которой практики взаимосвязанны.Когда ты это поймешь и поймешь почему это так, ты поймешь и о чем пишет автор. DB>Не вижу ответа на вопрос. Я уже давно не могу понять что такое XP
Достаточно строгий процесс разработки эффективный при небольших проектах, при которых задействовано небольшое количество разработчиков.
DB>>>У меня сейчас проблема есть — приложение с ~1K unit tests. GZ>>1 кил? DB>Да 784 если быть точным. Например, сейчас 50 кил кода и около 1 мега эталонов (правда я их генерил с унаследованной системы), для сервера с очень ограниченной функциональности.
GZ>>Первое, покрытие на 100 процентов не бывает, или бывает в очень простых случаях. Во вторых, тесты нужны в XP, не просто так. Они нужны для автоматизации рефакторинга. А рефакторинг нужен тоже не просто так. А он нужен чтобы поддерживать эволюцию проекта в системе коротких итераций. А эволюция проекта не просто так делается, а за счет нее убирается время на сбор и анализ требований(а это иногда до 2/3 времени проекта). А генерацию требований не отменишь, если у тебя не будет заказчика под боком. Все взаимосвязанно. Что-то выбьешь, ничего не получишь.
DB>А третье — методологии названные agile пытаються позаимствовать хотябы подмножество того что работает в XP.
Собственно agile(и его манифест) и была создана икспишниками. Просто под этим термином они объединили адаптивные методы построения приложений. А процессов Agile до фигищи. Например, Agile UP. Реформированный адаптивный RUP.
DB>Наиболее сложная часть — работать в парах. По многим причинам. Я собеседовал многих людей. Мало кто признался что может... Так что не надо про рефакторинг поучений — итак все ясно.
И что? Они пробовали? Я пробовал, скажу сразу, смысл есть. Достаточно эффективно как в плане процесса разработки, так и в плане обучения новичков.
DB>Просто иногда даже это не работает. Особенно когда нужно тесты рефакторить.
Да что ты так привязался к тестам. У меня есть сервер, который по независищим от нас причинам(некоторые компоненты писались не нами), глючен, и должен адаптироваться к конкретной базе данных. На него написаны функциональные тесты. Тесты вызывают функции сервера, и сравнивают их с эталонами(xml файлы). Поскольку базы данных разные, то для каждой базы данных готовится свои эталоны. И как результат, мы можем всегда сказать что сервер для конкретной базы данных работает. И никто о рефакторинге тестов даже и не заикается. Вполне конкретно и универсально сделано.
GZ>>Ошибки у мега-архитекторов не вылазят. На то они и мега-архитекторы чтобы уметь бороться с рисками.
if IsMegaArchitect(Iam){
if IveNeverDoneThis()
{
if !(Solutions=LookingAnotherSimilarTask())
ManyThinking(Solutions)
RealSolution=TestSolutionForNonfunctionRequariments(Solutions)
}
else
RealSolution=MakedTask();
}else RealSolution=MakeTaskAndWillLookWhatHappened();
Ошибки в основном бывают только по неопытности архитекторов, или неопытности менеджеров.
DB>А ты не архитектор часом?
А я на все руки мастер.
GZ>>Так значит тебе нравится XP? DB>А я говорил что мне не нравится XP?
Ты предьявил требования, как будто списанные со слов апологетов XP. Именно на эти вещи(ну правда еще на некоторые) они нажимают рекламируя себя.
Здравствуйте, vgrigor, Вы писали:
GZ>>На то они и паттерны, чтобы давать направление а привязку к местности делать самостоятельно. V>Если есть что привязывать, но нет такого ощущения то есть такие вещи там.
Вполне есть. Нужно просто абстрагироваться от кода и смотреть на идеи.
V>А я вот помню микрософт одну выдумал DNA, работающую, на 5 лет. V>И больше не было.
Они и не скрывали. Когда выходил NT4 оказалось что он плохо клеится к mainframe'ам которых было тогда множество. Собственно именно для этого и была сделана эта времянка. Потом ее уже вытеснили стабильные решения. V>А Java — J2EE.
Вообще-то оно живо. Не замечал что серваки рекламируются с лейблом что совместимы с J2EE.
V>Кроме SOA можете вспомнить еще такого, выделенного типа арзитектур, названия ?
SOA — это больше лейбл чем архитектура. Ну а остального до фигищи. Начиная от системы реального времени, игры, небольшие решения для конкретной задачи. Ocasionally connected решения. Интеграционные решения(которые не обязательно SOA). В общем до фигищи есть, и до фигищи можно придумать а главное квалифицировать.
GZ>>Да не может быть ощущения работоспособности от неполного набора паттернов по концептуальной архитектуре. Код там, только для того чтобы примерно описать паттерн. А от концепции к реализации очень долгий путь. Это не книга программиста или проектировщика. Это книга архитектора. V>Да долгий, зато он мастер, или не мастер, V>чтобы опробировать пути, пройти заметнную практическую часть, V>и дать нам за наши деннежки ? V>Или только тоже добрые слова, хотя так крут? V>Не крут.
Это был вопрос или утверждение.
V>Это да, 3 года назад — это было неплохо, а особенно 6, V>а теперь это общеизвестные вещи, инкапсулированные в библиотеки. V>А фаулер — только наметки, V>на сейчас сделанное. V>Маразм да?
Ага. Каждую библиотеку в которую инкапсулирована данная функциональность нужно адаптировать под свое решения. А для этого, все таки надо знать как она работает.
V>Славься Фаулер! Славься Фаулер! V>Ура народному герою Фаулеру, товарищи!
V>К примеру: классифиировал он ОРМ, но вместо указаний на правильные организации, архитектуру V>он просто сказал — что де это круто для детей, довольствуйтесь классификацией. V>(от базы, от обьектов, и смешанное что-то).
Да уж. Это не самая сильная сторона книги. В основном она писалась с учетом опыта на Java. А тут подкинули нетовского ублюдка DataSet. Только все что описано для данного паттерна, все верно. IMHO И график зависимости от сложности проекта — верный.
Здравствуйте, GlebZ, Вы писали:
DB>>Не вижу ответа на вопрос. Я уже давно не могу понять что такое XP GZ>Достаточно строгий процесс разработки эффективный при небольших проектах, при которых задействовано небольшое количество разработчиков.
Но при этом не обязательно неэффективный для больших проектов.
Здравствуйте, kochmin_alexandr, Вы писали:
_>Т.е. например для тестирования приложения, работающего с базой данных, просто отключаем слой работы непосредственно с базой, и заменяем его слоем — заглушкой, который будет эмулировать слой работы с базой, но сливать все в лог, или выдавать данные согласно плану тестирования. _>Аналогично для других слоев.
Как поступить аналогично для слоя работы с БД???
Вот тут Ф и все остальные обычно молчат, типа как а может никто об этом и не задумается
Слой-то тоже довольно увесистый и важный обычно...
Здравствуйте, DaBro, Вы писали:
DB>Коллеги, а не закрадывлось ли у вас осчусЧения что буржуйский товарисчи (Фаулер, Бэк) и иже с ними вводят в заблуждение нашего брата.
Пролистывая на днях Фаулерувскую "Архитектуру корпоративных программных приложений", наткнулся на следующее лирическое отступление:
Я полностью отдаю себе отчет в ограниченности своих рекомендаций. Фродо, один из персонажей киноленты "Властелин колец", помнится, как-то произнес: "Не ходите к эльфам за советом — они все равно не скажут ни да, ни нет". Я ни в коем случае не утверждаю, что владею бессмертным трансцендентным знанием, и ясно понимаю, что любое слово может нести в себе опасность. Если вы обратились к этой книге в надежде, что она поможет предпринять верные шаги для реализации конкретного проекта, должен заметить, что вы осведомлены о своих нуждах намного лучше, чем я. Должен признаться, мне приходится испытывать чувство глубокого разочарования каждый раз, когда на конференциях или по электронной почте ко мне, "ученому мужу", обращаются за консультациями по поводу конкретных архитектурных или функциональных решений, а я за пять минут не в состоянии сказать ничего вразумительного.
...
Пользуйтесь материалом как подспорьем, но не воспринимайте его как готовую истину, наличие которой исключает потребность в творческом поиске. В конце концов, вам самому принимать решения и мириться с их результатами.
Здравствуйте, DaBro, Вы писали:
DB>У меня сейчас проблема есть — приложение с ~1K unit tests. И там изначально понятно был что файлами то не обойтись. И вот тут поодержка тестов начинает занимать 50% времени. А самое забавное что тесты рефакторяться иногда чаще чем рабочий код. Потому что борьба со сложностью. И нет гарантии что тесты остаються корректными — никто не застрахован. Не скажу что без них было бы проще, но с базой, и системами кэша такое вытворять приходится... И ведь надо чтоб хотябы минут за 10 все выполнялось (как раз перекур устроить можно ). К тому же и заказчик поторапливает.
Да, поддержка тестов может занимать весьма заметное время. Но есть два нюанса:
1) Потратив время на поддержку тестов, вы почти польностью уверены, что изменения кода работают. Если же не тратить время на поддержку тестов.. шут его знает, где изменение кода случайно отзовётся. 1к тестов, он ведь не просто так возник, а наверное, от того, что программа не совсем тривиальная
2) Необходимость поддерживать тесты, неплохо стимулирует писать код с малым количеством dependencies. Чем больше dependencies, тем сложнее поддерживать тесты
DB>А Кент и Мартин знай себе повторяют — главное чтобы быстро и покрытие 100%. Может они только примеры к книгам пишут?
Вы знаете, мне лично Кент говорил, что 100% покрытие бывает вредно и неоправдано. Именно потому, что некоторые части кода (тот же GUI) может быть проще и дешевле проверять живым тестером. Чем больше покрытие юнит-тестами, тем лучше. Но если некоторые тесты требуют чрезмерных усилий по написанию и поддержке.. ну так, может, именно там их и не всегда стоит применять. Тесты — они ведь для повышения качества (читай: удешевления разработки через качество), а не наоборот.
На юнит-тестах у agile-истов свет клином не сходится. Обычно, большинство тестов — действительно юнит-тесты. Но есть и должны быть ещё и функциональные, и системные. Если их можно автоматизоровать за приемлемые деньги — хорошо. Если нельзя, то нельзя.
В общем, XP (как и любой другой agile-метод) — это о принципах и здравом смысле, а не о наборе догматических правил (тоже, почти дослованя цитата Бека)
Я ее первый раз в русской редакции прочитал. Особо много нового не узнал, но зато несколько упорядочил.
Была одна проблема — "клинило" на некоторых фрагментах. Думал у меня проблемы — оказалось нет. Взял английскую версию и где в русской были непонятки — поднимал первоисточник. Вывод — переводил пьяный бешеный бобер.
Для адекватного понимания "Архитектуры" иметь под рукой первоисточник просто необходимо. А еще лучше только английскую и читать.
Я свой русский экземпляр книги шваркнул в сердцах об стенку, т.к. задолбался переводить с русского на вменяемый. Ползуюсь теперь только оригинальной.
). К тому же и заказчик поторапливает. А Кент и Мартин знай себе повторяют — главное чтобы быстро и покрытие 100%. Может они только примеры к книгам пишут? 
)? Йих потом еще надо все время синхронизировать с кодом...
