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

V>Можно примеры?

Ну например Парус-Магазин (неофициально парус 9). Довольно старый проект, но спроектирован довольно неплохо. Неплохие решения (далеко не все) есть в Парус 7, хотя технологически он отстал очень сильно.

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

Парус много разных платформ продает. Ты о какой?
Что же касается прикручивания собственных блоков, то это не из-за неверных технических решений, это из-за такой политики Паруса. Сейчас ситуация потихоньку меняется.

V>С 1С все ясно — она ближе всех подошла к "правильной" идее образца конца 90-x...

Не знаю точно что ты под "правильной моделью" имеешь ввиду, но есть еще Axapta, упомянутый тобой Акцент, Тектон.

V> однако, явно хромает имплементация и налицо отсутствие приемлимой масштабируемости. К тому же, даже в "серверной" 8-ке, их сервер не является самодостаточным сервером приложений.

В 8-ке нет сервера приложений. Это классическая двухзвенка.

V>Про SAP я спрашивал у разработчиков конфигураций под нее. Ответы просто невероятные — при наличии некоей масштабируемости этот гроб гораздо более трухлявее внутри чем та же 1С.

Ты в курсе сколько их решениям лет?

V> Разрабатывать под SAP вообще неудобно,

Разрабатывать под SAP практически невозможно. Ты покупаешь готовое решение и услуги по перепроектированию собственных бизнес-процессов. Вобще, на западе, ввиду того что бизнес-процессы у них на порядок стабильнее онных в России, системы чаще продают готовые. Единственная гибкая западная система, которую я видел, это Axapta.

V>Или оно пока в разработке?

И в разработке тоже.

V> Когда посмотреть можно будет?

Могу только про себя говорить. Ориентировочно к концу года.

AVK>>А фундаментальные знания по твоему это только математика?

V>ИМХО, те же паттерны ООП — это что-то вроде таблицы умножения или правил сокращения дробей, которые надо просто знать и уметь распознавать.

Паттерны, они разные бывают. Те, что у банды описаны, они конечно. А вот к примеру те, что описаны в Microsoft Pattern&Practice уже на порядок сложнее (см. к примеру SCOAB (Smart Client Offline Application Block)). Есть еще более сложные. И наконец есть конкретные решения с еще более сложной структурой.

V>Математика бывает, однако, и прикладной. Теория МО — тоже часть математики, и должна хоть иногда применятся при разработке тех же серверов приложений.

А она и применяется. Только в небольшом объеме.

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

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

ГВ>>>2. — Нестабильности предметной области (сколько финансистов — столько финансовых школ, сколько страховых компаний — столько методов страхования, сколько торговых компаний — столько моделей работы с клиентами и т.п.);

V>>1. Сложность не надо путать с объемностью.

IT>Что в твоём понимании сложность? А то пока ты не дал своего определения вряд ли мы сможем говорить об одном и том же.

Для себя я определяю сложность как степень "напряжения" мозгов. Подойдет такое определение? Чем большего сосредоточения и умственной отдачи требует работа, тем она сложнее. Ну а тепеь можно бесконечно перечислять внешние факторы, влияющие на мозговую напряженность:
— известность задачи для исполнителя,
— объем и сложность (!!!) теоретических знаний,
— количество необходимых действий в уме
— объем материала, который необходимо дежать в уме одновременно для выполнения задачи (размерность с т.з. человеческого понимания).
— количество моментов в задаче, которые сможем исполнять "по-привычке" (т.е. практически не думая, как перемножаем числа до 10).
— и т.д.

V>>2. При наличии конкретного ТЗ (или конкретного клиента с конкретной моделью) это никак не увеличивает сложность самой задачи. (Хотя, это бы увеличило сложность, скажем, "супер-мега-универсальной" системы. Но разработка подобной системы — это скорее разработка системного плана)

IT>В молодой конторе с бурно развивающимся бизнесом наличие ТЗ такая же редкость как и сферические кони вне вакуума. Сроки — вчера. Polymorphic behaviour — в сад. Code Conventions — лесом. Релиз — раз в неделю. Программер — швец, жнец, на дуде игрец. Архитектор — специалист по ампутированию гландов через выхлопную трубу и замены протезов во время забега. В наличии несколько часов после 24:00 для деплоймента, 1000 компов в трёх странах и право хранить молчание, которое всё равно будет использовано против Вас.

IT>А теперь вопрос. Какое нафиг ТЗ?

Хороший стиль, я бы подумал о писательском поприще

Если мы будем так же рассматривать сложности организационного порядка, то тут мне ничего не останется как согласится со определением "сложность", ибо, в этом случае, потребуется неимоверное напряжение тех самых умственных усилий.

-----------
А для составления ТЗ необязательно штатных аналитиков держать, можно и постороннего нанять.

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>А именно?..

А именно открывашь стандарт и начинашь искать неопределенное поведение и т.п. в любом таком месте у создателя утилиты рефакторинга будет инфаркт. И или эта утилита будет переодически гробить код, или она на более менее сложный код начнет чихать и ругаться "мол что за барахло вы мне подсунули". Ну, а все эти макросы и инклюды подольют масла в огонь.

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

FR>А как же те три коммерческие утилиты для рефакторинга С++, ссылки на которые я тут недавно приводил?

Они столь известны и популярны, что оценить их качество практически невозможно.

VladD2,

> ПК>А именно?..

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

Покажи, как именно это будет происходить на примере любого из случаев неопределенного поведения, упомянутых в стандарте C++. Я не представляю, как наличие неопределенного, равно как и implementation defined или unspecified behavior может влиять на рефакторинг...

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

E>>Дима, а какую именно область IT ты считаещь более сложной, чем бизнес-приложения?

V>Так же могу добавить:
V>- разработка различного инструментария (в помощь администрированию, например, там широченное поле деятельности).

Как человек, который последние несколько лет занимается именно этим — уверяю, ничего сложного в этом нет....Даже более того, трудно поискать другую сферу деятельности, которая настолько сводится к грамотному пользованию чужим API

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Покажи, как именно это будет происходить на примере любого из случаев неопределенного поведения, упомянутых в стандарте C++. Я не представляю, как наличие неопределенного, равно как и implementation defined или unspecified behavior может влиять на рефакторинг...

Мне просто влом копаться в стандарте. Можешь вынимать их по одному и обсудим.

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

П>Как человек, который последние несколько лет занимается именно этим — уверяю, ничего сложного в этом нет....Даже более того, трудно поискать другую сферу деятельности, которая настолько сводится к грамотному пользованию чужим API

Грамотным пользованием чужим АПИ многие задачи сводятся на нет.

VladD2,

> ПК> Покажи, как именно это будет происходить на примере любого из случаев неопределенного поведения, упомянутых в стандарте C++. Я не представляю, как наличие неопределенного, равно как и implementation defined или unspecified behavior может влиять на рефакторинг...

> Мне просто влом копаться в стандарте. Можешь вынимать их по одному и обсудим.

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

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

VD>Здравствуйте, Патрик, Вы писали:

П>>Как человек, который последние несколько лет занимается именно этим — уверяю, ничего сложного в этом нет....Даже более того, трудно поискать другую сферу деятельности, которая настолько сводится к грамотному пользованию чужим API

VD>Грамотным пользованием чужим АПИ многие задачи сводятся на нет.

Что-то эту фразу я не переварил

Разработка программ для администраторов — это создание правильной комбинации вызовов чужого АПИ

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

ГВ>>Ну не совсем так. На самом деле, из того факта, что чаще всего заметны задачи типа "вынуть-из-БД-отобразить-в-Web" такого обобщения сделать нельзя. 1. Структура информационной системы может по сложности ну ой как перемахивать через компиляторы и ОС. Просто сложность здесь заключается в:
ГВ>>2. — Нестабильности предметной области (сколько финансистов — столько финансовых школ, сколько страховых компаний — столько методов страхования, сколько торговых компаний — столько моделей работы с клиентами и т.п.);
ГВ>>3. — Необходимости сильной адаптации интерфейса пользователя к требованиям конечного пользователя;
ГВ>>4. — Необходимости согласования работы ИС с целой кучей софта, уже имеющегося у покупателя (нередко).

V>Я пронумеровал твои пункты.

V>1. Сложность не надо путать с объемностью.
Нет. Это она и есть — количество структурных элементов и есть сложность.

V>2. При наличии конкретного ТЗ (или конкретного клиента с конкретной моделью) это никак не увеличивает сложность самой задачи. (Хотя, это бы увеличило сложность, скажем, "супер-мега-универсальной" системы. Но разработка подобной системы — это скорее разработка системного плана)
Проблема не в этом. Порой для того, чтобы сформировать детальное ТЗ нужно взять теоретический талмуд и... списать его наполовину. Потому и ТЗ будет у нас не всегда. Понятно, что последовательная борьба с такой нестабильностью приводит к разработкам "системного" плана.

V>3. Это разнавидность п.2 применимого к ГУИ. Частично разновидность п.1. Если не удается достаточно хорошо унифицировать и автоматизировать этот вопрос, то именно ручками формочки и клепаем. В этом случае это чистое подтверждение п.1.
+1

V>Де-факто, ситуация присутствует, однако, она искусственно создана. Ликвидации (или значительного снижения) именно этого момента я ожидаю от популярных бизнес-систем следующего поколения.
ИМХО — это невозможно. Поскольку это прямо зависит от количества разработчиков систем: набор понятий, структура связей между ними и т.п. Собственно, такая же ситуация была и с процессорами несколько раньше. Но тут положение дел упростилось за счёт того, что Intel подавила конкурентов соотношением цена/качество и... ну, и IBM помогла, разумеется.