superman пишет: > > > гониш! Я вот практически вчера ромбик написал, и ничего, ни упрощать > ничего не охота и особой кривизны архитекруры не чувствую.
Вполне возможно, что у тебя случай, который 1 из 100. Но я бы еще
несколько раз подумал, насколько это решение именно для твоего случая.
superman пишет: > > > S>гониш! Я вот практически вчера ромбик написал, и ничего, ни упрощать > ничего не охота и особой кривизны архитекруры не чувствую. > > Вобщим что б не быть голословным. ... Или смартпоинтер по > вашему это зло?
Такое впечатление, что ты решил тут излить свои проблему какую-то. Ну не
интересно это.
Если ты осознаешь свой выбор, если видишь последствия этого выбора, если
можешь доказать архитектору (или тому, на ком эти обязанности лежат)
удобство и эффективность своего выбора, то в чем проблема?
Проблема же обычно в том, что многие используют многие паттерны не
задумываясь о последствиях и часто не осознавая толком своего выбора.
Например, у меня, подобный выбор всегда подразумевает, что разработчик
должен доказать мне удобство и эффективность своего решения. Кстати к
синглтонам (в любых их проявлениях), я отношусь так же, и к визиторам тоже.
Здравствуйте, Vzhyk, Вы писали:
V>5 этап: еще не дошел.
ИМХО 5-й этап, это когда UML генерится на основе кода. Причем генерится только то, что помечено соответствующей аннотацией (или служебных комментариев) в коде, и в результате автосгенереный UML не загроможден лишними деталями и описывает только суть.
Просто у меня нет слов. UML приходит в графическом виде. По нему ручками приходится заниматься высокоинтеллектуальной работой — набивать названия методов и т.д, лучше б сначала эти классы вбить, а потом на их основе сгенерить диаграмку. И далее — потом оказывается, что надо бы названия ключевых методов поменять или возвращаемое значение — меняется. Но в документации это никак не отражается, времени нет исправлять документацию, в результате UML даже на очень абстрактном уровне не соответствует коду. И толку от этого UML — минимум.
А если его автоматом поддерживать — вот в этом случае UML ИМХО будет очень к месту, так как реально будет помогать видеть архитектуру, будет актуальным, и не требовать никаких действий по поддержке. Вот только такого я не видел еще нигде.
Здравствуйте, Vzhyk, Вы писали:
V>Такое впечатление, что ты решил тут излить свои проблему какую-то.
1. У меня нет проблем (тьфу, тьфу, тьфу)
2. я не хочу об этом поговорить
выше по ветке 4 поста подряд (в том числе и твой) утверждают что ромбом не вкоем случае пользоватья нельзя, а тем кто это делает надо дать по пальцам. Я просто привёл на мой взгляд полезный логичный и обоснованый случай использования ромбовидного наследования, из своей приктика вот и всё.
проблема скорее всего у тебя, если ты подходиш к любому вопросу с позиции "я это не исполюзую и не знаю как использовать и вообще никогда в своей практике с таким не встречался, поэтому у всех кто делает что-то подобное судя по всему большие проблемы с архитектурой"
ИМХО То_что_я_не_использую_и_не_заню_зачем != Большие_проблемы_с_архитектурой_у_того_парня
V>Ну не V>интересно это.
Ну извини. Какого ты тогда это читаеш и отвечаеш в ветке?
Я просто нашол пример с "знаю зачем", просто поделилися опытом. Мне он интересен.
elmal пишет: > > V>5 этап: еще не дошел. > ИМХО 5-й этап, это когда UML генерится на основе кода. Причем генерится > только то, что помечено соответствующей аннотацией (или служебных > комментариев) в коде, и в результате автосгенереный UML не загроможден > лишними деталями и описывает только суть.
doxygen
> Просто у меня нет слов. UML приходит в графическом виде. По нему ручками > приходится заниматься высокоинтеллектуальной работой — набивать названия > методов и т.д, лучше б сначала эти классы вбить, а потом на их основе > сгенерить диаграмку.
А почему не использовать какой генератор, хоть встроенный в тул, хоть
самописный.
А вообще то, что ты написал, это, 3-й?
Еще раз, UML — это не самоцель, это один из языков программинга, наравне
с другими, как то java, C#, C++, python ... и каждому из этих языков
свое место.
Здравствуйте, Vzhyk, Вы писали:
V>Еще раз, UML — это не самоцель, это один из языков программинга, наравне V>с другими, как то java, C#, C++, python ... и каждому из этих языков V>свое место.
Всегда считал его языком описания и способом документирования, но никак не программирования. Классовая диаграмка штука полезная зачастую, например, но когда она первична и код вторичен — одни неудобства от этого в результате.
А то, что считаешь третьим — нет, это не третий, так как в этом случае куча ненужного хлама не будет генериться. В UML будем иметь только то, что требуется, и ничего больше.
Здравствуйте, Vzhyk, Вы писали:
V>А почему не использовать какой генератор, хоть встроенный в тул, хоть V>самописный.
Генератор не сделает кучу мелких действий. Например он не поместит сгенерированные классы в нужные директории, более того, сгенерит он скорее всего не совсем то, что хотелось бы. А самой диаграмме абсолютно не должно быть важно где эти классы находятся, это излишняя детализация будет в большинстве случаев. Ну и это — мне всегда UML диаграмки приходили как графический растровый файл, с которого даже скопипастить ничего нельзя — какая автогенерация ?
PS В студенческие годы, начитавшись того, что UML это круто — пытался генерить код целиком с его помощью . Ну и еще, полгодика назад был у меня проектик, приходилось вообще всю логику рисовать в специализированной среде графически мышкой, а тот уже генерил код (коммитился только тот файл, который рисуем, рисовал что-то похожее на UML) — у меня в результате аллергия на графические тулзы и автогенерацию из графического представления выработалась наверно на всю жизнь .
elmal пишет: > > V>А почему не использовать какой генератор, хоть встроенный в тул, хоть > V>самописный. > Генератор не сделает кучу мелких действий. Например он не поместит > сгенерированные классы в нужные директории, более того, сгенерит он > скорее всего не совсем то, что хотелось бы.
У вас уже программы с интеллектом? Т.е. они делают то, что хотят сами, а
не то, что вы им говорите делать?
> Ну и это — мне всегда UML диаграмки > приходили как графический растровый файл, с которого даже скопипастить > ничего нельзя — какая автогенерация ?
Если вы забиваете (ну не ты лично) гвозди микроскопом, то это разве
говорит, что микроскоп дерьмо? Это больше говорит о вас.
> > PS В студенческие годы, начитавшись того, что UML это круто — пытался > генерить код целиком с его помощью ... — у меня в результате аллергия на графические тулзы и автогенерацию > из графического представления выработалась наверно на всю жизнь .
И это плохо, так рано и становиться настолько консерватором.
Просто надо выбирать инструменты под задачу, причем наиболее удобные и
позволяющие максимально автоматизировать механическую работу.
Здравствуйте, Vzhyk, Вы писали:
V>И это плохо, так рано и становиться настолько консерватором. V>Просто надо выбирать инструменты под задачу, причем наиболее удобные и V>позволяющие максимально автоматизировать механическую работу.
Да ... удобство очертененное. Рефакторить это все очень тяжело, когда надо провести декомпозицию — надо рисовать все заново с нуля обычно. С системами контроля версий все плохо — если файл надо редактировать двум людям, конфликты неизбежны, и таковы, что кому-то придется откатывать свои изменения и начинать рисовать все заново (и уже блокировать файл на изменение). Кучу времени тратить на то, чтоб стрелочки нормально выглядели, выравнивать там эти квадратики, двигать и т.д. Изменение если какое, и что-то не помещается — передвигать приходится вообще все. diff нечерта не сделать, не поймешь что изменилось. Кто-то что-то если сломал — хрен найдешь, самое реальное решение — дебажить автосгенеренный код (так как автогенерация, то там сам черт ногу сломит, написан же он для машины, а не для человека). И это в том случае, если тулза работает без ошибок и не тормозит, и имеет достаточно удобный интерфейс. Спасибо, это проходили уже.
Здравствуйте, alcotras, Вы писали:
A>Эх, молодой человек... Не видели Вы примеры индусских резюме ))))))))))))) 200% вранья — и полет нормальный, главное в референсы вписать всю деревню.
А на западе так принято. Англосаксы пиар любят.
Ситуация "чем человек умнее тем он скромнее" — чисто русская национальная черта. Буржуи ее совершенно не понимают.
Опыт — это такая вещь, которая появляется сразу после того, как была нужна...
Здравствуйте, Vzhyk, Вы писали:
V>Еще раз, UML — это не самоцель, это один из языков программинга,
Вообще-то это язык моделирования для ОО подхода к разработке.
V>наравне с другими, как то java, C#, C++, python ...
Ну-ну...
Здравствуйте, EM, Вы писали:
EM>Здравствуйте, The Lex, Вы писали:
TL>>Здравствуйте, olegkr, Вы писали:
O>>>Индусов отсеить, слава богу, просто — достаточно посмотреть на имя кандидата...
EM>Да, имя "Кумар" может натолкнуть на размышления.
А что вы так к индусам?! У них одна из самых равитых образовательных систем, математиков очень много, книг по программированию ими написано чрезвычайно много и на международных коференциях я чаще наших встречаю. Кстати говоря, и софта ими создано не в пример нам больше, один Infosys чего стоит (у нас есть лавки со щтатом больше 100 К чел?). Благодоря лавинообразному аутсорсу в Индию в последнее десятилетие, легко можно понять, что софт, которым мы пользуемся был написан именно в Индии. Это как Китай, который уже всех превозошел в спортре и заплонил товарами, так вот, Индия тоже самое, но в софте.
Здравствуйте, shrecher, Вы писали:
S>А что вы так к индусам?!
Работать нам с ними приходится. И про "развитое" образования наслышаны (ПТУ отдыхает) и знаем, что количество далеко не всегда перерастает в качество. Про Китай ты тоже к месту сказал, дешевые некачественные поделки — неплохое сравнение.
Из последнего общения с индусами. Попросили соседний отдел (там индусы) поправить хранимку, что бы update шел не по всем записям, а только по списку id. Самим нам править хранимку низзя, увы и ах. Так вот, список id они сразу забраковали, типа не умеем. Черт с вами, будем гонять сотни update-ов, раз не умеете, сделайте хотя бы с одним id на входе. Они сделали. Добавили в хранимку параметр и все, само тело хранимки не поменяли, видимо думали, что силы вуду автоматически это сделают.
Таких историй, сидя у камина зимними вечерами с бокалом коньяка, можно рассказывать правнукам и не повторяться годами.
Здравствуйте, shrecher, Вы писали:
O>>>>Индусов отсеить, слава богу, просто — достаточно посмотреть на имя кандидата...
EM>>Да, имя "Кумар" может натолкнуть на размышления.
S>А что вы так к индусам?!
да я к ним также как ко всем. Я вообще настолько не расист, что всем бы так.
S>У них одна из самых равитых образовательных систем, математиков очень много, книг по программированию ими написано чрезвычайно много и на международных коференциях я чаще наших встречаю. Кстати говоря, и софта ими создано не в пример нам больше, один Infosys чего стоит (у нас есть лавки со щтатом больше 100 К чел?). Благодоря лавинообразному аутсорсу в Индию в последнее десятилетие, легко можно понять, что софт, которым мы пользуемся был написан именно в Индии. Это как Китай, который уже всех превозошел в спортре и заплонил товарами, так вот, Индия тоже самое, но в софте.
Среди известных мне лондонских компаний за последний год пошла волна аутсорса в индию и выглядит это так: сидит тимлид, программирует потихоньку с 2-3 подчиненными.
Приходит умное начальство:
"будем расширяться! Вот тебе 20 индусов! Нет, 20 мало — 30! Бери телефон и рули".
Когда мне рассказывали что начинается потом даже я был впечатлен. Родной аутсорс со студентами это тоже круто, но не настолько. Например, у нас бы просто не додумались сказать о начальнике коренном англичанине что у него херовый английский и попросить другого.
Так что после всех этих рассказов я думаю что все индусские успехи делает 1% индусских программистов, которые сумели стать професионалами. Так как этот 1% больше русских 100%, то и успехи их больше. Но среднестатистический заказчик познакомится с представителями остальных 99 и судьба его будет непроста.
Опыт — это такая вещь, которая появляется сразу после того, как была нужна...
Здравствуйте, olegkr, Вы писали:
O>Здравствуйте, shrecher, Вы писали:
S>>А что вы так к индусам?! O>Работать нам с ними приходится.
пока нет.
O>Китай ты тоже к месту сказал, дешевые некачественные поделки — неплохое сравнение.
Качественно или нет, но "пипл хавает". Сечас все рынки ширпотреба, электроники, игрушек, тканей завалены китайскими товарами. Что не возмешь "China". Поэтому какбы этого качества и достаточно, наверно.
Здравствуйте, olegkr, Вы писали:
O>Попросили соседний отдел (там индусы) поправить хранимку, что бы update шел не по всем записям, а только по списку id. Самим нам править хранимку низзя, увы и ах.
судя по уровню маразма это может быть только Инвестбанк
Опыт — это такая вещь, которая появляется сразу после того, как была нужна...
Здравствуйте, EM, Вы писали:
EM>судя по уровню маразма это может быть только Инвестбанк
Ага, он самый. Только это не маразм, а прагматизм. Нафига мне отвечать за хранимку на чужом серваке? Ну поменяю я ее сам, а они потом, не имея понятия о моих изменениях, зальют старую версию и кирдык-приплыли, система в production упала. И кто виноват? Я виноват. Оно мне надо?
Думаю так же дела обстоят в любых крупных конторах.
V>>5 этап: еще не дошел.
AVK>А мы дошли после пары лет 4 этапа. Выкидываем UML нафик и описываем архитектуру простым и понятным человеческим языком с примерами кода и, если уж очень нужно, небольшими диаграммками без какой либо особой формализации. Для примера можешь посмотреть на всякие overview и architecture статьи в MSDN.
Кстати, примерно это и советует Алистер Коберн. Ну, кроме примеров кода — имхо, как раз их быть не должно. Код должен идти лесом в любой проектной документации, даже на самом низком уровне.
А вообще, мое мнение, описывать те же юзе кейсы на ЮМЛ довольно бесперспективно — не видно СЦЕНАРИЯ, а уже если кроме основного сценария есть и расширения — тогда вообще трах-бах, как нормальным образом все это связать, чтобы не сломать мозг даже врайтеру — непонятно. В общем, что-либо более сложное, чем роли, участники и цели, а также юзе-кейсы самого верхнего уровня на ЮМЛ описывать бесперспективно. Иногда можно поиграться с диаграммами взаимодействия или последовательностей, но в общем случае — все это гораздо лучше описывается неспециализированными (но понятными даже не специалисту) рисунками и четкими пошаговыми инструкциями. Мой опыт говорит о том, что ЮМЛ иногда хорошо использовать в роли "держателя оглавления и структуры". Т.е. на _самом_ верхнем уровне описания требований и проектирования, и то вперемешку с текстом. Все остальное — банальные текстовые описания с рисунками. В общем, все, как обычно, хорошо в меру и к месту...
Здравствуйте, shrecher, Вы писали:
S>А что вы так к индусам?! У них одна из самых равитых образовательных систем, математиков очень много, книг по программированию ими написано чрезвычайно много и на международных коференциях я чаще наших встречаю. Кстати говоря, и софта ими создано не в пример нам больше, один Infosys чего стоит (у нас есть лавки со щтатом больше 100 К чел?).
Ну компания с 100K человек. И что дальше? Ну написаны мегатонны формочек. И что?
S>Благодоря лавинообразному аутсорсу в Индию в последнее десятилетие, легко можно понять, что софт, которым мы пользуемся был написан именно в Индии.
Ага, понять можно по таким признакам: падучесть, глючность, непродуманость.
Основная масса индусов-аутсорсеров — тупы как пробки. Это не расизм, это просто факт жизни. Вменяемых индусов вряд ли сильно больше, чем вменяемых программистов в России. По крайней мере, мне такой попался пока только один — он работал начальником отдела и в одиночку исправлял то, что писали его подчинённые. По слухам, почти все вменяемые товарищи или уже уехали в США, или уже на годы вперёд заняты работой.
Ещё у индусов полное отсутствие инициативы. Даёшь им ТЗ и они будут его без вопросов делать, даже если там ошибки и оно в принципе жить не будет. Будут сидеть себе и тихо чего-то писать, пока платить заказчику не надоест.
))))))))))))) 200% вранья — и полет нормальный, главное в референсы вписать всю деревню.
