Здравствуйте, C...R...a...S...H, Вы писали:
BG>>Это не ошибка разработчиков, это ошибка архитекторов проекта. В частности неправильно составленные требования к high-volume traffic pages. Вы, наверняка, согласитесь, что в любой аппликухе есть куски, которые используются часто, и есть куски, что используются редко. На "редких" кусках можно оставить Button_OnClick() схему обработки, ценой дешевого пост-бека и пары кил вью стейта. "Частые" куски, стоит оптимизировать, тут спорить не о чем. CRA>Наверное, вы считаете, что отличный выход в системе применять два решения. Не думаю что с точки зрения поддержки это будет выглядеть хорошо.
Я считаю, что вопросы поддержки вторичны по отношению к вопросам разработки стабильной и быстрой системы.
CRA>А в чем недовольство event based моделью? Можно услышать конкретные проблемы?
Синклер привел очень хороший пример — постбек на high-volume странице, приводить еще пару — просто лень печатать. Теоретически это просто попытка привести модель из WindowsForms в веб аппликейшн, и тут как и положительные аргументы так и отрицательные: все выглядит одинаково (это хорошо), но плохо ложится на низкоуровневые протоколы (это не очень хорошо). Внутри — windows forms базируются на message queue, а веб базируется на request-response схеме. Эвенты (как паттерн ленивого вызова) тут не самая красивая аналогия, но, как я уже говорил, — этот мир полон компромиссов.
CRA>Может быть их можно решить без перехода на MVC BG>>На MVC будем посмотреть однозначно, счас как раз пишу песочницу на asp.net 3.5 с linq, надо будет ее туда включить. У меня просто есть некоторое недоверие ко всему, что называется MVC CRA>Странно, с чего у вас такое?
— What is Gigashadow?
— Gigashadow is the end and it is the beginning.
MVC черезчур распространенное сочетание, и счас им называют все что угодно. Да, конечно, это паттерн отделения презентации от данных bla-bla-bla, но мне хочется сказать "хоть горшком назови, только в печку не суй".
Здравствуйте, B0rG, Вы писали:
BG>Гы, правильные вопросы задаете, товарищ (с) BG>Беда в том, что у меня нет на них правильных ответов.
У меня есть. "не нужно искать злой умысел там, где для объяснения довольно глупости" BG>Расскажу вам лучше байку с одного из моих последних интервью в HP Financial Services: сидим базарим с проджект мэном и арком за жизнь и архитектуру. Попутно я бросаю фразу о том, что все производство софта суть набор компромиссов и начинаем за здравие, кончаем за упокой. Чем дольше лайфсайкл тем больше компромиссов. Завершаю фразой: как бы я хотел работал над проектом с самого начала в толковой группе, с правильно построенной архитектурой и т.д... Оба собеседника в один голос: если найдешь такой проект обязательно позвони нам
BG>В общем, честно говоря, я не знаю "почему нельзя сделать сразу по уму". Народ почему то не делает.
Народ как правило применяет то, к чему приучен.
ASP.NET 1.0 был катастрофической вещью. Штука, которая по умолчанию делает максимально плохие решения, воспитала целое поколение людей с травмированным здравым смыслом.
К счастью, хотя бы 3.5 подает надежды на лучшее. BG>Но меня это вполне устраивает: я могу прийти, посмотреть на проект, и сказать "за 6 месяцев мы это релизим, мне нужно a, b и с". И мы релизим за 5 + месяц на поддержку и кое-какую оптимизацию, а потом я иду в другую контору
"порулил — и убегай"?
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, B0rG, Вы писали:
BG>Здравствуйте, C...R...a...S...H, Вы писали:
BG>>>Это не ошибка разработчиков, это ошибка архитекторов проекта. В частности неправильно составленные требования к high-volume traffic pages. Вы, наверняка, согласитесь, что в любой аппликухе есть куски, которые используются часто, и есть куски, что используются редко. На "редких" кусках можно оставить Button_OnClick() схему обработки, ценой дешевого пост-бека и пары кил вью стейта. "Частые" куски, стоит оптимизировать, тут спорить не о чем. CRA>>Наверное, вы считаете, что отличный выход в системе применять два решения. Не думаю что с точки зрения поддержки это будет выглядеть хорошо.
BG>Я считаю, что вопросы поддержки вторичны по отношению к вопросам разработки стабильной и быстрой системы.
Во во.
В итоге получается система которая называется "Нетрож, а то рванет".
Ведь, для больших систем, стоимость разработки гораздо меньше чем стоимость поддержки.
CRA>>А в чем недовольство event based моделью? Можно услышать конкретные проблемы?
BG>Синклер привел очень хороший пример — постбек на high-volume странице, приводить еще пару — просто лень печатать. Теоретически это просто попытка привести модель из WindowsForms в веб аппликейшн, и тут как и положительные аргументы так и отрицательные: все выглядит одинаково (это хорошо), но плохо ложится на низкоуровневые протоколы (это не очень хорошо). Внутри — windows forms базируются на message queue, а веб базируется на request-response схеме. Эвенты (как паттерн ленивого вызова) тут не самая красивая аналогия, но, как я уже говорил, — этот мир полон компромиссов.
Поясните пожалуйста пример про постбек на high-volume странице.
Я не могу уловить суть проблемы.
CRA>>Может быть их можно решить без перехода на MVC BG>>>На MVC будем посмотреть однозначно, счас как раз пишу песочницу на asp.net 3.5 с linq, надо будет ее туда включить. У меня просто есть некоторое недоверие ко всему, что называется MVC CRA>>Странно, с чего у вас такое?
BG>- What is Gigashadow? BG>- Gigashadow is the end and it is the beginning.
BG>MVC черезчур распространенное сочетание, и счас им называют все что угодно. Да, конечно, это паттерн отделения презентации от данных bla-bla-bla, но мне хочется сказать "хоть горшком назови, только в печку не суй".
SOA тоже распространенное сочетание, и что?
Здравствуйте, Sinclair, Вы писали:
BG>>Гы, правильные вопросы задаете, товарищ (с) BG>>Беда в том, что у меня нет на них правильных ответов. S>У меня есть. "не нужно искать злой умысел там, где для объяснения довольно глупости"
К сожалению все не так просто. Я избегаю обвинять коллег в глупости
BG>>В общем, честно говоря, я не знаю "почему нельзя сделать сразу по уму". Народ почему то не делает. S>Народ как правило применяет то, к чему приучен. S>ASP.NET 1.0 был катастрофической вещью. Штука, которая по умолчанию делает максимально плохие решения, воспитала целое поколение людей с травмированным здравым смыслом. S>К счастью, хотя бы 3.5 подает надежды на лучшее.
Я делал только asp.net 2.0, с 1.1 игрался — у меня есть свой MVC framework с xml+xslt, и ручным процессором query string, но потом просто достало переписывать под него контроли, да и ajax на него не сильно хорошо ложится.
BG>>Но меня это вполне устраивает: я могу прийти, посмотреть на проект, и сказать "за 6 месяцев мы это релизим, мне нужно a, b и с". И мы релизим за 5 + месяц на поддержку и кое-какую оптимизацию, а потом я иду в другую контору S>"порулил — и убегай"?
Тут бизнес тоже можно понять. Я стою в три-четыре раза больше среднего джуниора, и бизнес считает, что проще нанять трех джуниоров. После года работы, бизнесу становится понятно, что все таки нужен сеньор, т.к. сроки просрочены, проект разваливается на части, все недовольны, ну и т.д. После того как проект сдан острая необходимость во мне отпадает, и я нахожу другой контракт.
Здравствуйте, C...R...a...S...H, Вы писали:
BG>>Я считаю, что вопросы поддержки вторичны по отношению к вопросам разработки стабильной и быстрой системы. CRA>Во во. CRA>В итоге получается система которая называется "Нетрож, а то рванет". CRA>Ведь, для больших систем, стоимость разработки гораздо меньше чем стоимость поддержки.
при нормальном применении defensive programming, логгинга и хорошем покрытии кода юнит тестами, поддержка сильно облегчается.
Для больших систем... Возьмем, например, бизнес логику мобильного телекома с дневным прогоном бабла порядка 2 млн е через систему, разработка и тестинг (по времени в 2 раза большим чем собственно девелопмент) стоила очень много, тогда как поддержка стоила в разы меньше. Поверьте мне на слово, я там арком работал, и стабильность системы была одной из моих прямых обязанностей.
BG>>Синклер привел очень хороший пример — постбек на high-volume странице, приводить еще пару — просто лень печатать. Теоретически это просто попытка привести модель из WindowsForms в веб аппликейшн, и тут как и положительные аргументы так и отрицательные: все выглядит одинаково (это хорошо), но плохо ложится на низкоуровневые протоколы (это не очень хорошо). Внутри — windows forms базируются на message queue, а веб базируется на request-response схеме. Эвенты (как паттерн ленивого вызова) тут не самая красивая аналогия, но, как я уже говорил, — этот мир полон компромиссов. CRA>Поясните пожалуйста пример про постбек на high-volume странице. CRA>Я не могу уловить суть проблемы.
Лень писать одно и тоже. У вас страница с 1 000 000 уникальных клиенстких хитов в день, как вы ее будете делать: с Button_OnClick или же по формату http://myserver/mypage.aspx?ItemID={id}, второй формат будет побыстрее, т.к. не надо грузить родителя Button_OnClick, и юзеры могут ставить ссылки на страницу.
BG>>MVC черезчур распространенное сочетание, и счас им называют все что угодно. Да, конечно, это паттерн отделения презентации от данных bla-bla-bla, но мне хочется сказать "хоть горшком назови, только в печку не суй". CRA> SOA тоже распространенное сочетание, и что?
Такое же бредовое.
Я когда в первый раз услышал словосочетание Software Factories мне тут же представилась большая полутемная комната с тысячью китайцев в кубиклах корпеющих над очередной реализацией Service Oriented Architecture. Я ужаснулся
BG>при нормальном применении defensive programming, логгинга и хорошем покрытии кода юнит тестами, поддержка сильно облегчается.
BG>Для больших систем... Возьмем, например, бизнес логику мобильного телекома с дневным прогоном бабла порядка 2 млн е через систему, разработка и тестинг (по времени в 2 раза большим чем собственно девелопмент) стоила очень много, тогда как поддержка стоила в разы меньше. Поверьте мне на слово, я там арком работал, и стабильность системы была одной из моих прямых обязанностей.
смотря что вкладывать в слово поддержка.
Вы видимо вкладываете в это слово такое поняние:
Система прошал CAT её установили на продакшен и посадили студента фиксить баги.
А я вкладываю в это доработку системы, добавление нового функианала, изменение бизнес правил и т.д.
А для системы в которой используется 2-3 подхода к архитектуре и code style, такие доработки многого стоят.
Хотя всегда есть вариант сказать: "шо за система, хто писал, срочно переписать..."
CRA>>Поясните пожалуйста пример про постбек на high-volume странице. CRA>>Я не могу уловить суть проблемы.
BG>Лень писать одно и тоже. У вас страница с 1 000 000 уникальных клиенстких хитов в день, как вы ее будете делать: с Button_OnClick или же по формату http://myserver/mypage.aspx?ItemID={id}, второй формат будет побыстрее, т.к. не надо грузить родителя Button_OnClick, и юзеры могут ставить ссылки на страницу.
Мне кажется вы в данном примере бросаетесь в крайности.
Как сейчас помню ASP.NET одностраничные порталы...
С другой стороны:
Button_OnClick
{
redirect("")
}
BG>>>MVC черезчур распространенное сочетание, и счас им называют все что угодно. Да, конечно, это паттерн отделения презентации от данных bla-bla-bla, но мне хочется сказать "хоть горшком назови, только в печку не суй". CRA>> SOA тоже распространенное сочетание, и что?
BG>Такое же бредовое.
BG>Я когда в первый раз услышал словосочетание Software Factories мне тут же представилась большая полутемная комната с тысячью китайцев в кубиклах корпеющих над очередной реализацией Service Oriented Architecture. Я ужаснулся
Боюсь даже спросить, выши мысли о Design pattens
Здравствуйте, C...R...a...S...H, Вы писали:
CRA>смотря что вкладывать в слово поддержка. CRA>Вы видимо вкладываете в это слово такое поняние:
Я так и не понял, как из фразы о том, что "вопросы поддержки вторичны по отношению к вопросам разработки" вы вытянули это, ну да ладно.
CRA>Система прошал CAT её установили на продакшен и посадили студента фиксить баги. CRA>А я вкладываю в это доработку системы, добавление нового функианала, изменение бизнес правил и т.д. CRA>А для системы в которой используется 2-3 подхода к архитектуре и code style, такие доработки многого стоят. Хотя всегда есть вариант сказать: "шо за система, хто писал, срочно переписать..."
Системы бывают разные, зеленые и красные. Различные архитектурные подходы, направленные на решение определенных задач, имеют приоритет по отношению к вопросам поддержки и развития системы.
Да, блин, это все на самом деле, спор о сферических конях в вакууме. Т.е. суета и томление духа. Объясню:
В ответ на мой тезис, что архитектурной целостностью системы можно пренебречь ради решения проблем оптимизации, вы стали возражать, что "нарушение архитектурной целостности усложняет поддержку", на этот момент я потерял интерес к этому спору и сказал "вопросы поддержки вторичны".
Вы хотите поспорить дальше, видимо, из тех же самых причин, по которым поддержка пытается оказать влияние на архитектуру. Для вас этот спор полезен: т.к. дает вам возможность найти аргументы на тезисы противоположной стороны, для меня же он абсолютно бесполезен, потому как общего решения таких вопросов не существует, и каждый надо решать по отдельности, исходя из имеющихся развед данных и ресурсов проекта, а это разговор долгий и сферическими конями тут не обойтись.
CRA>Мне кажется вы в данном примере бросаетесь в крайности. CRA>Как сейчас помню ASP.NET одностраничные порталы...
Мы с Синклером переломали уже добрую пару сотен копий, споря о целесообразности таких подходов. А после драки кулаками не машут.
CRA>Боюсь даже спросить, выши мысли о Design pattens
Да нормально почему нет, я стибусь только потому, что развелось слишком много архитектурных астронавтов, которые код писать не умеют, но зато умеют красиво говорить о паттернах, soa, orm и прочих фреймворках. Может это только в Ирландии, может быть в России ситуация иная, я не знаю чесслово.
Здравствуйте, B0rG, Вы писали:
BG>Здравствуйте, C...R...a...S...H, Вы писали:
CRA>>смотря что вкладывать в слово поддержка. CRA>>Вы видимо вкладываете в это слово такое поняние:
BG>Я так и не понял, как из фразы о том, что "вопросы поддержки вторичны по отношению к вопросам разработки" вы вытянули это, ну да ладно.
Я вывел это из вашего утверждения, что ваш опыт показывает, что процесс разработки системы дороже, чем процесс ее поддержки.
Если это не так, то извиняюсь
BG>Системы бывают разные, зеленые и красные. Различные архитектурные подходы, направленные на решение определенных задач, имеют приоритет по отношению к вопросам поддержки и развития системы.
BG>Да, блин, это все на самом деле, спор о сферических конях в вакууме. Т.е. суета и томление духа. Объясню:
BG>В ответ на мой тезис, что архитектурной целостностью системы можно пренебречь ради решения проблем оптимизации, вы стали возражать, что "нарушение архитектурной целостности усложняет поддержку", на этот момент я потерял интерес к этому спору и сказал "вопросы поддержки вторичны".
BG>Вы хотите поспорить дальше, видимо, из тех же самых причин, по которым поддержка пытается оказать влияние на архитектуру. Для вас этот спор полезен: т.к. дает вам возможность найти аргументы на тезисы противоположной стороны, для меня же он абсолютно бесполезен, потому как общего решения таких вопросов не существует, и каждый надо решать по отдельности, исходя из имеющихся развед данных и ресурсов проекта, а это разговор долгий и сферическими конями тут не обойтись.
Может быть вы и правы, но основным стимулом, сподвигшим меня на этот спор, было — узнать, что за контекст мог повлиять на решение использовать несколько архитектур в одном проекте.
Я еще не встречал проблем, решение которых требовало введение нескольких архитектур.
Здравствуйте, C...R...a...S...H, Вы писали:
CRA>Я вывел это из вашего утверждения, что ваш опыт показывает, что процесс разработки системы дороже, чем процесс ее поддержки. CRA>Если это не так, то извиняюсь
Там немного по другому:
система разрабатывается релизами, поддержка идет параллельным процессом, но не привязана к релиз циклу: критические фиксы, баг фиксы и т.д. делаются малой кровью команды app support. У app support есть magic power идти сразу в систем тест и деплоить в течении недели. Все остальные сначала идут в integration test, потом в system test в течении 2 месяцев. Все большие изменения цепляются исключительно к релизу, иначе просто нельзя ввиду большого regression test.
В app support систему сторожит набор слабых инженеров — их задача только в том что бы зафиксировать проблему, быстро что-то починить, и передать это аркам. Арки оценивают стоимость фикса и если фикс короткий, он отправляется в маленькую команду app support dev — очень сильные и ответственные инженеры, прекрасно знающие систему. Если фикс длинный он отдается команде, которая отвечает за этот или близкий модуль в данном релизе.
Так же у арков есть обязанность проверки архитектуры релизов на совместимость с продакшеном.
Это во взрослых конторах.
В детском саду все по другому: проджект тим, тестер и дба если повезет. Система релизов по фазам (часто между фазами проджект тим меняется), в поддержку отправляется самый слабый член команды, потому как за время проекта инженеры устают как от проекта, так и от клиента. Всем хочется новизны, и народ используют весь свой вес (кто во что горазд), что бы перескочить на другой проект, и проекты с нуля тут ценятся больше всего. У джуниора веса как правило нет, и он остается на поддержке
Сами понимаете, что в любом из вариантов вопросы поддержки вторичны Полезное качество для хорошего тимлида — уметь узнавать такие ситуации и знать как с ними бороться. Если при этом он еще сможет сохранить команду, то ему всеобщий почет и уважение.
С точки зрения сферического софта в вакууме такие подходы очень плохие, конечно, но жизнь вносит свои коррективы.
CRA>Может быть вы и правы, но основным стимулом, сподвигшим меня на этот спор, было — узнать, что за контекст мог повлиять на решение использовать несколько архитектур в одном проекте. CRA>Я еще не встречал проблем, решение которых требовало введение нескольких архитектур.
Здравствуйте, B0rG, Вы писали:
BG>Здравствуйте, C...R...a...S...H, Вы писали:
CRA>>Я вывел это из вашего утверждения, что ваш опыт показывает, что процесс разработки системы дороже, чем процесс ее поддержки. CRA>>Если это не так, то извиняюсь
BG>Там немного по другому: BG>система разрабатывается релизами, поддержка идет параллельным процессом, но не привязана к релиз циклу: критические фиксы, баг фиксы и т.д. делаются малой кровью команды app support. У app support есть magic power идти сразу в систем тест и деплоить в течении недели. Все остальные сначала идут в integration test, потом в system test в течении 2 месяцев. Все большие изменения цепляются исключительно к релизу, иначе просто нельзя ввиду большого regression test.
BG>В app support систему сторожит набор слабых инженеров — их задача только в том что бы зафиксировать проблему, быстро что-то починить, и передать это аркам. Арки оценивают стоимость фикса и если фикс короткий, он отправляется в маленькую команду app support dev — очень сильные и ответственные инженеры, прекрасно знающие систему. Если фикс длинный он отдается команде, которая отвечает за этот или близкий модуль в данном релизе.
BG>Так же у арков есть обязанность проверки архитектуры релизов на совместимость с продакшеном.
BG>Это во взрослых конторах.
Так вот я получается что поддержка обходится дороже чем создание системы.
А если система еще написана через одно место, то вообще исправление дефекта в одном месте убивает систему в другом.
Хочу заметить одно:
Все что вы написали ни коим образом не сходится с тем что вы писали ранее (сделали систему, установили, и побежали дальше...)
Сейчас по вашим словал систему поддерживают не просто пара программеров, а:
*Пара программеров
*Арки
*Апп сапортеры
Предположу, что этим хозяйством еще ПМ рулит.
Так тогда, что вы говорили по поводу того, что разработка дороже поддержки?
BG>В детском саду все по другому: проджект тим, тестер и дба если повезет. Система релизов по фазам (часто между фазами проджект тим меняется), в поддержку отправляется самый слабый член команды, потому как за время проекта инженеры устают как от проекта, так и от клиента. Всем хочется новизны, и народ используют весь свой вес (кто во что горазд), что бы перескочить на другой проект, и проекты с нуля тут ценятся больше всего. У джуниора веса как правило нет, и он остается на поддержке
Интересно, но есть одна проблема, которая отличает два представленных способа вести проект:
При первом способе во вселенной существуют сильные программеры которым нравиться сапорт (мне кажется это фантастика )
А вот во втором случае таких программеров не существует.
BG>Сами понимаете, что в любом из вариантов вопросы поддержки вторичны Полезное качество для хорошего тимлида — уметь узнавать такие ситуации и знать как с ними бороться. Если при этом он еще сможет сохранить команду, то ему всеобщий почет и уважение.
Так вот и получается что своими решениями добавить парачку архитектурных решения в один проект, вы закапываете всю каманду, потому что проект превращается, превращается проект в жуткого монстра, который содержит в себе несколько архитектурных решений аля:
Половина объектов домена использует Lazy load, а другая половине нет.
И народ, который сам же и писал эту систему уже не в силах что то поменять, и поэтому уходит в другие проекты.
BG>С точки зрения сферического софта в вакууме такие подходы очень плохие, конечно, но жизнь вносит свои коррективы.
CRA>>Может быть вы и правы, но основным стимулом, сподвигшим меня на этот спор, было — узнать, что за контекст мог повлиять на решение использовать несколько архитектур в одном проекте. CRA>>Я еще не встречал проблем, решение которых требовало введение нескольких архитектур.
BG>Вам повезло У меня они каждый день
ООООО...
Отлично!!!
Я затеял этот спор только для того, что бы узнать хоть парачку таких проблем.
Поделитесь пожалуйста.
Здравствуйте, C...R...a...S...H, Вы писали:
CRA>Так тогда, что вы говорили по поводу того, что разработка дороже поддержки?
потому что я не упомянул еще 10-20 релиз проджект тимов в каждой в среднем по 10 — 15 человек, которые занимаются собственно разработкой функциональности релиза. Затраты на саппорт на фоне затрат на проджект команды и тест команды в релизе, ничтожны.
Что до разных методов, то я работал в разных компаниях и смотрел по сторонам. Во взрослых конторах стабильность и качество системы как правило имеет приоритет. В детских садах, приоритет имеют сроки. То, что я называю Customer Driven Testing, т.е. мы фиксим только те баги, которые находит кастомер. Это не смешно, конечно же, но тем не менее — реальность.
CRA>При первом способе во вселенной существуют сильные программеры которым нравиться сапорт (мне кажется это фантастика ) А вот во втором случае таких программеров не существует.
Никто не говорил, что им нравится саппорт У них другие бенефиты.
CRA>Так вот и получается что своими решениями добавить парачку архитектурных решения в один проект, вы закапываете всю каманду, потому что проект превращается, превращается проект в жуткого монстра, который содержит в себе несколько архитектурных решений аля: CRA>Половина объектов домена использует Lazy load, а другая половине нет. CRA>И народ, который сам же и писал эту систему уже не в силах что то поменять, и поэтому уходит в другие проекты.
Я не считаю это большим грехом. Статические данные вплоне могут грузиться как и ленивым способом так и "все сразу". Конечно, было бы хорошо, если бы грузились одинаковым, но на некотором этапе развития системы это уже не возможно. Называется organic growth.
CRA>Отлично!!! CRA>Я затеял этот спор только для того, что бы узнать хоть парачку таких проблем. CRA>Поделитесь пожалуйста.
Я подписываю NDA, который в частности запрещает мне обсуждать детали архитектуры. А проблемы когда текущая архитектура сильно усложняет процесс, кроются как раз в этих самых деталях.
Хотя ладно: имеем модную архитектуру с nettiers orm, enterprise library, infragistics controls. Административный запрет на прямой доступ к базе. Во время первого бета релиза клиенту выясняется, что
1) при 5000+ записей в основных словарях (девелоперы использовали не больше трех записей типа Клиенты, Юзера, Продукты), все списки начинают тормозить, отжирая порядка 700 метров после 5 кликов на юае, да и грузяться порядка 100 секунд.
2) при загрузке реальных продуктов (там 4 поля типа текст, полный вес объекта может превышать 8 метров) выяснилось, что на клиента отправляется порядка 10 мегабайт viewState, потому что кто-то очень умный сохраняет этот объект во вью стейт.
Решения:
1)
* профайлером было обнаружено, что infragistics очень любит GetHashCode() метод, который оверлоадиться в энтитях в формате:
GetHashCode() { return property1.ToString + property2.ToString + ... }
Поменяли.
* Для генерации списков nettiers генерит специальные классы типа WebControls, нечитабельные совершенно, к тому же не поддерживающие ничего кроме IEnumerable()
После долгих споров я всех убедил это переписать на ObjectDataSource с прямым ad hoc сиквелом стало серьезно быстрее и память больше не текла. Тут можно было бы сделать еще быстрее, но юай использовал Infragistics контроли с очень богатой написанной функциональностью, переписывать которую вручную времени не было.
2) Хакнули через сохранение ViewState на сервере. Это чревато, конечно, но опять же — не было времени.
Плюс под конец с проекта разбежались все девелоперы, остались только мы вдвоем с другим сеньором, в качестве дополнительных ресурсов нам выдали двоих джуниоров, которые не могли даже html таблицу написать (я серьезно) после их работы в аппликухе поехал весь юай.
Как вы и сами понимаете ни я ни мой коллега этот проект видеть больше не хотели
Здравствуйте, B0rG, Вы писали:
BG>Здравствуйте, C...R...a...S...H, Вы писали:
CRA>>Так тогда, что вы говорили по поводу того, что разработка дороже поддержки?
BG>потому что я не упомянул еще 10-20 релиз проджект тимов в каждой в среднем по 10 — 15 человек, которые занимаются собственно разработкой функциональности релиза. Затраты на саппорт на фоне затрат на проджект команды и тест команды в релизе, ничтожны.
ОК.
BG>Что до разных методов, то я работал в разных компаниях и смотрел по сторонам. Во взрослых конторах стабильность и качество системы как правило имеет приоритет. В детских садах, приоритет имеют сроки. То, что я называю Customer Driven Testing, т.е. мы фиксим только те баги, которые находит кастомер. Это не смешно, конечно же, но тем не менее — реальность.
Интересное замечание.
CRA>>При первом способе во вселенной существуют сильные программеры которым нравиться сапорт (мне кажется это фантастика ) А вот во втором случае таких программеров не существует.
BG>Никто не говорил, что им нравится саппорт У них другие бенефиты.
CRA>>Так вот и получается что своими решениями добавить парачку архитектурных решения в один проект, вы закапываете всю каманду, потому что проект превращается, превращается проект в жуткого монстра, который содержит в себе несколько архитектурных решений аля: CRA>>Половина объектов домена использует Lazy load, а другая половине нет. CRA>>И народ, который сам же и писал эту систему уже не в силах что то поменять, и поэтому уходит в другие проекты.
BG>Я не считаю это большим грехом. Статические данные вплоне могут грузиться как и ленивым способом так и "все сразу". Конечно, было бы хорошо, если бы грузились одинаковым, но на некотором этапе развития системы это уже не возможно. Называется organic growth.
Да ладно, это называется кривая арзитектура.
Это как создавать машину и на середине сборки использовать вместо стали дерево, и говорить что мол так дешевле
CRA>>Отлично!!! CRA>>Я затеял этот спор только для того, что бы узнать хоть парачку таких проблем. CRA>>Поделитесь пожалуйста.
BG>Я подписываю NDA, который в частности запрещает мне обсуждать детали архитектуры. А проблемы когда текущая архитектура сильно усложняет процесс, кроются как раз в этих самых деталях.
BG>Хотя ладно: имеем модную архитектуру с nettiers orm, enterprise library, infragistics controls. Административный запрет на прямой доступ к базе. Во время первого бета релиза клиенту выясняется, что BG>1) при 5000+ записей в основных словарях (девелоперы использовали не больше трех записей типа Клиенты, Юзера, Продукты), все списки начинают тормозить, отжирая порядка 700 метров после 5 кликов на юае, да и грузяться порядка 100 секунд.
Думаю что это — _реальный_ дефект архитектуры системы.
Странно, если ваш архитектор до сих пор, не знал что HTML, не особо предназначен для вывода 5000+ элементов пользователю.
К тому же вы хоть и писали про правильный процесс разработки, видимо даже не удосужились провести нагрузочное тестирование
BG>2) при загрузке реальных продуктов (там 4 поля типа текст, полный вес объекта может превышать 8 метров) выяснилось, что на клиента отправляется порядка 10 мегабайт viewState, потому что кто-то очень умный сохраняет этот объект во вью стейт.
Ничего не понятно, что за объект такой.
BG>Решения: BG>1) BG>* профайлером было обнаружено, что infragistics очень любит GetHashCode() метод, который оверлоадиться в энтитях в формате: BG>GetHashCode() { return property1.ToString + property2.ToString + ... } BG>Поменяли.
Странно я всегда думал что возвращаемое значение у GetHashCode() Int32
BG>* Для генерации списков nettiers генерит специальные классы типа WebControls, нечитабельные совершенно, к тому же не поддерживающие ничего кроме IEnumerable() BG>После долгих споров я всех убедил это переписать на ObjectDataSource с прямым ad hoc сиквелом стало серьезно быстрее и память больше не текла. Тут можно было бы сделать еще быстрее, но юай использовал Infragistics контроли с очень богатой написанной функциональностью, переписывать которую вручную времени не было.
Интересно кончено, но по тому что вы написали я ничего не могу сказать конкретного, так как мне лично ничеге не понятно, с nettiers так что умываю руки
BG>2) Хакнули через сохранение ViewState на сервере. Это чревато, конечно, но опять же — не было времени.
Вот вот, а вы говорили что — "В детских садах, приоритет имеют сроки"
BG>Плюс под конец с проекта разбежались все девелоперы, остались только мы вдвоем с другим сеньором, в качестве дополнительных ресурсов нам выдали двоих джуниоров, которые не могли даже html таблицу написать (я серьезно) после их работы в аппликухе поехал весь юай.
Се ля ви
BG>Как вы и сами понимаете ни я ни мой коллега этот проект видеть больше не хотели
Так получается у вас как в детском саду?
Здравствуйте, C...R...a...S...H, Вы писали:
BG>>2) при загрузке реальных продуктов (там 4 поля типа текст, полный вес объекта может превышать 8 метров) выяснилось, что на клиента отправляется порядка 10 мегабайт viewState, потому что кто-то очень умный сохраняет этот объект во вью стейт. CRA>Ничего не понятно, что за объект такой.
обычный Продукт с четырьмя текстовыми описаниями, и прочей лабудой. Беда была в форме его редактирования — InfragisticsTabControl с пятью табами, каждый делал что то интересное. Разработчик решил, что самым лучшим способом передавать продукт между табами, будет ViewState. Это, конечно, работало на ура, т.к. девелоперы не заполняли текстовые поля продукта поэтому вес сериализованного продукта был меньше килобайта, и ни кого не волновал. Как только запихали реальные продукты с реальными описаниями, вес сериализованного Продукта увеличился до 8 метров, и стало немного тяжеловато. Опять же проблема прояснилась когда я из дома на это смотрел — на работе толстый канал чуть ли не 2 мега аплоад, там чуток подтормаживало но не сильно, а вот из дома с моими 384Килобитами, 8 метров аплоада на постбаке было уже существенно.
Проблема была еще в том, что начальные разработчики не придерживались философии: глупый юай, умный бакэнд, поэтому большая часть бизнес логики была запихана прямо в aspx страницы, не самым оптимальным способом. Рефакторить этот код было очень тяжело и в некоторых случаях практически не возможно. На полную перепись формы редактирования ушло бы недели три (спеков нет, тестов нет, нихрена нет), а времени уже практически не оставалось.
BG>>Решения: BG>>1) BG>>* профайлером было обнаружено, что infragistics очень любит GetHashCode() метод, который оверлоадиться в энтитях в формате: BG>>GetHashCode() { return property1.ToString + property2.ToString + ... } BG>>Поменяли. CRA>Странно я всегда думал что возвращаемое значение у GetHashCode() Int32
ну значит таким образом
GetHashCode() {return property1.ToString().GetHashCode() + property2.ToString().GetHashCode() ... }
я уже честно сказать не помню, дело было в сентябре Суть в том, что GetHashCode для ентитей считался как суммарный нашкод всех мемберов (а те в свою очередь тоже могли быть сложными объектами). ToString() там точно был, потому что именно по ToString() я его и нашел в профайлере: у нас 5000 продуктов в базе, на гриде отображается страница в 20 продуктов, а при этом у меня в профайлере 3 000 000 вызовов ToString(). понятное дело WTF?! Переделали, что бы возвращал EntityID, т.к. и продукты и юзера и клиенты имеют primary key, который в общем то и определяет их идентичность.
CRA>Интересно кончено, но по тому что вы написали я ничего не могу сказать конкретного, так как мне лично ничеге не понятно, с nettiers так что умываю руки
Я надеялся, что вам будет понятно, что неттиерс использовать не стоит
BG>>Как вы и сами понимаете ни я ни мой коллега этот проект видеть больше не хотели CRA>Так получается у вас как в детском саду?
В той конторе был деццкий сад, не без этого. В этой конторе не деццкий сад, но архитекрурные проблемы все равно есть.
Здравствуйте, B0rG, Вы писали:
BG>Здравствуйте, C...R...a...S...H, Вы писали:
BG>>>2) при загрузке реальных продуктов (там 4 поля типа текст, полный вес объекта может превышать 8 метров) выяснилось, что на клиента отправляется порядка 10 мегабайт viewState, потому что кто-то очень умный сохраняет этот объект во вью стейт. CRA>>Ничего не понятно, что за объект такой.
BG>обычный Продукт с четырьмя текстовыми описаниями, и прочей лабудой. Беда была в форме его редактирования — InfragisticsTabControl с пятью табами, каждый делал что то интересное. Разработчик решил, что самым лучшим способом передавать продукт между табами, будет ViewState. Это, конечно, работало на ура, т.к. девелоперы не заполняли текстовые поля продукта поэтому вес сериализованного продукта был меньше килобайта, и ни кого не волновал. Как только запихали реальные продукты с реальными описаниями, вес сериализованного Продукта увеличился до 8 метров, и стало немного тяжеловато. Опять же проблема прояснилась когда я из дома на это смотрел — на работе толстый канал чуть ли не 2 мега аплоад, там чуток подтормаживало но не сильно, а вот из дома с моими 384Килобитами, 8 метров аплоада на постбаке было уже существенно.
BG>Проблема была еще в том, что начальные разработчики не придерживались философии: глупый юай, умный бакэнд, поэтому большая часть бизнес логики была запихана прямо в aspx страницы, не самым оптимальным способом. Рефакторить этот код было очень тяжело и в некоторых случаях практически не возможно. На полную перепись формы редактирования ушло бы недели три (спеков нет, тестов нет, нихрена нет), а времени уже практически не оставалось.
Так с этого и надо было начинать, проблема одна — кривая архитектура.
И говорить, что ASP.NET Events model is sucks неправельно!
BG>>>Решения: BG>>>1) BG>>>* профайлером было обнаружено, что infragistics очень любит GetHashCode() метод, который оверлоадиться в энтитях в формате: BG>>>GetHashCode() { return property1.ToString + property2.ToString + ... } BG>>>Поменяли. CRA>>Странно я всегда думал что возвращаемое значение у GetHashCode() Int32
BG>ну значит таким образом BG>GetHashCode() {return property1.ToString().GetHashCode() + property2.ToString().GetHashCode() ... } BG>я уже честно сказать не помню, дело было в сентябре Суть в том, что GetHashCode для ентитей считался как суммарный нашкод всех мемберов (а те в свою очередь тоже могли быть сложными объектами). ToString() там точно был, потому что именно по ToString() я его и нашел в профайлере: у нас 5000 продуктов в базе, на гриде отображается страница в 20 продуктов, а при этом у меня в профайлере 3 000 000 вызовов ToString(). понятное дело WTF?! Переделали, что бы возвращал EntityID, т.к. и продукты и юзера и клиенты имеют primary key, который в общем то и определяет их идентичность.
Интересно, в одном случае инфраджистик в другом EntityID, как я понимаю проблемы были с доменными объектам
CRA>>Интересно кончено, но по тому что вы написали я ничего не могу сказать конкретного, так как мне лично ничеге не понятно, с nettiers так что умываю руки
BG>Я надеялся, что вам будет понятно, что неттиерс использовать не стоит
Посмотрим, жизнь она такая...
BG>>>Как вы и сами понимаете ни я ни мой коллега этот проект видеть больше не хотели CRA>>Так получается у вас как в детском саду?
BG>В той конторе был деццкий сад, не без этого. В этой конторе не деццкий сад, но архитекрурные проблемы все равно есть.
Без архитектурных проблем никуды.
Но я знаю одно — несколько архитектурных решений в одном проекта это самое плохое что может быть!
Здравствуйте, Sinclair, Вы писали:
S>Крайне рекомендую как можно быстрее ознакомиться с MVC Framework из ASP.NET 3.5. Это — правильный способ делать приложения на ASP.NET.
Кстати, я так не считаю. Контролов под него нет, хотя сама по себе реализация MVC сделана неплохо, ее даже можно без труда превратить в MVP. В данном виде этот фреймворк хорош для internet — приложений с простым интерфейсом.
Если же брать корпоративынй интранет, то даже мой самописный MVP-фреймворк делает работу более удобной, чем то, что сейчас есть у MS.
Здравствуйте, B0rG, Вы писали:
Замечание в сторону: на заре своей ASP.NET карьеры имел крайне негативный опыт взаимодействия с инфрагистиками.
То есть, с одной стороны, я в то время вообще не понимал как рендерятся страницы в ASP.NET, что такое viewstate и прочие детали postbackов, а с другой стороны, инфрагистики работали
а) чудовищно медленно в любом варианте и
б) некорректно во многих из вариантов.
После этого я перестал верить в великую силу инфрагистика, и на несколько лет заразился ощущением, что я делаю что-то не то.
Это ощущение стало превращаться в уверенность, когда я начал лучше понимать внутреннее устройство постбеков, а также закономерности поведения хороших веб-приложений.
В итоге понимание того, как надо писать приложения, у меня нашлось, но осадок по отношению к инфрагистику остался. Безотносительно окружающей архитектуры.
Это, кстати, к вопросу о том, как совершенно незначительные на первый взгляд решения начинают влиять на архитектуру приложения.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>В итоге понимание того, как надо писать приложения, у меня нашлось, но осадок по отношению к инфрагистику остался. Безотносительно окружающей архитектуры.
Все верно.
Инфрагистики достаточно тяжелая штука. Я и сам не фанат. Но тут есть несколько но:
*) клиент хотел rich functionality. Если бы девелоперы это делали руками, не применяя инфрагистик, у них ушло бы в 3 раза больше времени и 10 раз больше багов.
*) Некоторые вещи они позволяют делать очень быстро и красиво: например экспорт грида в эксель — я думал, что пропарюсь пол-дня не меньше (после моих предыдущих экспериментов), а удалось сделать за 15 минут.
Если согласиться жить с этими недостатками, понимая при этом, что мы приносим в жертву, то инфрагистиками вполне себе можно жить
