Хотелось бы найти хорошие книжки по проектированию ERP и просто сложных систем (я не про использование паттернов),а про общую архитектуру.
Т.е в каких местах имело бы смысл делать так или иначе и хотелось бы с примерами небольшими.как те или иные задачи лучше реализовывать
Здравствуйте, Аноним, Вы писали:
А>Хотелось бы найти хорошие книжки по проектированию ERP и просто сложных систем (я не про использование паттернов),а про общую архитектуру. А>Т.е в каких местах имело бы смысл делать так или иначе и хотелось бы с примерами небольшими.как те или иные задачи лучше реализовывать
У меня уже довольно давно складвается такое впечатление, что на хороших примерах нельзя научится хорошему дизайну, потому что хорошие примеры в других условиях могут стать плохими и даже самыми худшими из возможных, что неизбежно приведёт к когнитивному диссонансу индивида.
Изучение неудачных решений в этом смысле гораздо полезней, тем более, что ценность нашего опыта — это как раз не как надо делать, а как делать не надо.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Изучение неудачных решений в этом смысле гораздо полезней, тем более, что ценность нашего опыта — это как раз не как надо делать, а как делать не надо.
Согласен, моя практика тоже показывает, что знание того, как НЕ надо делать, гораздо ценнее. Потому что правильность подхода сложно предсказать заранее (ну если не считать типовые проекты, которых до этого уже наклепал порядочно, хотя и тут всё не столь очевидно).
Здравствуйте, koandrew, Вы писали:
K>Согласен, моя практика тоже показывает, что знание того, как НЕ надо делать, гораздо ценнее. Потому что правильность подхода сложно предсказать заранее (ну если не считать типовые проекты, которых до этого уже наклепал порядочно, хотя и тут всё не столь очевидно).
Осталось только найти соответствующую литературу.
Здравствуйте, Аноним, Вы писали:
А>Доброе время суток Господа.
А>Хотелось бы найти хорошие книжки по проектированию ERP и просто сложных систем (я не про использование паттернов),а про общую архитектуру. А>Т.е в каких местах имело бы смысл делать так или иначе и хотелось бы с примерами небольшими.как те или иные задачи лучше реализовывать
А>заранее благодарен за ссылки
С примерами про общую архитектуру, вряд ли найдете.
Здравствуйте, Аноним, Вы писали:
А>Хотелось бы найти хорошие книжки по проектированию ERP и просто сложных систем (я не про использование паттернов),а про общую архитектуру.
В одной хорошей книге (к своему стыду, не помню уже в какой) было сказано, что хорошую архитектуру нельзя создать изначально, она должна родиться в процессе решения задачи. Поэтому вооружайтесь общими принципами, паттернами и здравым смыслом... да прибудет с вами Сила!
IT>У меня уже довольно давно складвается такое впечатление, что на хороших примерах нельзя научится хорошему дизайну, потому что хорошие примеры в других условиях могут стать плохими и даже самыми худшими из возможных, что неизбежно приведёт к когнитивному диссонансу индивида.
Я думаю причина не в хороших примерах как таковых, а в дисбалансе между теорией и практикой. Если программист в свой профессиональной деятельности занимается простыми системами, то зачем ему читать про сложные системы. Как он на практике сможет применить эти знания? Теория без практики это мусор, балласт.
Еще проблема в авторитарном стиле мышления. Я часто сталкиваюсь с тем что программист в ответ на просьбу обосновать архитектурное решение, говорит что так надо делать, потому что так написано в интернете или книге. То есть не потому-что это нужно на данном проекте, а потому-что некий уважаемый дядя в своем блоге про это написал. На эту тему был топик http://www.rsdn.ru/forum/philosophy/5146953.1
Здравствуйте, Аноним, Вы писали:
А>Доброе время суток Господа.
А>Хотелось бы найти хорошие книжки по проектированию ERP и просто сложных систем (я не про использование паттернов),а про общую архитектуру. А>Т.е в каких местах имело бы смысл делать так или иначе и хотелось бы с примерами небольшими.как те или иные задачи лучше реализовывать
А>заранее благодарен за ссылки
Любая ERP состоит из двух элементов
1. Среда для разработки
2. Сама ERP система
Вы какую задачу решаете?
Здравствуйте, IT, Вы писали:
IT>У меня уже довольно давно складвается такое впечатление, что на хороших примерах нельзя научится хорошему дизайну, потому что хорошие примеры в других условиях могут стать плохими и даже самыми худшими из возможных, что неизбежно приведёт к когнитивному диссонансу индивида.
IT>Изучение неудачных решений в этом смысле гораздо полезней, тем более, что ценность нашего опыта — это как раз не как надо делать, а как делать не надо.
Ценность опыта это
1 свойства различных решений и их комбинаций, т.е. возможности и ограничения
2 требования в различных семействах задач
На одном "как не надо делать" далеко не уедешь, потому что это не дает ответа "как надо". Более того, недостаточно знать удачные примеры и неудачные, т.к. в конкретной задаче требования и ограничения могут быть уникальными. Соответственно "как надо" вытекает из анализа требований, возможностей и ограничений.
Здравствуйте, Ikemefula, Вы писали:
I>Ценность опыта это I>1 свойства различных решений и их комбинаций, т.е. возможности и ограничения I>2 требования в различных семействах задач
Можно пояснить? Пока это звучит как нечно псевдо умное и ровным счётом ничего не значащее.
I> На одном "как не надо делать" далеко не уедешь, потому что это не дает ответа "как надо". Более того, недостаточно знать удачные примеры и неудачные, т.к. в конкретной задаче требования и ограничения могут быть уникальными. Соответственно "как надо" вытекает из анализа требований, возможностей и ограничений.
К сожалению, требования, возможности и ограничения можно заранее проанализировать только для задач в сферическом вакууме. В жизни это получается сделать только, когда задача уже решена, либо очень близка к завершению.
... << RSDN@Home 1.2.0 alpha 5 rev. 69>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
I>>Ценность опыта это I>>1 свойства различных решений и их комбинаций, т.е. возможности и ограничения I>>2 требования в различных семействах задач
IT>Можно пояснить? Пока это звучит как нечно псевдо умное и ровным счётом ничего не значащее.
Наборот, удачное решение, неудачное — это ни о чем не говорит, это просто эмоциональные ярлыки. Эффект решения слишком часто маскируется успехом-неудачей самого продукта или политикой внутри конторы. Свойсвта решения это расход ресурсов, особенности взаимосдействия с другими модулями и тд и тд.
Ограничения в каждом семействе задач более менее известны. Скажем если ты делаешь UI, то совершенно очевидно, есть время отклика интерфейса, хотя оно как правило нигде и не озвучивается специально.
А если ты вдруг решишь полезть поближе железом, то появится более жосткое ограничение как время отклика системы. А если пишешь сетевое приложение, то ограничениями будет например пропускная способность.
I>> На одном "как не надо делать" далеко не уедешь, потому что это не дает ответа "как надо". Более того, недостаточно знать удачные примеры и неудачные, т.к. в конкретной задаче требования и ограничения могут быть уникальными. Соответственно "как надо" вытекает из анализа требований, возможностей и ограничений.
IT>К сожалению, требования, возможности и ограничения можно заранее проанализировать только для задач в сферическом вакууме. В жизни это получается сделать только, когда задача уже решена, либо очень близка к завершению.
Возможности и ограничения, как минимум часть, известны для каждого используемого инструмента, или тебе лично, или другим, кто их пробовал. Требования никогда не приходят в виде "сделай шоб усё было хорошо". Как правило проектировщик их сам же и уточняет разными способами, вплоть до непосредственной работы с заказчиком, помогая сформулировать проблему и желаемый результат. Потому не ясно, как ты работаешь до того, как задача стала близка к завершению
Скажем имея такой инструмент как GC, худо бедно известны его свойства и ограничения. По требованиям к конкретной задаче можно построить более-менее адекватную модель и посмотреть, вписываются ли ограничения этой модели в ограничения GC. Если не вписываются, то решение на GC гарантировано не взлетит и незачем ждать конца проекта, что бы убедиться в этом. Когда требования меняются, очевидно, нужно перепроверять все такие конфликты. Например кастомер в любой момент может сказать "я хочу в 100 раз больше данных на клиенте".
Естественно, некоторые свойства могут быть неизвестны. Тогда берешь профайлер, исследуешь свойство GC в конкретном проекте ("и их комбинаций")и у тебя появляются внятные ограничения. Сравниваешь их с теми требованиями, что есть на данный момент и делаешь вывод, куда двигаться дальше. Взамен получаешь опыт — свойства, возможности решений и требования в некотором семействе задач.
Здравствуйте, koandrew, Вы писали:
K>Согласен, моя практика тоже показывает, что знание того, как НЕ надо делать, гораздо ценнее. Потому что правильность подхода сложно предсказать заранее (ну если не считать типовые проекты, которых до этого уже наклепал порядочно, хотя и тут всё не столь очевидно).
"Как надо" сужает пространство всех возможных решений(которое бесконечно) до пары десятков. "как не надо" помогает отфильтровать уже эти возможные решения. При этом, без рассмотрения хотя бы приблизительных требований, и то и другое смысла не имеет.
Скажем, для веб приложения одна фраза кастомера "... в будущем году я перевожу операторов с веба на планшеты и смартфоны всех сортов" резко меняет вообще всё, и возможно вплоть до серверной части. Например может оказаться так, что стек .NET окажется слишком дорогим.
Здравствуйте, Ikemefula, Вы писали:
I>Наборот, удачное решение, неудачное — это ни о чем не говорит, это просто эмоциональные ярлыки. Эффект решения слишком часто маскируется успехом-неудачей самого продукта или политикой внутри конторы. Свойсвта решения это расход ресурсов, особенности взаимосдействия с другими модулями и тд и тд.
неудачные решения очень даже бывают.
т.е. в начале проекта принимается решение, а к концу становится очевидно, что была проделана бесполезная работа и что последствия этого решения пожирают время и силы программистов, и переделывать уже некогда (как бы нибудь донести эту хрень до релиза, а только потом избавляться)
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Философ, Вы писали:
I>>Наборот, удачное решение, неудачное — это ни о чем не говорит, это просто эмоциональные ярлыки. Эффект решения слишком часто маскируется успехом-неудачей самого продукта или политикой внутри конторы. Свойсвта решения это расход ресурсов, особенности взаимосдействия с другими модулями и тд и тд.
Ф>неудачные решения очень даже бывают. Ф>т.е. в начале проекта принимается решение, а к концу становится очевидно, что была проделана бесполезная работа и что последствия этого решения пожирают время и силы программистов, и переделывать уже некогда (как бы нибудь донести эту хрень до релиза, а только потом избавляться)
Я даже больше скажу — у нас был случай, когда решение (логически хорошее на момент принятия) было принято при разработке системы (скоростной распределенный доступ к MS SQL вместо единой точки) и потом с последствиями (водопад дедлоков) этого боролись лет 10 (и конца-края все еще не видно) во всех прочих релизах новых версий. То есть даже избавиться от ошибки не удалось потому как тогда меняется архитектура и теряется совместимость.
Здравствуйте, Ikemefula, Вы писали:
I>Наборот, удачное решение, неудачное — это ни о чем не говорит, это просто эмоциональные ярлыки. Эффект решения слишком часто маскируется успехом-неудачей самого продукта или политикой внутри конторы. Свойсвта решения это расход ресурсов, особенности взаимосдействия с другими модулями и тд и тд.
Если быть честным с самим собой и при оценки удачности оперировать только объективными факторами, то удачность/неудачность вполне можно обнаружить, описать, проанализировать и сделать выводы. В моей, теперь уже можно сказать, практически бывшей конторе мы неоднократно проводили эксперименты по применению разных технологий для различных задач с последующим анализом и разбором полётов именно удачности решения. Никаких эмоций, чёткие факты и их анализ.
I>Возможности и ограничения, как минимум часть, известны для каждого используемого инструмента, или тебе лично, или другим, кто их пробовал. Требования никогда не приходят в виде "сделай шоб усё было хорошо". Как правило проектировщик их сам же и уточняет разными способами, вплоть до непосредственной работы с заказчиком, помогая сформулировать проблему и желаемый результат. Потому не ясно, как ты работаешь до того, как задача стала близка к завершению
В жизни и заказчик и разработчик тяготеет как раз к "сделай шоб усё было хорошо". И в этом нет ничего плохого, если разработчик изначально строит архитектуру проекта так, чтобы в любой момент быть готовым её существенно изменить. Здесь как раз и важен отрицательный опыт, который отрезает заведомо плохие пути. А вот заведомо хороших, к сожалению не бывает, если не решается типовая задача.
... << RSDN@Home 1.2.0 alpha 5 rev. 69>>
Если нам не помогут, то мы тоже никого не пощадим.
IT>Здесь как раз и важен отрицательный опыт, который отрезает заведомо плохие пути. А вот заведомо хороших, к сожалению не бывает, если не решается типовая задача.
Вот стоит задача выбрать архитектурное решение. На рассмотрение было подано 10 вариантов. Используя знания "как не надо" можно отсечь 5 вариантов. Используя знания "как надо" нужно выбрать лучший вариант из 5-ти оставшихся.
Можно конечно знать только "как надо", но знать нужно будет очень хорошо, так как придется выбирать лучший вариант уже не 5-ти вариантов, а из 10-ти.
Можно знать только "как не надо", только если знать очень хорошо, то можно забраковать все 10-вариантов, так и выбрав лучшего.
Получается как жизни одинаково важно иметь и положительный и отрицательный опыт: одинаково важно знать и как надо и как не надо.
Если у человека будет дисбаланс знаний "как надо" и "как не надо" или совокупный их недостаток, то он может столкнуться с проблемой Буриданова осла http://ru.wikipedia.org/wiki/%D0%91%D1%83%D1%80%D0%B8%D0%B4%D0%B0%D0%BD%D0%BE%D0%B2_%D0%BE%D1%81%D1%91%D0%BB
Здравствуйте, Философ, Вы писали:
Ф>Здравствуйте, Ikemefula, Вы писали:
I>>Наборот, удачное решение, неудачное — это ни о чем не говорит, это просто эмоциональные ярлыки. Эффект решения слишком часто маскируется успехом-неудачей самого продукта или политикой внутри конторы. Свойсвта решения это расход ресурсов, особенности взаимосдействия с другими модулями и тд и тд.
Ф>неудачные решения очень даже бывают. Ф>т.е. в начале проекта принимается решение, а к концу становится очевидно, что была проделана бесполезная работа и что последствия этого решения пожирают время и силы программистов, и переделывать уже некогда (как бы нибудь донести эту хрень до релиза, а только потом избавляться)
Здравствуйте, qlat, Вы писали:
Q>Здравствуйте, Аноним, Вы писали:
А>>Доброе время суток Господа.
А>>Хотелось бы найти хорошие книжки по проектированию ERP и просто сложных систем (я не про использование паттернов),а про общую архитектуру. А>>Т.е в каких местах имело бы смысл делать так или иначе и хотелось бы с примерами небольшими.как те или иные задачи лучше реализовывать
А>>заранее благодарен за ссылки
Q>Любая ERP состоит из двух элементов Q>1. Среда для разработки Q>2. Сама ERP система Q>Вы какую задачу решаете?
Написать проблем не составляет,написать грамотно,а вот тут уже задумываешься.
Как и говорили про отклик UI.
1)Никогда ранее не заморачивался но при работе с бд при плохой связи подвисает UI, использовать просто Thread ? или ThreadPool или таски чтобы не вешать UI(приложение не отвечает) на некоторых запросах ?
2)Больше хочется понять какие процедуры лучше бы перенести на сторону SQL сервера, описав их в TSQL,а какие раскидать по dll, — на чём обьективно основывать этот выбор ?
3)В некоторых вариантах развития ситуации возможно что система будет обрастать отчетами, как лучше реализовать связку данных с отчетом чтобы не пихать это всё в основной проект,а разнести это по dll(тут более интересен чей нибудь опыт)
Архитектуру я могу выстроить и "сделать чтобы работало", но к сожалению меня это перестало удовлетворять,я хочу делать более грамотно и красиво с точки зрения разработчика.
Я понимаю что это все должно прийти с опытом,но к сожалению мне только года 2-3 назад довелось только дорабатывать 1 ERP,а в данный момент задачи стоят другие,но интерес не угасает.
Очень благодарен за ваше понимание и любой ваш бесценный опыт!
Если нам не помогут, то мы тоже никого не пощадим.
