Здравствуйте, Аноним, Вы писали:
А>Хотелось бы найти хорошие книжки по проектированию ERP и просто сложных систем (я не про использование паттернов),а про общую архитектуру. А>Т.е в каких местах имело бы смысл делать так или иначе и хотелось бы с примерами небольшими.как те или иные задачи лучше реализовывать
У меня уже довольно давно складвается такое впечатление, что на хороших примерах нельзя научится хорошему дизайну, потому что хорошие примеры в других условиях могут стать плохими и даже самыми худшими из возможных, что неизбежно приведёт к когнитивному диссонансу индивида.
Изучение неудачных решений в этом смысле гораздо полезней, тем более, что ценность нашего опыта — это как раз не как надо делать, а как делать не надо.
Если нам не помогут, то мы тоже никого не пощадим.
Re[2]: реализация \ проектирование приложений
От:
Аноним
Дата:
24.07.13 21:46
Оценка:
Здравствуйте, 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,а в данный момент задачи стоят другие,но интерес не угасает.
Очень благодарен за ваше понимание и любой ваш бесценный опыт!
Здравствуйте, Ikemefula, Вы писали:
I>Критерий успешности какой ?
Общая сложность решения.
I>Какие гипотезы выносятся в эксперимент и что именно тебе дают результаты ?
Главный результат — опыт применения той или иной технологии, заключающийся главным образом в выявлении её недостатков и ограничений.
I>Мне кажется ты изобретаешь теорию принятия решений. Отрицательный опыт и положительный ничем не помогут в новой задаче.
Т.е. по-твоему любой опыт бесполезен? В принципе, если свой опыт совсем не анализировать, то я с тобой согласен. Но это не мой случай.
I>То есть, выходит так, что успешно-неуспешно тянет неявно определенный и очень жосткий контекст и все утверждения привязаны к этому конктексту.
Я объясню, почему отрицательный опыт более ценный и почему он помогает в дальнейшем отсекать заведом неверные решения. Дело в том, что неправильное решение гораздо проще проанализировать и выявить причины неуспешности. Вдумчивый анализ даёт довольно точный и главное ограниченный список этих самых причин. А вот успешное решение ограниченного списка причин успешности не имеет, этот список бесконечен. Это как ходьбы оп минному полю. Есть ограниченное число мест, где находятся мины и куда не стоит идти, а вот путей их обхода, если знать где они находятся, бесконечное множество.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, igor-booch, Вы писали:
IB>Бухгалтерия это часть ERP
Да.
IB>причем центральная
Нет. Центральная часть, о чем недвусмысленно говорит название, это планирование ресурсов. А бухгалтерия это не планирование, это пост-фактум отчетность.
IB>Продуктом работы любого модуля (например закупки, продажи, склад) могут быть бухгалтерские проводки.
Уверен? Даже если взять типовые конфигурации 1С, то упомянутый тобой склад никаких бухгалтерских проводок не формирует, там свои собственные регистры. А серьезные ERP системы про сравнению с типовыми конфигурациями 1С, это примерно как авиалайнер рядом с велосипедом.
IB>Модуль склад есть точно в Axapta
И чего? Он много где есть.
IB>По моим оценкам 50 — 60% среднего и малого бизнеса достаточно стандартной функциональности модуля Склад.
Ах по твоим оценкам. Ну тогда сдаюсь.
IB>Только русские заказчики всегда стремятся прогнуть систему под себя
Это делают все, кто хочет быть конкурентоспособным. А вот кто вместо прогибания софта под бизнес, или просто подбора достаточно гибкого софта, наоборот бизнес под софт прогибает, те обычно печально заканчивают.
AVK>>стандартная логика какого нибудь отраслевого решения, она с неба падает или все таки кто то ее пишет? IB>Пишет Microsoft
И? Он при этом аксаптовым инструментарием не пользуется, пишет все в блокноте?
IB>на консалтинговые компании, которые занимаются внедрением Axapta она "падает с неба", если можно так выразиться
Кого в этом топике волнуют те, кто занимается внедрением? Средства разработки не для них создаются, а для тех кто делает прикладные решения. Если ты когда то там у какого то внедренца подпиливал стандартные конфигурации, это вовсе не означает что это единственная или даже основная аудитория средств разработки ERP платформ. В Парусе, к примеру, вообще таких людей, как у 1С, массовых допильщиков стандартных конфигураций, вообще нет. А конкретно в упомянутом тут Парус 10 на данный момент под релизную платформу собрать решение можно только на серверах Паруса. Бизнес у всех поставщиков ERP решений разный, не стоит под одну гребенку всех кто в этом секторе работает равнять.
... << RSDN@Home 1.2.0 alpha 5 rev. 100 on Windows 8 6.2.9200.0>>
Здравствуйте, Ikemefula, Вы писали:
IT>>Я не знаю метрик, которые можно было бы использовать для формальной оценки сложности. Если ты про это. I>А как же тогда общую сложность решения оценивать ?
На больше / меньше.
I>>>По моему надо акцентироваться не на ярлыках, а на возможностях и свойствах решений. IT>>Я не понимаю что ты подразумеваешь под возможностями и своствами решений. I>На примере твоего БЛТ — возможности это просто фичи, большие и маленькие. А быстродействие, расход памяти и прочие вещи — это свойства.
И какое это всё имеет отношение к правильности принятых решений. Вот например следующее имеет самое непосредственное отношение. На примере моего БЛТ можно сказать, что SqlBuilder в нём спроектирован неудачно, т.к. в одном месте намешалось AST для SQL, оптимизации этого AST и средства его конструирования. В результате получилась довольно негибкая архитектура, что в конце концов не лучшим образом повлияла на некоторые решения в дальнейшем. Т.е. имеет место быть самый настоящий отрицательный опыт с чётким пониманием того почему так делать не надо. А то, о чём ты говоришь — это есть функциональные и нефункцианальные требования, которые к обсуждаемой теме вообще не имеют никакого отношения.
I>Вроде как по мелочи, но оказывается, что удачный опыт какой то не совсем удачный, без конкретного контекста его вообще невозможно реюзать.
Именно это я и пытаюсь донести с самого моего первого сообщения в этом топике.
... << RSDN@Home 1.2.0 alpha 5 rev. 69>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Ikemefula, Вы писали:
IT>>На больше / меньше. I>Значит у тебя есть какие то метрики, только ты стесняешься их показать
Я такой стеснительный.
I>То есть, "намешалось AST для SQL, оптимизации этого AST и средства его конструирования" и "негибкая архитектура" ты почему то не можешь рассматриват как свойство BLT. Вопрос — почему ?
Это не свойство, это — косяк. Ещё раз объясняю, свойства о которых ты говоришь — это функциональные и нефункциональные требования к задаче. Сложность, успешность и неуспешность решения к этому не имеют отношения, т.к. одно и тоже свойство может быть реализовано как хорошо, так и плохо, может требовать кучу ресурсов, а может расходовать их очень оптимально.
IT>>Именно это я и пытаюсь донести с самого моего первого сообщения в этом топике. I>Насколько я понял, "неудачный опыт" судя по примеру БЛТ это просто некоторые ограничения == свойства в конкретном контексте. И вот как то странно искать решение руководствуясь одними лишь ограничениями
По-моему, ты зациклился на своих свойсвах и пытаешь подменить одно понятие другим, чтобы объяснить для себя непонятное в более привычных терминах. Из этой подмены ничего не получается, но в результате ты сваливаешь свои проблемы на оригинальные утверждения.
... << RSDN@Home 1.2.0 alpha 5 rev. 69>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
I>>То есть, "намешалось AST для SQL, оптимизации этого AST и средства его конструирования" и "негибкая архитектура" ты почему то не можешь рассматриват как свойство BLT. Вопрос — почему ?
IT>Это не свойство, это — косяк. Ещё раз объясняю, свойства о которых ты говоришь — это функциональные и нефункциональные требования к задаче.
"намешалось AST для SQL, оптимизации этого AST и средства его конструирования" и "негибкая архитектура" — вот это свойства(втч). Если ты считаешь что это функциональные и нефункциональные требования к твоему BLT, так и говори.
>Сложность, успешность и неуспешность решения к этому не имеют отношения, т.к. одно и тоже свойство может быть реализовано как хорошо, так и плохо, может требовать кучу ресурсов, а может расходовать их очень оптимально.
Расход ресурсов вдруг перестал быть свойством ?
IT>По-моему, ты зациклился на своих свойсвах и пытаешь подменить одно понятие другим, чтобы объяснить для себя непонятное в более привычных терминах. Из этой подмены ничего не получается, но в результате ты сваливаешь свои проблемы на оригинальные утверждения.
А по моему ты изобретаешь уже давно известную теорию.
реализация \ проектирование приложений
От:
Аноним
Дата:
19.07.13 13:07
Оценка:
Доброе время суток Господа.
Хотелось бы найти хорошие книжки по проектированию 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>>Наборот, удачное решение, неудачное — это ни о чем не говорит, это просто эмоциональные ярлыки. Эффект решения слишком часто маскируется успехом-неудачей самого продукта или политикой внутри конторы. Свойсвта решения это расход ресурсов, особенности взаимосдействия с другими модулями и тд и тд.
Ф>неудачные решения очень даже бывают. Ф>т.е. в начале проекта принимается решение, а к концу становится очевидно, что была проделана бесполезная работа и что последствия этого решения пожирают время и силы программистов, и переделывать уже некогда (как бы нибудь донести эту хрень до релиза, а только потом избавляться)
Здравствуйте, Аноним, Вы писали:
А>Доброе время суток Господа.
А>Хотелось бы найти хорошие книжки по проектированию ERP и просто сложных систем (я не про использование паттернов),а про общую архитектуру. А>Т.е в каких местах имело бы смысл делать так или иначе и хотелось бы с примерами небольшими.как те или иные задачи лучше реализовывать
А>заранее благодарен за ссылки
Здравствуйте, IT, Вы писали:
IT>Если быть честным с самим собой и при оценки удачности оперировать только объективными факторами, то удачность/неудачность вполне можно обнаружить, описать, проанализировать и сделать выводы. В моей, теперь уже можно сказать, практически бывшей конторе мы неоднократно проводили эксперименты по применению разных технологий для различных задач с последующим анализом и разбором полётов именно удачности решения. Никаких эмоций, чёткие факты и их анализ.
Критерий успешности какой ? Какие гипотезы выносятся в эксперимент и что именно тебе дают результаты ?
I>>Возможности и ограничения, как минимум часть, известны для каждого используемого инструмента, или тебе лично, или другим, кто их пробовал. Требования никогда не приходят в виде "сделай шоб усё было хорошо". Как правило проектировщик их сам же и уточняет разными способами, вплоть до непосредственной работы с заказчиком, помогая сформулировать проблему и желаемый результат. Потому не ясно, как ты работаешь до того, как задача стала близка к завершению
IT>В жизни и заказчик и разработчик тяготеет как раз к "сделай шоб усё было хорошо". И в этом нет ничего плохого, если разработчик изначально строит архитектуру проекта так, чтобы в любой момент быть готовым её существенно изменить. Здесь как раз и важен отрицательный опыт, который отрезает заведомо плохие пути. А вот заведомо хороших, к сожалению не бывает, если не решается типовая задача.
Мне кажется ты изобретаешь теорию принятия решений. Отрицательный опыт и положительный ничем не помогут в новой задаче. А вот знания возможностей и свойств инструментов наоборот, помогают и в новых задачах. И анализ требований на предмет выявляения ограничений так же поможет в новых задачах.
Скажем, в небольших приложениях не надо думать за GC, более того, не надо помогать ему, достаточно научиться занулять ссылки. В высоконагруженых приложениях и задачх реального режима времени все наоборот, надо не только помогать GC, но и думать за GC . Отсюда неудивительно видеть heapless кеширование и тд.
Если опираться только на негативный опыт, придется всунуть в реалтайм-ядро все плюшки GC, получить по лбу раз пятьсот и потом записать старый негативный опыт в позитивный. А буде случится вернуться на обычные веб-приложения — проделать все в обратном порядке.
При этом, если отталкиваться от возможностей и свойств, можно обнаружить, что GC имеет ряд вещей, которые сильно недетерминированы. Например невозможно предсказать, сколько будет работать этот GC в конкретном случае. Время отклика этого GC цифры ни о чем. Если сравнивать это с требованиями реалтайма, то, внезапно, еще до начала разработки есть целый ряд конфликтов и heapless решение нарисуется само собой. А вот уже дальше помогает негативный опыт — из всех heapless решений выбросить неудачные.
То есть, выходит так, что успешно-неуспешно тянет неявно определенный и очень жосткий контекст и все утверждения привязаны к этому конктексту. Человеку не в теме будет просто непонятно, как реюзать твой опыт. А если фокусироваться на возможностях и свойствах, то как минимум твой опыт будет реюзабельным самим собой даже в новых задачах.
Здравствуйте, Poul_Ko, Вы писали:
P_K>Здравствуйте, Аноним, Вы писали:
А>>Хотелось бы найти хорошие книжки по проектированию ERP и просто сложных систем (я не про использование паттернов),а про общую архитектуру.
P_K>В одной хорошей книге (к своему стыду, не помню уже в какой) было сказано, что хорошую архитектуру нельзя создать изначально, она должна родиться в процессе решения задачи. Поэтому вооружайтесь общими принципами, паттернами и здравым смыслом... да прибудет с вами Сила!
В книге Гради Буча это сказано, хотя наверняка не только в ней, а в любой книге, ведь это одно из фундаментальных свойств хорошой архитектуры — ее просто невозможно сделать такой с нуля. Даже если имеется иллюзия что некая архитектура получилось удачной с нуля, скорее всего просто был использован богатый опыт (сын ошибок трудных) других архитекторов, работавших над этой проблемой ранее.
А насчет ERP, то Фаулер тут вне конкуренции, правда некоторые его книги ужасно переведены на русский.
Здравствуйте, vl690001x, Вы писали:
V>А насчет ERP, то Фаулер тут вне конкуренции, правда некоторые его книги ужасно переведены на русский.
У него и контент ужасен, он устарел на 5 лет примерно. Описывает по сути реалии начала-середины 90-х годов, сегодня уже и проблем нет, которые он решает.
К сожалению ему альтернативы нет. Нету книг по современной архитектуре, приходится на практике все изучать.
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, 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,а в данный момент задачи стоят другие,но интерес не угасает. А>Очень благодарен за ваше понимание и любой ваш бесценный опыт!
1. Если для Вас написать в лоб проблем не составляет, то Вы уникальны, я хорошо знаю Axapta (около 9 лет в ней работал), и точно бы не смог реализовать всю логику системы (бухгалтерию, склад, производство, сводное планирование, расчеты с клиентами, зарплату и кадры, crm и т.д. )
2. обычно ERP работают с несколькими базами, поэтому у них свой язык (это касается среды разработки), ERP системы 3-х уровневые: клиент, серверная логика (пишется не на языке базы данных) и база данных (без sql — процедур). Логика ERP систем не содержится в dll-ках.
3. внутри среды разработки свой генератор отчетов, перед тем как его сделать, лучше создать среду для разработки.
Я сейчас как раз пишу среду для разработки, может через 2 месяца выложу результат работы. Первый вариант будет простой и двухуровневый (клиент + база), в качестве примера перенесу логику 1С 7-ки.
Базы SQL, Access, IB.
: IB>>1 вариант стоит 200$ капитальных затрат, 15$\месяц эксплуатационных IB>>2 вариант стоит 300$ капитальных затрат, 20$\месяц эксплуатационных
I>Девелопер таких вещей никогда не видит. У девелопера критерии свои, у тимлида — свои, у менеджера — свои, у сейлс — свои, у тестера — свои.
Вот очень плохо если не видят.
На самом деле видят все, только под ресурсом понимают разные вещи.
У девелопера — ресурс это его собственное время потраченное на решение задачи
У тимлида — ресурс это сумма времен всех девелоперов команды
У манагера — ресурс это деньги
В конечном итоге все ресурсы имеют денежный эквивалент.
Сейлсы и тестеры не должны принимать решения по технической реализации задачи. Их я не рассматриваю.
Здравствуйте, qlat, Вы писали:
Q>Здравствуйте, Аноним, Вы писали:
А>>Здравствуйте, 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,а в данный момент задачи стоят другие,но интерес не угасает. А>>Очень благодарен за ваше понимание и любой ваш бесценный опыт!
Q>1. Если для Вас написать в лоб проблем не составляет, то Вы уникальны, я хорошо знаю Axapta (около 9 лет в ней работал), и точно бы не смог реализовать всю логику системы (бухгалтерию, склад, производство, сводное планирование, расчеты с клиентами, зарплату и кадры, crm и т.д. )
Q>2. обычно ERP работают с несколькими базами, поэтому у них свой язык (это касается среды разработки), ERP системы 3-х уровневые: клиент, серверная логика (пишется не на языке базы данных) и база данных (без sql — процедур). Логика ERP систем не содержится в dll-ках.
Q>3. внутри среды разработки свой генератор отчетов, перед тем как его сделать, лучше создать среду для разработки.
Q>Я сейчас как раз пишу среду для разработки, может через 2 месяца выложу результат работы. Первый вариант будет простой и двухуровневый (клиент + база), в качестве примера перенесу логику 1С 7-ки. Q>Базы SQL, Access, IB.
1)предприятия бывают разные.
2)про 3-х уровненную систему интересно,а почему логику реализовывают именно на сервере,а клиентов цепляют к серверу,к чему такая сложность?для некоторых этот вопрос покажется естественным,но всё-же хотелось бы узнать...
я так понимаю есть
для какой цели?
ведь добавляя новый функционал к системе придется обновлять и сервер и клиентов.
Какие преимущества хранения логики на процессинговом сервере?
Здравствуйте, igor-booch, Вы писали:
IB>Вот очень плохо если не видят.
Надо полагать тебе как девелоперу отчитываются обо всех издержках, я ж не в курсе.
IB>На самом деле видят все, только под ресурсом понимают разные вещи. IB>У девелопера — ресурс это его собственное время потраченное на решение задачи IB>У тимлида — ресурс это сумма времен всех девелоперов команды IB>У манагера — ресурс это деньги IB>В конечном итоге все ресурсы имеют денежный эквивалент.
Это слишком упрощенно, что бы можно было хоть как то применять.
IB>Сейлсы и тестеры не должны принимать решения по технической реализации задачи. Их я не рассматриваю.
Девелопер — затратил на фичу два дня, всё палит.
Тимлид — сорганизовал команду что бы найти решение, которое реализуется в два дня.
Тестеры говорят — протестировать фичу надо два года в пересчете на одного человека. Затраты девелоперов после этого никому не интересны.
Сейлсы приходят и говорят — ваша классная реализация никому не нужна, денег не будет. Считаем эффект — денег 0, затрат вагон, эффект == 0.
Ну если никто с друг с другом разговаривать не будет, то картина у всех конечно будет разная.
Управление проектом (и система коммуникаций на проекте в частности) на это и направлено
чтобы у всех была единая картина,
чтобы действия всех работников были согласованы.
Если руководители для этого не предпринимают усилий, то команда развалится, в независимости от того что будет считаться критерием успешности
Здравствуйте, igor-booch, Вы писали:
I>>Итого — у всех разная картина.
IB>Ну если никто с друг с другом разговаривать не будет, то картина у всех конечно будет разная.
Понял. Наверное перед тобой сам гендир отчитывается. Завидую.
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, qlat, Вы писали:
Q>>Здравствуйте, Аноним, Вы писали:
А>>>Здравствуйте, 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,а в данный момент задачи стоят другие,но интерес не угасает. А>>>Очень благодарен за ваше понимание и любой ваш бесценный опыт!
Q>>1. Если для Вас написать в лоб проблем не составляет, то Вы уникальны, я хорошо знаю Axapta (около 9 лет в ней работал), и точно бы не смог реализовать всю логику системы (бухгалтерию, склад, производство, сводное планирование, расчеты с клиентами, зарплату и кадры, crm и т.д. )
Q>>2. обычно ERP работают с несколькими базами, поэтому у них свой язык (это касается среды разработки), ERP системы 3-х уровневые: клиент, серверная логика (пишется не на языке базы данных) и база данных (без sql — процедур). Логика ERP систем не содержится в dll-ках.
Q>>3. внутри среды разработки свой генератор отчетов, перед тем как его сделать, лучше создать среду для разработки.
Q>>Я сейчас как раз пишу среду для разработки, может через 2 месяца выложу результат работы. Первый вариант будет простой и двухуровневый (клиент + база), в качестве примера перенесу логику 1С 7-ки. Q>>Базы SQL, Access, IB.
А>1)предприятия бывают разные.
А>2)про 3-х уровненную систему интересно,а почему логику реализовывают именно на сервере,а клиентов цепляют к серверу,к чему такая сложность?для некоторых этот вопрос покажется естественным,но всё-же хотелось бы узнать... А>я так понимаю есть
А>а)процессинговый сервер(реализация логики). А>б)куча тонких клиентов.
А>для какой цели? А>ведь добавляя новый функционал к системе придется обновлять и сервер и клиентов. А>Какие преимущества хранения логики на процессинговом сервере?
в чем преимущества 3-звенки, их много
1. независимость от базы данных (oracle, sql, ib, dbf)
2. клиент не требует установки клиентов баз данных
3. клиент — это движок, он работает с метаданными (формами, таблицами, объектами, отчетами, запросами и т.д.), которые хранятся на сервере, поэтому изменение логики происходит без обновления клиентов, идеальный клиент web-клиент
4. своя удобная и быстрая среда разработки (работа с метаданными) это уход от sql — процедур, триггеров, поэтому требуется, чтобы логика отрабатывала на сервере по производительности аналогичном серверу БД. это и есть сервер приложения.
5. серверов приложения может быть много, а база данных одна.
I>>>Итого — у всех разная картина. IB>>Ну если никто с друг с другом разговаривать не будет, то картина у всех конечно будет разная. I>Понял. Наверное перед тобой сам гендир отчитывается. Завидую.
А Вы чему конкретно завидуете? Неужели Вам доставляет удовольствие когда перед Вами кто-то отчитывается?
Здравствуйте, igor-booch, Вы писали:
I>>>>Итого — у всех разная картина. IB>>>Ну если никто с друг с другом разговаривать не будет, то картина у всех конечно будет разная. I>>Понял. Наверное перед тобой сам гендир отчитывается. Завидую.
IB>А Вы чему конкретно завидуете? Неужели Вам доставляет удовольствие когда перед Вами кто-то отчитывается?
Это была ирония. Вот представь себе типичный аутсорс(наверное 80% всех проектов) — сделали и получили бабло. Успешно ? С точки зрения аутсорсера — да, успешно. Всё. Какие бы ни были технические решения — проект сдан, значит все они успешные.
Даже если заказчик вынужен будет еще три года допиливать этот проект, что бы хоть как то отбить затраты, для аутсорсера выше проект все равно успешный.
I>Это была ирония. Вот представь себе типичный аутсорс(наверное 80% всех проектов) — сделали и получили бабло. Успешно ? С точки зрения аутсорсера — да, успешно. Всё. Какие бы ни были технические решения — проект сдан, значит все они успешные. I>Даже если заказчик вынужен будет еще три года допиливать этот проект, что бы хоть как то отбить затраты, для аутсорсера выше проект все равно успешный.
Есть репутационные потери. Они тоже имеют денежный эквивалент. Посчитать его точно конечно нельзя, но можно экспертно оценить.
Здравствуйте, qlat, Вы писали:
Q>3. клиент — это движок, он работает с метаданными (формами, таблицами, объектами, отчетами, запросами и т.д.), которые хранятся на сервере, поэтому изменение логики происходит без обновления клиентов, идеальный клиент web-клиент
Практика показывает, что без клиентской логики хорошего клиента скорее всего не получится. Даже если это web-клиент.
Q>4. своя удобная и быстрая среда разработки (работа с метаданными) это уход от sql
Создавать свою среду разработки ради ухода от sql точно не стоит, это можно сделать намного проще. Да и вообще, на современном этапе создавать свою среду разработки не нужно никогда, потому что обеспечение того функционала, что дают современные IDE не под силу даже крупным корпорациям, если средства разработки не являются основной сферой их деятельности. А если ты этого функционала не обеспечишь, тогда твое средство будет сильно проигрывать в продуктивности, соответственно смысла в нем будет меньше нуля.
Q>5. серверов приложения может быть много, а база данных одна.
А кеши ты как между разными серверами будешь синхронизировать? Или кешей в твоих серверах нет?
... << RSDN@Home 1.2.0 alpha 5 rev. 100 on Windows 8 6.2.9200.0>>
AVK>Создавать свою среду разработки ради ухода от sql точно не стоит, это можно сделать намного проще. Да и вообще, на современном этапе создавать свою среду разработки не нужно никогда, потому что обеспечение того функционала, что дают современные IDE не под силу даже крупным корпорациям, если средства разработки не являются основной сферой их деятельности. А если ты этого функционала не обеспечишь, тогда твое средство будет сильно проигрывать в продуктивности, соответственно смысла в нем будет меньше нуля.
Здравствуйте, qlat, Вы писали:
Q>Пример 1С, Axapta, Sap
Это все создавалось в те времена, когда IDE современного уровня просто не существовало, а сделать продукт, хотя бы по некоторым параметрам сравнимым с чем нибудь типа VS6 еще можно. Это я не говорю о том, что в 1С все было настолько убого, что даже VCS прикрутить нельзя было. Но с тех пор в этой области очень очень много поменялось. Сейчас IDE без мощных средств анализа и автоматизированного изменения кода, поддержки VCS, расширяемости, современного редактора и прочих уже привычных вещей просто не нужна никому, кроме некоторых гиков, до сих пор пользующихся текстовыми редакторами для разработки.
Но самое интересное что почти все серьезные IDE (ну, как минимум, Eclipse, IDEA и VS) имеют широчайшие возможности по расширяемости в том числе и в плане поддержки собственных языков и платформ, и даже специальные инструменты для создания таких вещей, см., к примеру, DSL Tools в VS, или то что сейчас под эгидой Nemerle делается, или тот же MPS. Бери да пользуйся (хотя и тут трудозатраты для серьезных средств явно не по плечу одному человеку).
P.S. Ты, кстати, VS LightSwitch смотрел? Если нет, то стоит это сделать.
... << RSDN@Home 1.2.0 alpha 5 rev. 100 on Windows 8 6.2.9200.0>>
AVK>Это все создавалось в те времена, когда IDE современного уровня просто не существовало, а сделать продукт, хотя бы по некоторым параметрам сравнимым с чем нибудь типа VS6 еще можно. Это я не говорю о том, что в 1С все было настолько убого, что даже VCS прикрутить нельзя было. Но с тех пор в этой области очень очень много поменялось. Сейчас IDE без мощных средств анализа и автоматизированного изменения кода, поддержки VCS, расширяемости, современного редактора и прочих уже привычных вещей просто не нужна никому, кроме некоторых гиков, до сих пор пользующихся текстовыми редакторами для разработки. AVK>Но самое интересное что почти все серьезные IDE (ну, как минимум, Eclipse, IDEA и VS) имеют широчайшие возможности по расширяемости в том числе и в плане поддержки собственных языков и платформ, и даже специальные инструменты для создания таких вещей, см., к примеру, DSL Tools в VS, или то что сейчас под эгидой Nemerle делается, или тот же MPS. Бери да пользуйся (хотя и тут трудозатраты для серьезных средств явно не по плечу одному человеку).
Согласен IDE становятся открытые, но пока примеров полной интеграции я не видел.
Может скоро увидим, но я не буду первопроходцем
Здравствуйте, IT, Вы писали:
I>>Критерий успешности какой ?
IT>Общая сложность решения.
Чем выше сложность тем лучше или как ? Как сравнить сложность RX и TPL для одной и той же задачи ?
I>>Какие гипотезы выносятся в эксперимент и что именно тебе дают результаты ?
IT>Главный результат — опыт применения той или иной технологии, заключающийся главным образом в выявлении её недостатков и ограничений.
Лучше говорить про возможности и свойства. Потому что недостатки и ограничения привязаны к контексту и совсем не очевидно, как именно.
I>>Мне кажется ты изобретаешь теорию принятия решений. Отрицательный опыт и положительный ничем не помогут в новой задаче.
IT>Т.е. по-твоему любой опыт бесполезен? В принципе, если свой опыт совсем не анализировать, то я с тобой согласен. Но это не мой случай.
По моему надо акцентироваться не на ярлыках, а на возможностях и свойствах решений.
I>>То есть, выходит так, что успешно-неуспешно тянет неявно определенный и очень жосткий контекст и все утверждения привязаны к этому конктексту.
IT>Я объясню, почему отрицательный опыт более ценный и почему он помогает в дальнейшем отсекать заведом неверные решения. Дело в том, что неправильное решение гораздо проще проанализировать и выявить причины неуспешности. Вдумчивый анализ даёт довольно точный и главное ограниченный список этих самых причин. А вот успешное решение ограниченного списка причин успешности не имеет, этот список бесконечен. Это как ходьбы оп минному полю. Есть ограниченное число мест, где находятся мины и куда не стоит идти, а вот путей их обхода, если знать где они находятся, бесконечное множество.
Не совсем ясно, что ты с этим опытом будешь делать. Вот окажется что heapless решение это неудачный опыт, потому что все твои рассуждения привязаны к контексту. А потом сядешь за реалтайм и то же самое окажется именно тем, что надо.
А если отталкиваться от возможностей и свойств, все получается очень просто.
Здравствуйте, igor-booch, Вы писали:
I>>Это была ирония. Вот представь себе типичный аутсорс(наверное 80% всех проектов) — сделали и получили бабло. Успешно ? С точки зрения аутсорсера — да, успешно. Всё. Какие бы ни были технические решения — проект сдан, значит все они успешные. I>>Даже если заказчик вынужен будет еще три года допиливать этот проект, что бы хоть как то отбить затраты, для аутсорсера выше проект все равно успешный.
IB>Есть репутационные потери. Они тоже имеют денежный эквивалент. Посчитать его точно конечно нельзя, но можно экспертно оценить.
То есть, для экспертной оценки качества решения нужна еще какая то экспертная оценка ?
Теоретически твой подход может работать. ТОлько на практике всю необходимую информацию ты можешь получить через год, два а может и вообще никогда не получишь или получишь, но не ту.
Вот реальный пример, названия конторы и продукты изменены.
Команда берется за проект и за год выкатывает версию. Им сообщает что проект никому не нужен и увольняют, остаётся суппорт.
Вывод по твоей методологии — технические решения отстой.
Через полгода этот же проект взлетает сам собой и приносит бабло. Вывод — технические решения на высоте.
Еще через полгода проект сворачивают окончательно. Вывод — технические решения снова отстой.
Через год CEO говорит, что этот продукт был самым лучшим из того что делала контора.
Вывод — технические решения снова на высоте.
Финансовый директор говорит что проект не окупился, потому что суппорт сожрал весь профит. Вывод — технические решения отстой.
Еще через год этот же код продукта реюзается на 90%, ядро остаётся без изменения характеристик, возможностей и тд и новые продукт взлетает, приносит прибыль и окупает всю разработку обоих продуктов за все годы, при этом продолжает так же глючить как и первый вариант.
И вот у тебя два результата — по одному техническое решение отстой. По второму — ажно круть, хотя 90% код почему то из отстойного продукта
Чего реально видно на этом примере — у конторы корявый маркетинг. Никакой корреляции между прибылью и качеством технических решений просто нет и быть не может.
Для того, что бы внятно говорить про успех, надо забыть это слово применительно к техническим решениям.
Вместо этого лучше использовать вещи навроде востребованость и качество, а это уже две большие разницы.
То есть, нужно отделить маркетинг от технических решений. Маркетинг оценивать по прибыли. Технические решения — по качеству.
Вопрос — как оценить качество технического решения ?
I>skipped I>Для того, что бы внятно говорить про успех, надо забыть это слово применительно к техническим решениям. I>Вместо этого лучше использовать вещи навроде востребованость и качество, а это уже две большие разницы. I>То есть, нужно отделить маркетинг от технических решений. Маркетинг оценивать по прибыли. Технические решения — по качеству.
Требования по качеству это часть постановки задачи. Например
требования по производительности — капитальные затраты
по безопасности — капитальные затраты
по трудозатратам на масштабирование (рост функциональности или количества пользователей (данных)) — эксплуатационные расходы
по трудозатратам на исправление багов — эксплуатационные расходы
и т. д.
Если команда не выполнила требования по качеству за отведенный для задачи срок (превысили лимит затрат) это априори означает что она выбрали неудачный вариант
решения задачи.
Даже если команда выполнит требования по качеству, но за срок превышающий отведенный для задачи срок, то это также будет означать что команда выбрала неудачный вариант
решения задачи.
Если экплуатационные расходы превышают максимально допустимые расходы описанные в постановке задачи, то это тоже означает что команда выбрала неудачный вариант
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, qlat, Вы писали:
Q>>Согласен IDE становятся открытые, но пока примеров полной интеграции я не видел.
AVK>Что ты подразумеваешь под полной интеграцией? Во всех трех перечисленных IDE и основные поддерживаемые языки реализованы в виде расширений.
у меня нет примеров систем класса ERP, без своей среды разработки, где использовалась бы полностью среда типа VS. видел решения — биллинг. системы, произв. системы, WMS и т.д. — все это были самописки, которые продавались как коробки, но они были закрытые, в них разработчик клиента почти ничего писать не мог, как в 1С, Axapta, SAP.
Здравствуйте, qlat, Вы писали:
Q>может ты пример приведешь?
Первая ссылка в гугле — http://mybusinessnet.codeplex.com/. А вообще мне твоя логика не очень понятна — типа миллионы леммингов не могут ошибаться? Большинство современных ERP систем родились не сейчас, а тогда, когда качественных и открытых IDE еще не было, я об этом как раз и писал.
... << RSDN@Home 1.2.0 alpha 5 rev. 100 on Windows 8 6.2.9200.0>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, qlat, Вы писали:
Q>>может ты пример приведешь?
AVK>Первая ссылка в гугле — http://mybusinessnet.codeplex.com/. А вообще мне твоя логика не очень понятна — типа миллионы леммингов не могут ошибаться? Большинство современных ERP систем родились не сейчас, а тогда, когда качественных и открытых IDE еще не было, я об этом как раз и писал.
Логика — использовать накопившийся опыт, для быстрого написания движка и перенос решения 1С 7 на данный движок. И не быть первопроходцем
Здравствуйте, Ikemefula, Вы писали:
I>Чем выше сложность тем лучше или как ?
Или как.
I>Как сравнить сложность RX и TPL для одной и той же задачи ?
Я не знаю метрик, которые можно было бы использовать для формальной оценки сложности. Если ты про это.
I>По моему надо акцентироваться не на ярлыках, а на возможностях и свойствах решений.
Я не понимаю что ты подразумеваешь под возможностями и своствами решений.
I>Не совсем ясно, что ты с этим опытом будешь делать.
Этот опыт я буду применять.
I>А если отталкиваться от возможностей и свойств, все получается очень просто.
Если ты мне внятно растолкуешь что ты под этим понимаешь, то может я с тобой и соглашусь.
... << RSDN@Home 1.2.0 alpha 5 rev. 69>>
Если нам не помогут, то мы тоже никого не пощадим.
IT>Это как ходьбы оп минному полю. Есть ограниченное число мест, где находятся мины и куда не стоит идти, а вот путей их обхода, если знать где они находятся, бесконечное множество.
Очень хорошая аналогия. Путей обхода бесконечное множество, но только один путь является наикратчайшим между пунктами А и Б. Знание этого пути является знанием "как надо". И мне не нужно знать где находятся все мины минного поля. Мне нужно знать только мины, которые встретятся на моем кратчайшем пути. Путь человека между пунктами А и Б, который не знает "как надо", будет длиннее кратчайшего. Соответственно ему придется обнаружить больше мин. Когда человек находится в пункте А и ему нужно попасть в пункт Б, сначала продумывает маршрут — это теория, знания "как надо". Потом на этом маршруте он встречает мины получает знания "как не надо" — это практика. А если человек отправится в путь не проложив маршрута, он изучит больше мин, но эти мину будут залегать на таких не оптимальных путях, которыми люди вооруженные знаниями "как надо" никогда не ходят.
Поэтому нельзя говорить:
IT>Я объясню, почему отрицательный опыт более ценный
Все знания имеют ценность, только эта ценность отличается качественно. Это все-равно что сказать, что автомобилисту важнее знать где находятся ямки и кочки на дорогах (актуально для российских дорог), чем знать сами дороги.
Q>>Пример 1С, Axapta, Sap AVK>Это все создавалось в те времена, когда IDE современного уровня просто не существовало
Это всё имеет свою нишу на рынке до сих пор и будет иметь. ERP логика (бухгалтерия, склад) стандартизована. Эти среды направлены на то чтобы максимально быстро и легко (с наименьшими затратами ресурсов) расширять и конфигурировать стандартную логику ERP. Именно расширять и конфигурировать, а не создавать новую. Сделать в этих средах что-то что выбивается из стандартной логики действительно труднее, чем в универсальных средах, типа Visual Studio. Программист ERP в первую очередь ценен знанием предметной области. Технически программирование в среде разработки ERP примитивно. Языки программирования ERP это что-то вроде DSL.
Итого ERP позволяют минимизировать расходы компании, если ей нужна только стандартная логика ERP, возможно сконфигурированная под её нужды. А то что позволяет минимизировать расходы, всегда найдет место на рынке.
Использование ERP это что-то вроде аутсорсинга
бухгалтерии, управления складом. Customer relationship menegment требует большей специализации под клиента, поэтому CRM системы развиты меньше. Хотя тоже есть у Microsoft.
Здравствуйте, igor-booch, Вы писали:
IB>ERP логика (бухгалтерия, склад) стандартизована.
Если бы. Во-первых не путай бухгалтерию и ERP. В бухгалтерии таки да, есть стандарты (которые периодически меняются, особенно в РФ), но и в рамках этих стандартов возможны определенные изменения в логике. Но ERP это сильно больше чем бухгалтерия. А склад нифига не стандартизован (стандартизованы, и то в определенных пределах, некоторые документы типа накладной), тебя обманули.
IB> Эти среды направлены на то чтобы максимально быстро и легко (с наименьшими затратами ресурсов) расширять и конфигурировать стандартную логику ERP. Именно расширять и конфигурировать, а не создавать новую.
Ты 1С то видел изнутри? Опять же, ты что думаешь, стандартная логика какого нибудь отраслевого решения, она с неба падает или все таки кто то ее пишет?
... << RSDN@Home 1.2.0 alpha 5 rev. 100 on Windows 8 6.2.9200.0>>
Здравствуйте, igor-booch, Вы писали:
IB>Очень хорошая аналогия. Путей обхода бесконечное множество, но только один путь является наикратчайшим между пунктами А и Б.
Не надо из аналогий делать выводы, это, как минимум, логически некорректно. Критериев оптимальности решения несколько, и баланс приоритетов этих критериев зависит от конкретной ситуации и конкретного проекта. Где то важнее время, где то возможность реализации с большим количеством неопытных разработчиков, где то минимизация потраченного бабла, где то достижение высокого уровня качества и т.д. Но и это еще проблема. Другая проблема в том что не все критерии можно посчитать в нужный момент времени. Как, к примеру, оценить стоимость развития системы, когда у нас еще даже первый релиз не состоялся?
В отличие от этого, факапы видны вполне очевидным образом и почти вне зависимости от критериев оптимальности и баланса между ними.
Таким образом, сказать что вот такое решение всегда хорошо в любом проекте почти никогда не выходит, кроме совсем уж примитивных вещей, зато сказать что вот такой факап это жопа опять же в почти любом проекте обычно удается.
IT>>Я объясню, почему отрицательный опыт более ценный IB>Все знания имеют ценность, только эта ценность отличается качественно. Это все-равно что сказать, что автомобилисту важнее знать где находятся ямки и кочки на дорогах (актуально для российских дорог), чем знать сами дороги.
Предполагается обычно, что человек, который берется за архитектуру системы с ощутимой стоимостью разработки уже знает где дороги.
... << RSDN@Home 1.2.0 alpha 5 rev. 100 on Windows 8 6.2.9200.0>>
AVK>Во-первых не путай бухгалтерию и ERP. AVK>Но ERP это сильно больше чем бухгалтерия.
Бухгалтерия это часть ERP, причем центральная. Продуктом работы любого модуля (например закупки, продажи, склад) могут быть бухгалтерские проводки.
AVK>А склад нифига не стандартизован (стандартизованы, и то в определенных пределах, некоторые документы типа накладной), тебя обманули.
Модуль склад есть точно в Axapta, есть в 1С. По моим оценкам 50 — 60% среднего и малого бизнеса достаточно стандартной функциональности модуля Склад. 20 — 30% требуется расширение стандартной функциональности средствами разработки ERP. Только русские заказчики всегда стремятся прогнуть систему под себя, невзирая на риск её поломки, а иностранные заказчики учитывают риск поломки от чрезмерного вмешательства программистов в стандартную логику и предпочитают подстроить свои бизнес процессы под систему ERP.
AVK>Ты 1С то видел изнутри? Опять же, ты что думаешь,
Axapta видел изнутри, работал 1,5 года на ней программистом.
AVK>стандартная логика какого нибудь отраслевого решения, она с неба падает или все таки кто то ее пишет?
Пишет Microsoft, на консалтинговые компании, которые занимаются внедрением Axapta она "падает с неба", если можно так выразиться. Консалтинговая фирма стандартную логику не пишет, он её больше конфигурирует и дополняет под нужды конечного заказчика.
Здравствуйте, igor-booch, Вы писали:
I>>Для того, что бы внятно говорить про успех, надо забыть это слово применительно к техническим решениям. I>>Вместо этого лучше использовать вещи навроде востребованость и качество, а это уже две большие разницы. I>>То есть, нужно отделить маркетинг от технических решений. Маркетинг оценивать по прибыли. Технические решения — по качеству.
IB>Я говорил не о прибыли, а о затратах, причем <b>затратах </b>
Это не важно. Самое главное — у тебя оценка комплексная.
То есть, по популярности текста ты пытаешься оценить уровень владения языком автора текста
IB>Требования по качеству это часть постановки задачи. Например IB>требования по производительности — капитальные затраты IB>по безопасности — капитальные затраты IB>по трудозатратам на масштабирование (рост функциональности или количества пользователей (данных)) — эксплуатационные расходы IB>по трудозатратам на исправление багов — эксплуатационные расходы IB>и т. д.
IB>Если команда не выполнила требования по качеству за отведенный для задачи срок (превысили лимит затрат) это априори означает что она выбрали неудачный вариант
Ну как же — выполнила. Все в ажуре — вложились в сроки, получили бабло — код хороший и решения на высоте.
IB>Если экплуатационные расходы превышают максимально допустимые расходы описанные в постановке задачи, то это тоже означает что команда выбрала неудачный вариант
Здравствуйте, IT, Вы писали:
I>>Как сравнить сложность RX и TPL для одной и той же задачи ?
IT>Я не знаю метрик, которые можно было бы использовать для формальной оценки сложности. Если ты про это.
А как же тогда общую сложность решения оценивать ?
I>>По моему надо акцентироваться не на ярлыках, а на возможностях и свойствах решений. IT>Я не понимаю что ты подразумеваешь под возможностями и своствами решений.
На примере твоего БЛТ — возможности это просто фичи, большие и маленькие. А быстродействие, расход памяти и прочие вещи — это свойства.
I>>А если отталкиваться от возможностей и свойств, все получается очень просто. IT>Если ты мне внятно растолкуешь что ты под этим понимаешь, то может я с тобой и соглашусь.
Еще раз на примере GC. Если подходить по твоему, то для конкретного приложения можно получить вывод, что GC это удачное решение, ибо не надо следить за памятью и тд, а надо всего то заботиться о занулении ссылок.
В другом приложении внезапно окажется, что этого недостаточно, надо еще избавляться от старых объектов и пользовать иммутабельные объекты. В третьем — окажется, что наоборот, надо переходить на старые объекты. Вроде как по мелочи, но оказывается, что удачный опыт какой то не совсем удачный, без конкретного контекста его вообще невозможно реюзать.
Собтсвенно отсутствие реюзабельности демонстрирует другой пример — в конкретном приложении, скажем высоконагруженый сервер или какой реалтайм нужно использовать heapless-решения ну например для кеширования и очень аккуратно пользовать GC в остальных случаях.
При этом проблемы с реалтаймом вытекают из свойств .Net GC и требований к реалтайму. Если время отклика час-два, то это одно, а если 100мс то GC мягко говоря, может работать гораздо дольше и тут не надо пилить какой то проект, что бы анализировать удачность или неудачность применения GC.
Вобщем обсуждение удачных и неудачных решений имеет смысл только если ты сидишь носом в одной и той же области годами, контекст не меняется и людям во круг тебя всё и так понятно, даже объяснять не нужно.
Здравствуйте, IT, Вы писали:
IT>>>Я не знаю метрик, которые можно было бы использовать для формальной оценки сложности. Если ты про это. I>>А как же тогда общую сложность решения оценивать ?
IT>На больше / меньше.
Значит у тебя есть какие то метрики, только ты стесняешься их показать
I>>На примере твоего БЛТ — возможности это просто фичи, большие и маленькие. А быстродействие, расход памяти и прочие вещи — это свойства.
IT>И какое это всё имеет отношение к правильности принятых решений. Вот например следующее имеет самое непосредственное отношение. На примере моего БЛТ можно сказать, что SqlBuilder в нём спроектирован неудачно, т.к. в одном месте намешалось AST для SQL, оптимизации этого AST и средства его конструирования. В результате получилась довольно негибкая архитектура, что в конце концов не лучшим образом повлияла на некоторые решения в дальнейшем. Т.е. имеет место быть самый настоящий отрицательный опыт с чётким пониманием того почему так делать не надо. А то, о чём ты говоришь — это есть функциональные и нефункцианальные требования, которые к обсуждаемой теме вообще не имеют никакого отношения.
То есть, "намешалось AST для SQL, оптимизации этого AST и средства его конструирования" и "негибкая архитектура" ты почему то не можешь рассматриват как свойство BLT. Вопрос — почему ?
I>>Вроде как по мелочи, но оказывается, что удачный опыт какой то не совсем удачный, без конкретного контекста его вообще невозможно реюзать.
IT>Именно это я и пытаюсь донести с самого моего первого сообщения в этом топике.
Насколько я понял, "неудачный опыт" судя по примеру БЛТ это просто некоторые ограничения == свойства в конкретном контексте. И вот как то странно искать решение руководствуясь одними лишь ограничениями
Здравствуйте, IT, Вы писали:
IT>По-моему, ты зациклился на своих свойсвах и пытаешь подменить одно понятие другим, чтобы объяснить для себя непонятное в более привычных терминах. Из этой подмены ничего не получается, но в результате ты сваливаешь свои проблемы на оригинальные утверждения.
Есть интересный аргумент. Берешь незнакомую задачу, т.е. задачу из какого нибудь класса с которым ты ранее не сталкивался, и пробуешь её решить своим методом "как не надо делать" от начала и до конца.
Здравствуйте, AndrewVK, Вы писали:
AVK>Нет. Центральная часть, о чем недвусмысленно говорит название, это планирование ресурсов. А бухгалтерия это не планирование, это пост-фактум отчетность.
Зачем знать что было первым яйцо или курица, или где начало и конец палки? бухгалтерия или планирование
склад(логистика) или проекты. Важны функции, которые предоставляет типовое решение, чем больше их, тем шире решение.
AVK>А серьезные ERP системы про сравнению с типовыми конфигурациями 1С, это примерно как авиалайнер рядом с велосипедом.
1С 8. — ERP система, на ней автоматизируют крупные предприятия и холдинги, посмотри на сайте кто клиенты и какие модули внедряют — планирование и бюджетирование
AVK>Кого в этом топике волнуют те, кто занимается внедрением? Средства разработки не для них создаются, а для тех кто делает прикладные решения. Если ты когда то там у какого то внедренца подпиливал стандартные конфигурации, это вовсе не означает что это единственная или даже основная аудитория средств разработки ERP платформ. В Парусе, к примеру, вообще таких людей, как у 1С, массовых допильщиков стандартных конфигураций, вообще нет. А конкретно в упомянутом тут Парус 10 на данный момент под релизную платформу собрать решение можно только на серверах Паруса. Бизнес у всех поставщиков ERP решений разный, не стоит под одну гребенку всех кто в этом секторе работает равнять.
Средства разработки создаются для программистов, если средства разработки плохое то программисты внедрения и заказчик ничего не сможет изменить, а значит система не будет широко применяться, т.к. только 20 человек из компании разработчика смогут ее изменить.
Здравствуйте, qlat, Вы писали:
AVK>>Нет. Центральная часть, о чем недвусмысленно говорит название, это планирование ресурсов. А бухгалтерия это не планирование, это пост-фактум отчетность. Q>Зачем знать что было первым яйцо или курица, или где начало и конец палки? бухгалтерия или планирование
Затем, что алгоритмы планирования, в отличие от бухгалтерии, никоим образом не стандартизированы.
AVK>>А серьезные ERP системы про сравнению с типовыми конфигурациями 1С, это примерно как авиалайнер рядом с велосипедом. Q>1С 8. — ERP система, на ней автоматизируют крупные предприятия и холдинги
Ключевое в цитате я выделил болдом.
... << RSDN@Home 1.2.0 alpha 5 rev. 100 on Windows 8 6.2.9200.0>>
Здравствуйте, qlat, Вы писали:
Q>Согласен IDE становятся открытые, но пока примеров полной интеграции я не видел.
А что такое "полной интеграции"? Сейчас на Eclipse уже есть, по-моему, всё.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, qlat, Вы писали:
Q>И не быть первопроходцем
И для "не быть первопроходцем" ты решил написать свой велосипедный IDE с нуля, вместо того чтобы воспользоваться готовыми средствами разработки, в которые вложено десяток тысяч человеколет?
... << RSDN@Home 1.2.0 alpha 5 rev. 100 on Windows 8 6.2.9200.0>>
Если нам не помогут, то мы тоже никого не пощадим.
