Здравствуйте, 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
б) Когда мы закончим систему, мы неизбежно обнаружим, что эта перегородка не раздвигается, так как цепляется за шкаф, а чтобы передвинуть шкаф, нужно сломать стену.
А МВТУ пробовал.
Если нам не помогут, то мы тоже никого не пощадим.
