У меня в голове назрело несколько полуриторических вопросов и соображений.
— Почему лучшие умы буквально с первых дней создания компьютеров бьются над проблемой создания языка, позволяющего проектировать программы по аналогии с созданием электронных схем, и всё без толку???
— Почему "электронщики" могут:
— Создавать из электронных компонентов платы;
— Оттестировав платы, не забивать себе голову деталями их реализации;
— Создавать из плат крейты;
— Оттестировав крейты, считать их работающими "чёрными ящиками";
— Создавать из крейтов — стойки, и т.д....
...а программисты не могут?
// Оффтоп: Моё основное место работы — лаборатория экспериментальной ядерной физики, и я каждый день
// вижу то, о чём говорю. Стили работы инженеров-разработчиков электронной аппаратуры и
// программистов разнятся кардинально. Причём не в пользу последних.
— Почему современное программирование по-прежнему напоминает смесь шаманства, искусства и кулинарии нежели инженерную дисциплину?
— Почему единожды написав и оттестировав программный компонент, процесс повторного использования оного во всех дальнейших проектах схожей тематики доводит программиста до кровавого геморроя? Особенно в С++!
— Не кажется ли вам, уважаемые господа, что концепция программы в виде последовательно выполняющихся инструкций годится далеко не на все случаи жизни?
// Оффтоп: ФП не предлагайте — я прагматик
— Не лучше ли использовать flow-driven-programming для больших, и тем более распределённых, программных систем.
// Да, я конечно понимаю, что серебрянной пули не существует, и все существующие классы задач данным методом не решить.
// Какие задачи удобно решать: системы DSP, SCADA, АСУТП, системы диагностики, сигнализации, и т.п.
К чему вообще всё это: хочется просто-напросто поднапрячься, да и изваять модульную, повторно-используемую и удобную (на первых порах — хотя бы для себя) "потокоцентричную" архитектуру разработки приложений.
Из коммерческих реализаций данной идеи стОит вспомнить LabVIEW. Очень, надо сказать, популярный язык в узких кругах, и недешёвый при том.
Но неуместные в dataflow-стиле императивные конструкции языка, ужаснейшие механизмы обработки событий, жутчайшие стандартные элементы GUI, проприетарный формат модулей и проектов, неудобный редактор схем, закрытость, дороговизна и многое другое, сделали этот язык мертворождённым.
Есть идеи, как сделать так же, да лучше. СтОит ли браться?
PS. Понимаю, что последний вопрос самый риторический.
Здравствуйте, iiice, Вы писали:
I>Есть идеи, как сделать так же, да лучше. СтОит ли браться?
Не стоит, всё равно ничего не получится.
Софтостроение кардинально отличается от других инженерных дисциплин одной принципиальной вещью — перманентным измением функциональных требований к системе на всех этапах проектирования и разработки. Если бы электронщики проектировали и конструировали свои системы как мы, то, боюсь, у них бы дело вообще далеко не ушло.
Неясность изложения обычно происходит от путаницы в мыслях.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, iiice, Вы писали:
I>>Есть идеи, как сделать так же, да лучше. СтОит ли браться?
IT>Не стоит, всё равно ничего не получится.
IT>Софтостроение кардинально отличается от других инженерных дисциплин одной принципиальной вещью — перманентным измением функциональных требований к системе на всех этапах проектирования и разработки. Если бы электронщики проектировали и конструировали свои системы как мы, то, боюсь, у них бы дело вообще далеко не ушло.
Не согласен. Строительная инженерия начиналась с шалаша, а сейчас мы строим небоскребы — всему свое время: надо пройти все стадии от "шалаша" до "небоскреба".
Здравствуйте, Alexey Lan, Вы писали:
AL>Не согласен. Строительная инженерия начиналась с шалаша, а сейчас мы строим небоскребы — всему свое время: надо пройти все стадии от "шалаша" до "небоскреба".
Что-то я ни разу не видел, что бы кто-то из строителей начинал строить шалаш, а закончил небоскрёбом. А в софтостроении такое сплошь и рядом.
Неясность изложения обычно происходит от путаницы в мыслях.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Alexey Lan, Вы писали:
AL>>Не согласен. Строительная инженерия начиналась с шалаша, а сейчас мы строим небоскребы — всему свое время: надо пройти все стадии от "шалаша" до "небоскреба".
IT>Что-то я ни разу не видел, что бы кто-то из строителей начинал строить шалаш, а закончил небоскрёбом. А в софтостроении такое сплошь и рядом.
А я пока не видел небоскребов
Пока научились в массе что-то вроде шашлашей, обработаных глиной, в большом количестве и самых разнообразных форм делать, а до небоскребов пожалуй далековато. Прототипчики есть, но использовать их по назначению пока нельзя.
Кстати, насчет требований — клиенты к дому тоже меняют требования порой с космической скоростью, только вот c такими никогда контракт не заключат, то же и с бизнес-процессами, если на бизнес-уровне все грамотно и четко, то и до разработчиков будет спущен грамотный четкий чертеж на "дом" (средневековый), причем на каркас, а уж фенечки используя разработанные или уже имеющиеся инструменты будут доделывать. В этом направлении уже движутся многие продукты и с каждым годом их будет все больше, а надежность дойдет до уровня "небоскребов"
Здравствуйте, Alexey Lan, Вы писали:
IT>>Что-то я ни разу не видел, что бы кто-то из строителей начинал строить шалаш, а закончил небоскрёбом. А в софтостроении такое сплошь и рядом.
AL>А я пока не видел небоскребов
Видел, не видел — это лирика. А факты — это изменение требований к системе по ходу дела. Абсолютно старндартная практика в софтостроении, неприменимая больше нигде.
AL>Кстати, насчет требований — клиенты к дому тоже меняют требования порой с космической скоростью, только вот c такими никогда контракт не заключат,
Потому что построить дом в таких условиях не получится, а софт написать можно.
AL>то же и с бизнес-процессами, если на бизнес-уровне все грамотно и четко, то и до разработчиков будет спущен грамотный четкий чертеж на "дом" (средневековый), причем на каркас, а уж фенечки используя разработанные или уже имеющиеся инструменты будут доделывать. В этом направлении уже движутся многие продукты и с каждым годом их будет все больше, а надежность дойдет до уровня "небоскребов"
Я сомневаюсь. Пока такой небоскрёб по спущенному грамотному чёткому чережу будет построен, то он уже успеет десять раз морально устареть и никому не будет нужен.
Неясность изложения обычно происходит от путаницы в мыслях.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Alexey Lan, Вы писали:
IT>>>Что-то я ни разу не видел, что бы кто-то из строителей начинал строить шалаш, а закончил небоскрёбом. А в софтостроении такое сплошь и рядом.
AL>>А я пока не видел небоскребов
IT>Видел, не видел — это лирика. А факты — это изменение требований к системе по ходу дела. Абсолютно старндартная практика в софтостроении, неприменимая больше нигде.
В софтостроении 5 лет, может и не много, но достаточно, чтобы бы утверждать — небоскребы еще не научились строить, а требования быстро меняют по причине которую вы нижеуказали — значит работать надо здесь на бизнес-уровне, а не только подстраивать процессы разработки софта.
AL>>Кстати, насчет требований — клиенты к дому тоже меняют требования порой с космической скоростью, только вот c такими никогда контракт не заключат,
IT>Потому что построить дом в таких условиях не получится, а софт написать можно.
Научимся формировать бизнес-правила четко, раз и на долго, то будет как и в строительстве, а внутренней перепланировкой будут заниматься уже другие люди.
AL>>то же и с бизнес-процессами, если на бизнес-уровне все грамотно и четко, то и до разработчиков будет спущен грамотный четкий чертеж на "дом" (средневековый), причем на каркас, а уж фенечки используя разработанные или уже имеющиеся инструменты будут доделывать. В этом направлении уже движутся многие продукты и с каждым годом их будет все больше, а надежность дойдет до уровня "небоскребов"
IT>Я сомневаюсь. Пока такой небоскрёб по спущенному грамотному чёткому чережу будет построен, то он уже успеет десять раз морально устареть и никому не будет нужен.
Правило 1-10-100 всем известно, так что надо учиться составлять требования таким образом, чтобы фундамент и каркас отвечали требованиям на 10 лет вперед, а уже перегородки будем менять в рамках заданных ограничений.
IT>Софтостроение кардинально отличается от других инженерных дисциплин одной принципиальной вещью — перманентным измением функциональных требований к системе на всех этапах проектирования и разработки. Если бы электронщики проектировали и конструировали свои системы как мы, то, боюсь, у них бы дело вообще далеко не ушло.
Модульная dataflow-центричная архитектура, основанная на (пере)сборке приложения из готовых, собранных и оттестированных, компонентов, как раз таки и позволяет перестраивать всю систему за считанные мгновения. А вот С++, в данном контексте, как раз и является злом. Хотя бы из-за времени компиляции, невозможности изоляции интерфейса от реализации в шаблоно-ориентированном коде. Про сложность интеграции компонентов от разных поставщиков я вообще молчу. А при отсутствии ABI вообще странно, как этот язык добрался до таких высот.
IT>Не стоит, всё равно ничего не получится.
Зачем же сразу так категорично? Идею я взял не из воздуха. Уже есть LabVIEW, SCADA-системы. IEC61131, наконец. Все они содержат графический конфигуратор и набор функциональных "кирпичей", дополняемый при желании на тех же С/С++/C#. Для своих задач языки более чем адекватные. Мешает проприетарность и закрытость форматов данных и спецификаций. Те же производители промышленных контроллеров лепят ни с чем не совместимые реализации IEC61131, чтобы затруднить миграцию клиентов на продукты других фирм. Я же хочу разработать систему, переносимую куда угодно (в рамках POSIX). В идеале, вплоть до микроконтроллеров.
Еще один пример — это всем известный COM. Архитектура модульная, независимая от расположения компонентов, с самодостаточными бинарными сборками, с многоязыкостью, с АГРЕГАЦИЕЙ, наконец... Сказка, одним словом, а не архитектура. Но только под винду, мать её. Что лично меня категорически не устраивает. И не надо начинать старую песню о главном, мол, 99% всех проектов нонче делаются под Windows. Для меня это ни капельки не аргумент. Так как приходится и под Линукс писать, и всяческие мелкие RTOSы использовать (а-ля uCOS), и вообще безосные проекты для ARM-контроллеров делать. И нисколько об этом не жалею — в своё время я сознательно ушёл из комфортного, теплого и убаюкивающего мира C#, SQL, поняв, что не моё это
Возвращаясь к своим баранам, то есть промышленным и экспериментально-физическим системам, могу высказаться на счёт PLC. Ничегошеньки аппаратно-сложного там нет. А деньги на этом рынке делаются внушительные. Все дело в удачных программных платформах, привязывающих клиента к себе (в силу своей проприетарности). Платформы эти, как правило, основаны на IEC61131. А IEC61131, если кто не знает, — это чисто инженерная подход в разработке АСУТП, безо всякого шаманства. В идеале, конечно — всё в мире не без огрехов. ВотЪ так.
PS. Не забывайте, что с повсеместным распространением FPGA программирование и электроника вообще сливаются в одну дисциплину. В перспективе, конечно.
Здравствуйте, iiice, Вы писали:
I>Есть идеи, как сделать так же, да лучше. СтОит ли браться?
Конечно стоит! И начать лучше с исследований. Статьи на эту тему написать. Это должно быть многим интересно, ну а походу может и выяснится — правильной ли дорогой идем...
Здравствуйте, Alexey Lan, Вы писали:
IT>>Потому что построить дом в таких условиях не получится, а софт написать можно. AL>Научимся формировать бизнес-правила четко, раз и на долго, то будет как и в строительстве,
В том-то всё и дело, что бизнесу не надо чётко и надолго. Правила ведения бизнеса не влияют на архитектуру зданий, в которых находится сам бизнес. А вот на архитектуру софта влияют очень сильно и непосредственно. Более того. Это то, за счёт чего бизнес может стать гибче и получить конкурентное преимущество.
IT>>Я сомневаюсь. Пока такой небоскрёб по спущенному грамотному чёткому чережу будет построен, то он уже успеет десять раз морально устареть и никому не будет нужен.
AL>Правило 1-10-100 всем известно, так что надо учиться составлять требования таким образом, чтобы фундамент и каркас отвечали требованиям на 10 лет вперед, а уже перегородки будем менять в рамках заданных ограничений.
Всё так. Только фундамент и каркас — это не модули и повторноиспользуемые компоненты, о которых говорит автор темы, а соответствующие технологии и качество уже существующего кода, которые позволяют относительно просто модифициаровать код под нужды бизнеса.
Неясность изложения обычно происходит от путаницы в мыслях.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, iiice, Вы писали:
I>Модульная dataflow-центричная архитектура, основанная на (пере)сборке приложения из готовых, собранных и оттестированных, компонентов, как раз таки и позволяет перестраивать всю систему за считанные мгновения.
Это заблуждение, которое даже не имеет смысла опровергать. Каждый бизнес имеет свою специфику, которой может элементарно не оказаться в готовых, собранных и оттестированных компонентах.
Вообще, существует два диаметрально противоположных вида программ, которые нам желательно не путать друг с другом, так как к ним предъявляются совершенно разные требования как при разработке, так и при эксплуатации. Это:
1. Фреймворки, библиотеки, стандартные компоненты и прочее повторно используемое хозяйство, которое предназначено исключительно для производства другого софта.
2. Конечные (бизнес) приложения.
В принципе, любой софт так или иначе находится где-то на линии, соединяющей эти две группы. Что касается первой группы, то с ней более менее всё понятно. Действительно, имеет смысл добиваться модульности, повторной используемости и прочего. Со временем такие библиотеки/компоненты утрясаются и могут даже, при определенной возможности их расщирения, не меняться и при этом приносить пользу достаточно долгое время.
А вот со второй группой не всё так просто. С этой группой не понятно что делать. Самое неправильное на мой взгляд, как раз попытка формализовать бизнес приложения и затолкать их в какие-то рамки. Это бессмысленно и бесполезно. Прежде всего это означает формализацию и ограничение самого бизнеса. Не существует двух одинаковых менеджеров, не существует двух компаний, ведущих одинаково один и тот же бизнес. Следовательно, не может существовать и двух одинаковых информационных систем, автоматизирующих такой бизнес. Практически всегда требуется индпошив.
Так стоит ли с этим бороться? Может быть гораздо разумнее повернуться к этому факту лицом и организовать соответствующим образом процессы производства бизнес софта?
Неясность изложения обычно происходит от путаницы в мыслях.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>В том-то всё и дело, что бизнесу не надо чётко и надолго. Правила ведения бизнеса не влияют на архитектуру зданий, в которых находится сам бизнес.
Влияют, ещё как влияют. Если нужно регулярно собирать по 200 человек в одном помещении, бывший жилой дом не годится — нужен кинотеатр или большая школа. Если нужен McDrive, нужно организовать машинную дорожку и окна для приёма/выдачи. И так далее.
И с "не надо чётко и надолго" Вы перегнули. Признайтесь, что просто не подумали:))
Обобщённо говоря, практически все попытки объяснения по аналогии, попавшие в этот тред, жестоко хромают.
IT>Всё так. Только фундамент и каркас — это не модули и повторноиспользуемые компоненты, о которых говорит автор темы, а соответствующие технологии и качество уже существующего кода, которые позволяют относительно просто модифициаровать код под нужды бизнеса.
Здравствуйте, iiice, Вы писали:
I>- Почему лучшие умы буквально с первых дней создания компьютеров бьются над проблемой создания языка, позволяющего проектировать программы по аналогии с созданием электронных схем, и всё без толку???
I>- Почему "электронщики" могут: I> — Создавать из электронных компонентов платы; I> — Оттестировав платы, не забивать себе голову деталями их реализации; I> — Создавать из плат крейты; I> — Оттестировав крейты, считать их работающими "чёрными ящиками"; I> — Создавать из крейтов — стойки, и т.д....
I> ...а программисты не могут?
Могут — ровно с таким же успехом. Одиночный электронный компонент можно сравнить с одной библиотечной функцией или группой функций некоторой мелкой подсистемы. Крейты — с крупными подсистемами. И так далее.
Этот этап развития, позволяющий вообще конструировать целое из частей, а полученное считать пригодным стать частью следующего, более крупного целого, пройден уже 50 лет назад. Тогда, когда появилось в теории понятие "системы команд исполнителя" и средства расширения этой системы команд введением разнообразных "подпрограмм" (позднее "функций"). Тем не менее идеальной картины не получилось потому, что сложность пошла дальше. Я подчеркнул.:)
Использование уже готового кода (AKA "повторное использование кода") в программировании — практика столь же древняя и почтенная, и с теми же результатами, как использование готовых элементов в схемотехнике. Когда её можно применять — так и делается. Когда нет — соответственно, нет. Но любой код, любой интерфейс вступает рано или поздно в противоречие с новыми требованиями. И тут в первую очередь влияет именно возможность переделки и лёгкость использования как переделанного, так и вообще другого. Если бы использовался подход, описанный Вами (я не говорю, заметьте, что это всегда подход электронщиков!) — работать было бы можно, и так часто и делают — например, когда стоит задача быстро собрать прототип, вылизывание затрат в котором непринципиально, а работать он должен "на вчера".
А теперь про электронику — несколько контрпримеров "из жизни". Первый. Мне вчера рассказали про один цискин модуль в свитч — 48 гигабитных медных портов. Модуль формально умеет пропускать гигабит по каждому порту. На практике оказывается, что у модуля 6 групп по 8 портов, и суммарная скорость в каждой не может превосходить гигабита. Наверно, на момент, когда только-только гигабитные порты появлялись, это было отличное решение — быстро и дёшево сделать поддержку _реального_ гигабита для тех немногих линков, которые несмотря на формальный коннект на гигабите реально от него используют дай бог чтобы 10%. Но когда он начинает использоваться в тяжёлой среде, где хоть и временно, но каждый линк может потребовать полную загрузку — начинаются провалы. А теперь скажите — годится ли мелкая переделка модуля для того, чтобы сделать его независящим от того, как сгруппировались линки? По-моему, нет — начнём с того, что потребуется внутримодульный кросс на хотя бы часть полной суммарной скорости, а это уже такие потоки, которые находятся на пределе возможностей современной электроники.
Второй — встроенные сетевухи, которые нынче на каждой материнской плате и которые успешно убивают так любимый мной рынок сетевух на ISA/PCI/etc. платах. Почему они меняются каждые полгода? Почему Asus вдруг стал поставлять никому почти не известный до того Attansic? Почему только Intel ставит интеловские сетевухи (чуть ли не единственные нормальные, как по мне)? И как Вы думаете, сколько трудился тот же Attansic для того, чтобы сделать чип, который на один несчастный доллар дешевле конкурентов? И куда делась вся предыдущая история тестирования старых решений?
Всё это я рассказываю для того, чтобы показать, что реальная жизнь существенно отличается от того, как Вы описали. Есть и соображения совсем не технические (как с заменой встроенных сетевух), и необходимости глобальной переделки. И то же самое и в программировании, настолько похоже, что как будто зеркало подставили! Есть, например, метод, который успешно работает до 1000 обрабатываемых элементов, но потом начинает слишком много хотеть памяти, потому что у него есть затрата O(N^3), хоть и с ничтожной константой. Значит — он не годится, надо заменять на другой. А другой будет хотеть для оптимальной работы другого метода управления (например, вместо загрузки по одному элементу — открыть операцию загрузки, набить по одному и затем закоммитить, а в промежутке они ещё не будут видны). Значит, начинается переделка дальше по цепочке...
Вот кстати родился ещё более прямой электронный пример (не буду уже переписывать предыдущее). Как Вам нравится переход ISA->PCI, PCI->PCI-E? А ведь первый был целой эпической трагедией, и второй через полгода окончательно даст то же самое. Много плат, которые нельзя перетащить в новые компьютеры несмотря на то, что отлично работают (кто-то про GUS плакался, а мне пришлось менять у клиента тип линка, потому что Cronyx Sigma 22 не переносилась). Глобальная переделка ядерных подложек работы с устройствами. Переделки драйверов. А сами платы? Те же сетевухи: Realtek 8019 — честный ISA'шный клон NE2000 (до сих пор производится для мелких железяк). 8029 — то же, но с PCI интерфейсом — и никакого больше изменения, но заставили — и пришлось практически выбросить уже готовое и часть делать заново. Потом 100Mbit — пришла 8139 (и сколько глюков там отгребли по миру, сложно подсчитать — а Вы говорите, что, мол, оттестировали и поехали)...
I>- Почему современное программирование по-прежнему напоминает смесь шаманства, искусства и кулинарии нежели инженерную дисциплину? :)
Потому что сложность того, что надо вложить, в разы и на порядки больше, а сложность каждого "вкладывания" самого по себе меньше. Общий механизм полностью тот же, а вот цены составляющих — разные. Заложив схему электронного устройства, Вы приняли значительно более дорогое и необратимое решение. Вам и в голову не придёт идея "через три месяца чтобы к этому чипу добавить функцию XXX и поддержку YYY"! — потому что аппаратное решение — у вас заложено как минимум на 2-3 года, и хорошо, если не 10. А от программистов — Вы будете этого требовать! — потому что знаете, что переделать код легче!
I>- Почему единожды написав и оттестировав программный компонент, процесс повторного использования оного во всех дальнейших проектах схожей тематики доводит программиста до кровавого геморроя? Особенно в С++!
Про C++ ничего тут не скажу, детали смотреть надо. А в общем случае — Вы дайте программистам на такой же объём логики столько же времени на разработку и тестирование. А не в десять раз меньше. И пообещайте им и особенно себе, что что бы ни происходило — следующий приступ работы над этим кодом будет не раньше чем через 3 года. Вот тогда и сравним результаты... что, не нравится?;))
I>Есть идеи, как сделать так же, да лучше. :super: СтОит ли браться? I>PS. Понимаю, что последний вопрос самый риторический.
Да нет, не риторический. Просто не пытайтесь бежать впереди паровоза.
N> Тогда, когда появилось в теории понятие "системы команд исполнителя" и средства расширения этой системы команд введением разнообразных "подпрограмм" (позднее "функций").
Одних только подпрограмм недостаточно для построения концептуально красивой архитектуры. Хорошо бы иметь "сопрограммы" (coroutines), обменивающиеся потоками данных. Средства С/С++ их напрямую не поддерживают. Приходтся извращаться с тредами и примитивами синхронизации.
Здравствуйте, iiice, Вы писали:
N>> Тогда, когда появилось в теории понятие "системы команд исполнителя" и средства расширения этой системы команд введением разнообразных "подпрограмм" (позднее "функций").
I>Одних только подпрограмм недостаточно для построения концептуально красивой архитектуры. Хорошо бы иметь "сопрограммы" (coroutines), обменивающиеся потоками данных. Средства С/С++ их напрямую не поддерживают. Приходтся извращаться с тредами и примитивами синхронизации.
I>- Не лучше ли использовать flow-driven-programming для больших, и тем более распределённых, программных систем. I> // Да, я конечно понимаю, что серебрянной пули не существует, и все существующие классы задач данным методом не решить. I> // Какие задачи удобно решать: системы DSP, SCADA, АСУТП, системы диагностики, сигнализации, и т.п.
Лучше. И именно для этих систем именно эти парадигмы и используются. Разговор, извиняюсь, ни о чем. То, что нет единой графической среды для создания приложений такого класса, ни о чем не говорит. Посмотрите, пожалуйста, на проект Ptolemy II — там есть все о чем вы сказали в своем посте. Вот список проектов в которых используется Ptolemy II. В проекте проработаны как теоретическая сторона (рассмотрены различные модели вычислений и гетерогенные системы на их основе), так и практическая сторона "САПР" и кодогенерация (в разных версиях поддерживается генерация в Java\C\VHDL). Языков, поддерживающих dataflow концепцию, также масса. Да, они не мейнстрим — потому что приложения, которые вы перечислили, мейнстрим и не составляют как раз.
Здравствуйте, netch80, Вы писали:
IT>>В том-то всё и дело, что бизнесу не надо чётко и надолго. Правила ведения бизнеса не влияют на архитектуру зданий, в которых находится сам бизнес.
N>Влияют, ещё как влияют. Если нужно регулярно собирать по 200 человек в одном помещении, бывший жилой дом не годится — нужен кинотеатр или большая школа. Если нужен McDrive, нужно организовать машинную дорожку и окна для приёма/выдачи. И так далее.
Ты хочешь сказать, что компании так же часто меняют свои здания, как и требования к софту?
N>И с "не надо чётко и надолго" Вы перегнули. Признайтесь, что просто не подумали
Я не просто подумал, я отвечал как архитектор за подобные системы, которые должны были гибко реагировать на изменения в бизнесе организации. И моя главная задача была не "софт надолго", а софт быстро и точно под нужды бизнеса.
N>Обобщённо говоря, практически все попытки объяснения по аналогии, попавшие в этот тред, жестоко хромают.
Да нормальная аналогия, просто ты на неё смотришь не с той стороны. Нужно смотреть на неё не в статике, а в динамике, и тогда сразу станет видно, что здания каждый день не меняются, а требования к софту легко, и что бизнес "софт надолго" — это тормоз в развитии самого бизнеса.
Неясность изложения обычно происходит от путаницы в мыслях.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>>>В том-то всё и дело, что бизнесу не надо чётко и надолго. Правила ведения бизнеса не влияют на архитектуру зданий, в которых находится сам бизнес. N>>Влияют, ещё как влияют. Если нужно регулярно собирать по 200 человек в одном помещении, бывший жилой дом не годится — нужен кинотеатр или большая школа. Если нужен McDrive, нужно организовать машинную дорожку и окна для приёма/выдачи. И так далее. IT>Ты хочешь сказать, что компании так же часто меняют свои здания, как и требования к софту?
Чтобы сносить и строить с нуля — нет. А чтобы сделать разную косметику — да. Глобальная замена всего кроме стен каждые три года — я уже столько раз наблюдал, что надоело.
N>>И с "не надо чётко и надолго" Вы перегнули. Признайтесь, что просто не подумали:)) IT>Я не просто подумал, я отвечал как архитектор за подобные системы, которые должны были гибко реагировать на изменения в бизнесе организации. И моя главная задача была не "софт надолго", а софт быстро и точно под нужды бизнеса.
Здравствуйте, iiice, Вы писали:
I>- Почему лучшие умы буквально с первых дней создания компьютеров бьются над проблемой создания языка, позволяющего проектировать программы по аналогии с созданием электронных схем, и всё без толку???
I>- Почему "электронщики" могут: I> — Создавать из электронных компонентов платы; I> — Оттестировав платы, не забивать себе голову деталями их реализации; I> — Создавать из плат крейты; I> — Оттестировав крейты, считать их работающими "чёрными ящиками"; I> — Создавать из крейтов — стойки, и т.д....
Если бы все было так радужно, то в электронное оборудование не встраивали бы процессоры и софт направо и налево. Я уже и затрудняюсь назвать чисто электронный (без софта) бытовой прибор. Может быть утюг только, да и то не факт Соответственно, программы не пишут по аналогии с разработкой электронных схем так как это дорого и не все, что хотелось бы можно сделать.
Здравствуйте, iiice, Вы писали:
I>Всем привет! И доброй пятницы!
I>У меня в голове назрело несколько полуриторических вопросов и соображений.
... I> ...а программисты не могут? I> // Оффтоп: Моё основное место работы — лаборатория экспериментальной ядерной физики, и я каждый день I> // вижу то, о чём говорю. Стили работы инженеров-разработчиков электронной аппаратуры и I> // программистов разнятся кардинально. Причём не в пользу последних.
...
ну почему не могут? Давно уже работа идет как у электронщиков, берем компоненты и соединяем, никто не пишет с нуля оконную систему,
подсистему ввода вывода, библиотеки логгирования и т.п. Почему все же много работы? Ну это зависит от предназначения готового кода.
Если это что-то типа .нет фреймворка или j2ee, то понятно что это очень универсальное средство и приходится проводить большие работы
по допиливанию напильником, если берем 1С или готовый движок игры и навешиваем на него, то что нужно, то объем работ естественно меньше,
чем если бы мы с нуля начали писать складскую программу или новую игру.
Hello, iiice!
You wrote on Fri, 05 Oct 2007 14:01:40 GMT:
i> — Почему современное программирование по-прежнему напоминает смесь i> шаманства, искусства и кулинарии нежели инженерную дисциплину?
Здесь уже верно сказали про постоянно изменяющиеся требования, что привносит львиную долю сложности.
Справедливости ради нужно отметить, что здесь не все так плохо. Workflow-системы разрабатываются еще с начала 80-х прошлого века и достигли зрелости. Это касается как самих движков, так и средств моделирования.
Зачем нужен workflow и как это помогает бороться с изменяющимися требованиями?
Не секрет, что бизнес-приложения очень часто разрабатываются с целью автоматизации бизнес-процессов. Особенно это касается областей, связанных с обработкой документов и различными процедурами рассмотрения и согласования: страхование, банки, customer service, etc. Workflow-система позволяет смоделировать такие процессы, выполнять их, заниматься мониторингом и главное — легко вносить изменения. Любая достойная система имеет графический дизайнер, который позволяет вносить изменения в процессы непосредственно бизнес-аналитику, т.е. программирование не требуется вообще.
Если мы добавим сюда еще какой-нибудь application framework, работающий поверх workflow-системы и добавляющий необходимые бизнес-сущности и графический интерфейс пользователя (а такие фреймворки делаются на ура), то мы получим отличное решение для process-centric бизнес-приложений.
Помимо этого, хорошие workflow-системы интегрируются с business rule engines. Это позволяет легко модифицировать определенную часть бизнес-логики, опять же без программирования.
Собственно, индустрия уже осознала преимущества такого подхода, о чем свидетельствует бурнорастущий рынок BPM (Business Process Management) систем. Ноги у них растут как раз из workflow-систем, только акцент делается на интеграцию и более крупный масштаб.
Здравствуйте, iiice, Вы писали:
I>Еще один пример — это всем известный COM. Архитектура модульная, независимая от расположения компонентов, с самодостаточными бинарными сборками, с многоязыкостью, с АГРЕГАЦИЕЙ, наконец... Сказка, одним словом, а не архитектура. Но только под винду, мать её. Что лично меня категорически не устраивает.
Здравствуйте, Сергей, Вы писали:
С>Кросс-платформенный COM есть — Mozilla XPCOM.
Это COM побная библиотека с сильно урезанным функционалом (по сравнению с виндовым)
"For every complex problem, there is a solution that is simple, neat,
and wrong."
Здравствуйте, Alexey Lan, Вы писали:
AL>Правило 1-10-100 всем известно, так что надо учиться составлять требования таким образом, чтобы фундамент и каркас отвечали требованиям на 10 лет вперед, а уже перегородки будем менять в рамках заданных ограничений.
Это нереально. В жизни я ни разу не видел, чтобы такой подход работал.
а) Если мы закладываемся на 10 лет вперед, разработка потребует слишком много времени, за это время конкуренты уже будут иметь огромное преимущество, разрабатывая систему итеративным способом, меняя требования по результатам тестов и опытной эксплуатации полученных в каждой итерации прототипов. Они закончат ее раньше, и к моменту выхода неопробованного монстра у них уже будет улучшенная версия 2.1.3
б) Когда мы закончим систему, мы неизбежно обнаружим, что эта перегородка не раздвигается, так как цепляется за шкаф, а чтобы передвинуть шкаф, нужно сломать стену.
СтОит ли браться?
Если нам не помогут, то мы тоже никого не пощадим.
), причем на каркас, а уж фенечки используя разработанные или уже имеющиеся инструменты будут доделывать. В этом направлении уже движутся многие продукты и с каждым годом их будет все больше, а надежность дойдет до уровня "небоскребов"
