Здравствуйте, Vzhyk, Вы писали:

V>В смысле? Его за тебе другие поддерживают, как и С с плюсами впрочем.
Sequence diagram???

V>Знаешь, голову еще никто не отменял.
Нельзя учесть все ньюансы. Да и бессмысленно это.

V>А в коде не проще, насмотрелся я таких "кодировщиков", аж тошнит.
Ну а я насмотрелся того, как после начала работы по диаграммам архитектуру приходилось менять, т.к. не учли вот тааакууусенькой мелкой детали. Кроме того, у меня нет проблем мыслить абстрактными понятиями без цветных квадратиков. Кому-то может помогает, не спорю.

olegkr пишет:
>
>
> V>В смысле? Его за тебе другие поддерживают, как и С с плюсами впрочем.
> Sequence diagram???
Осталось спросить. А сколько тебе лет?
А sequence, вполне себе приличные, если применены к месту, а вот если не
к месту, то даже обычные диаграммы классов фиг в актуальном состоянии
поддерживать сможешь.

>
> V>Знаешь, голову еще никто не отменял.
> Нельзя учесть все ньюансы. Да и бессмысленно это.
А сколько тебе лет? Ну нельзя же всю жизнь ко всему подходить только с
точки зрения черного и белого.
Конечно нельзя, категорически нельзя.

>
> V>А в коде не проще, насмотрелся я таких "кодировщиков", аж тошнит.
> Ну а я насмотрелся того, как после начала работы по диаграммам
> архитектуру приходилось менять, т.к. не учли вот тааакууусенькой мелкой
> детали. Кроме того, у меня нет проблем мыслить абстрактными понятиями
> без цветных квадратиков. Кому-то может помогает, не спорю.

Не люблю телепатией заниматься, но придется.
В твоем случае, твое неприятие диаграмм в UML похоже вытекает из того,
как тебя заставляли их использовать.

Есть два подхода:
1. В этих диаграммах описываются ключевые и наиболее важные моменты системы.
2. Диаграммы делаются почти механически с дикой детализацией до каждого
приватного члена класса и sequence вешается ко всему, чему можно и нельзя.
Как видишь второй подход, про дурака, которому сказали молиться...



P.S. Как ты думаешь, остальные разработчики у вас телепаты?

P.P.S. Мне пока удавалось делать такую архитектуру, которую пока ни одна
из малюсеньких или не малюсеньких деталей не поломала. Причем без UML я
бы где-то точно слажал.

olegkr пишет:
>
Как я дошел до понимание эффективности использования UML.

Этапы понимания, сильно упрощенно:

1 этап: какие странные и бестолковые картинки, по коду и так все понятно
— облом на своем же коде через год.

2 этап: будем рисовать все в UML (Бучи и все остальные плотно изучались)
и генерировать код — полный провал.

3 этап: ладно, не получилось, будем писать код, как привычно и по нему
реверсом генерить UML — чуть лучше, но автомат дает кучу ненужного
хлама. Фактически нужно перерисовать самому, а потом, посмотрев то, что
получилось поправить код.

4 этап: всему свое место и время. В UML, как достаточно удобном языке
отображаются ключевые моменты архитектуры и реализации системы, без
излишней детализации. Код пишется ручками, или генерируется на уровне
интерфейсов и шаблонов реализаций (ну не люблю я по клавиатуре стучать).
— Так как, диаграммы не перегружены детализацией поддержка их в
актуальном состоянии элементарна;
— Так как диаграммы не перегружены детализацией по ним легко видны
взаимосвязи в системе, потоки данных, в общем только то, что нужно для
понимания архитектуры в целом.

5 этап: еще не дошел.

Здравствуйте, Vzhyk, Вы писали:

V>Осталось спросить. А сколько тебе лет?
Много, я старенький

V>А sequence, вполне себе приличные, если применены к месту, а вот если не
V>к месту, то даже обычные диаграммы классов фиг в актуальном состоянии
V>поддерживать сможешь.
Что за каша? Ничего не понял. Если диаграммы классов хоть как-то автоматически синхронизируются с кодом, то все остальные типы диаграмм — вообще никак.

V>1. В этих диаграммах описываются ключевые и наиболее важные моменты системы.
Это правильно. Единственное место, где UML применим — это высокоуровневые диаграммы, расчитанные для показа начальству и в качестве иллюстраций к шоу под названием "а я сейчас вам всем расскажу, какая у нас крутая архитектура". Практическая ценность их в разработке стремится к нулю.

V>2. Диаграммы делаются почти механически с дикой детализацией до каждого
приватного члена класса и sequence вешается ко всему, чему можно и нельзя.
Правильно. И поэтому я и говорю, что такие рабочие диаграммы нам нафиг не нужны, а нужны красивые картинки для пиара.

Здравствуйте, elh_smart, Вы писали:

_>На этом, думаю, обсуждение можно завершить. С вашего позволения.

Поздравляю, вы в Нью-Й..., тьфу, на RSDN. Запасайся попкорном!

Здравствуйте, SkyDance, Вы писали:

SD>Значит, в вашей отрасли это не требуется. Все зависит от того, чем заниматься. В некоторых случаях и вовсе человек С++ не применяет. Но если дается тест по С++, это значит, что человека ждут именно на плюсовые разработки.

В обычной разработке детальное знание голого С++ ненужно, если, конечно, не разработчик компилятора. Нужно занать ООП, рабираться часто используемых конструкциях и уметь найти ответ на неизвесный материал. Самое главное это уметь писать надежно, проверять коды ошибок, уметь алгоритмировать, мыслить творчески, находить причины ошибок и надежно их устранять.

Здравствуйте, egaron, Вы писали:

A>>>В инфе написано, что он в 85-м году родился.
A>>>Ранова-то себя матёрым волком считать, которому такие тесты будет стыдно показывать.
L>> Помниться видел человека 35 лет. Понятия неимеющем о юнит тестировании. UML — как нечто большое трудное и злое, которое я — как молодой сотрудник от нежелания работать пытался навязать. Немог корректно спроектировать бд. Довольно смутные представления об ооп (не мне судить но незнание что такое friend классы наводит на чёрные думки). Что такое автосборки мы незнали. Использовали сервер со структурой батников для автобилда. Попытки перейти на круиз контрол присекались.

E>На какие же черные думки навело ? что человек — кодер-неудачник, а вы — кодер-фанатик ? не все с фанатизмом бросаются на новые технологии.

Угу. friend-классы и нормальные формы БД — ни дать, ни взять — новые технологии. make и его последователи — тоже какая-то круто навороченная новизна. Ну а unit-тестирование вообще придумано молодняком, чтоб от работы отлынивать. egaron, ты говори, да не заговаривайся.

E>не все не вылезают из-за компа днем и ночью. у неокторых людей в 35 даже семья есть, не знали ?
E>Вот характерный пример для ветки "бунт 40-летних" и ответ на вопрос — почему мы так не любим молодых

Да уж... А меня он наводит на не менее чёрную мысль, что в конфликте "молодых" и "старых" немало рациональных зёрен. Прям таки — амбары, до верху набитые. Огорчает сие без меры.

E>зы) на всех моих работах ни разу не понадобился ЮМЛ. а эти всякие "Л" (один за другим). Разве что для вьюношей, самоутверждающихся на собеседках засчет "старперов"

Гонишь. Это всего лишь знание общеупотребительного языка формализации моделей. Что-то вроде языка принципиальных электрических схем.

Здравствуйте, Dziman, Вы писали:

E>>Да знаешь, если бы я некоторых своих 50-летних коллег стал бы спрашивать по крузаку , нанту или другим новомодным приблудам, то их ответ был бы тот же, как если бы тебя стали спрашивать по системе команд ЕС ЭВМ. это не основание их считать глупее себя. молодые всегда знают больше технических деталей, особенно если те новомодные.

D>Т.е. спросить по технологиям, приминяемым на проекте — это самоутверждение ?

Нет, но плохо то, что ты считаешь, что незнание определённых технологий автоматически приведёт к тому, что проект не будет сделан за разумное время. Собственно, производительность труда программистов определяется развитостью абстрактного мышления, а не памятью на кучу деталей.

D>На собеседовании не должно быть глупее/умнее, а должно быть подходит ли кандидат для проекта. Набрав десяток человек(будь они хоть глупее, хоть умнее "тебя"), знающих "систему комманд ЕС ЭВМ", но не знающих что такое "крузак", "нант", ..., "все технологии используемые на проекте", не сделаешь проект за разумное время.

Да, вот это оно и есть. ИМХО, нужно выяснить, знает ли кандидат, что такое автосборка и зачем нужна. Что именно используется в проекте — уже детали. Хоть nant, хоть make, хоть пресловутый ворох пакетных файлов, хоть что-то самописное.

Здравствуйте, vsb, Вы писали:

L>> Скажем так. БД была даже не в 1 НФ.
vsb>А такое разве бывает? На какой СУБД?

Легко! На любой из клонов PICK (Unidata).

Здравствуйте, olegkr, Вы писали:

V>>1. В этих диаграммах описываются ключевые и наиболее важные моменты системы.
O>Это правильно. Единственное место, где UML применим — это высокоуровневые диаграммы, расчитанные для показа начальству и в качестве иллюстраций к шоу под названием "а я сейчас вам всем расскажу, какая у нас крутая архитектура". Практическая ценность их в разработке стремится к нулю.

Ну не скажи. Например, те же самые use cases вполне себе удобно на UML описывать. Только это уже не шоу, а вполне себе документация.

Здравствуйте, Vzhyk, Вы писали:

>> Из личного опыта "межобщения" лично я предпочел бы крамотно нарисованные
>> диаграммы.
V>Примерчик, можно. Диаграммы вообще, они такие разные.
V>Позаимствую, если понравиться больше, чем UML (в смысле более понятно
V>любому программисту будет).

Читал-читал... Ты имеешь в виду, что ты подумал, что я использовал "свои кастомные не UML диаграммы"? Нет, конечно же.

Диаграмма состояний — как же без нее?
Sequence diagram — не знаю как это на русский переводится — особенно на синхронизации многопоточных систем.
Диаграмма классов — сам не лююблю и не нашел применимости кроме как "показать директору как мы много крутых классов наклепали".

olegkr пишет:
>
>
> V>1. В этих диаграммах описываются ключевые и наиболее важные моменты
> системы.
> Это правильно. Единственное место, где UML применим — это
> высокоуровневые диаграммы, расчитанные для показа начальству и в
> качестве иллюстраций к шоу под названием "а я сейчас вам всем расскажу,
> какая у нас крутая архитектура". Практическая ценность их в разработке
> стремится к нулю.
>
> V>2. Диаграммы делаются почти механически с дикой детализацией до каждого
> приватного члена класса и sequence вешается ко всему, чему можно и нельзя.
> Правильно. И поэтому я и говорю, что такие рабочие диаграммы нам нафиг
> не нужны, а нужны красивые картинки для пиара.
Теперь понятна твоя реакция на UML.

А молотком гвозди забивать не пробовал? Зачем, ну например, начальство
так сказало.

Здравствуйте, The Lex, Вы писали:


TL>Да, кстати: пока домой ехал — придумал как бы я "проверял кандидата на логику на примере мультинаследования". Берем кандидата, рисуем ему диаграмму наследования, ложим рядом стандарт, и просим объяснить последовательность конструирования и деконструирования, причем в идеальном варианте — ссылаясь на пункты в стандарте.

Кому нужна эта голая теория. Спрашивают обычно то, с чем предстоит рабоать.Интресно, если чел не рабола с мультинаследованием и ему не предстоит с ним работать, то зачем это спрашивать?

PS. За 10+ лет программирования на C++ мне практически не было нужды лазить а C++ стандарт. Есть VC++ у него свое трактование всех стандартов. RFC — да прой нужно, а C++ стандарт — "в сад".

Здравствуйте, Vzhyk, Вы писали:

V>Lloyd пишет:
>>
>> А если человек, которого собеседовали, был на позицию C++-ника, то он
>> просто не мог этого забыть.
V>По ручкам, по ручкам за ромбики и не линейкой, а молотком, если в живом
V>коде такое (ну кроме очень экзотических случаев, 1 из 100, может быть).

Да я не против что по ручкам за ромбики, не поверите, никогда ексепшены не юзал, а вопрос тоже есть на собеседовании.

Не поверите, но даже в институте, когда человек идет учиться на этого, как его... программера, то тоже спрашивают и Пушкина (в одной стране) и Шевченко (в другой), хотя потов в работе не то что 1 к 100 но даже 1 к 10М не встретится.

Есть общее знание. Кто знает — а что за код придет от кастомера? Сможет ли человек в нем разобраться и понять где сидит большая толстая бага. На вашем месте я бы не делал таких скоропалительных выводов.

Здравствуйте, shrecher, Вы писали:

S>PS. За 10+ лет программирования на C++ мне практически не было нужды лазить а C++ стандарт. Есть VC++ у него свое трактование всех стандартов. RFC — да прой нужно, а C++ стандарт — "в сад".

Тогда Вы путаете "10+ лет программирования на C++" и "10+ дет программирования на VC++", IMHO.

TL>Хочешь понять как мыслит? Задавай классические вопросы "про жирафа в холодильнике". "Про жирафа" — боян? Придумай свои, которые "как мыслит". имхо, вопросы по стандарту и "фишкам" языка-платформы-архитектуры — не самые лучшие для "понять как мыслит человек".

Нафиг, нафиг.
"Жирафы в холодильнике" покажут лишь умение кандидата сидеть на форумах а-ля рсдн, и всё. Эти задачи откровенно плохи. Потому что:

1. Они абстрактные. Люди же нужны конкретные и с конкретными мозгами.
2. На эти задачи есть "правильный ответ", который либо знаешь, либо нет.
3. В глазах кандидата каждый такой "абстрактый вопрос" — минус конторе. Потому что контора занимается черти чем вместо конкретных дел.

D>Потрясающе спорное утверждение, в разработке есть различные направления, у которых сильные и слабые стороны различаются. Если человек попробовал и более менее вник(это происходит за полгода-года), он будет , в общем случае, эффективнее и гибче, чем "проффи", который отработал в одной конторе, с одним подходом к разработке, одними корпоративными правилами(очевидно, не идеальными), одними людьми. Кстати, как говорил классик "проффи" подобен "ффлюссу".

Каждый молодой выпускник ВУЗа обязательно думает, что вот именно он-то, как раз, работает эффективнее и гибче.
К счастью, с возрастом приходит понимание, что стоит "медленно спуститься с холма и покрыть всё стадо" (С)

L>friend классы

Апологеты ООП какбе считают что приватность это зло (я думаю потому что она не способствует декомпозиции)
понятия friend и т.п. это уже примочки отдельных реализаций

Здравствуйте, SkyDance, Вы писали:
SD>Нафиг, нафиг.
Однажды на собеседовании в ответ умничающему интервьюеру, который задал мне задачку из серии "до каких пор волк в лес бежит" я задал свою логическую задачку, на которую ответ знал Такого о...вшего лица я в жизни не видел. "Я... затрудняюсь ответить если честно..." и "Мы Вам перезвоним...". Ну и я для себя выводы сделал

Здравствуйте, Octothorp, Вы писали:

O>Однажды на собеседовании в ответ умничающему интервьюеру, который задал мне задачку из серии "до каких пор волк в лес бежит" я задал свою логическую задачку, на которую ответ знал Такого о...вшего лица я в жизни не видел. "Я... затрудняюсь ответить если честно..." и "Мы Вам перезвоним...". Ну и я для себя выводы сделал
Вообще, как только на интервью начинаются задачи из серии "летят два напильника, один круглый, другой на север...", можно сразу делать выводы.