Здравствуйте, 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%. Может они только примеры к книгам пишут? 
)? Йих потом еще надо все время синхронизировать с кодом...
